Active Directory Azure

Table of Contents
Overview
What is Azure Active Directory?
Choose edition
About Azure identity management
Preview the Azure portal experience
Get started
Get an Azure AD tenant
Sign up for Azure AD Premium
Associate Azure subscriptions
Manage AD licensing
Get Azure for your organization
FAQs
SaaS app tutorials
How to
Manage users
Add users
Add users from other directories
Delete users
Manage user profiles
Reset a password
Manage user work information
Share accounts
Manage groups and members
Manage groups
Manage group members
Manage group owners
Manage group membership
View all groups
Enable dedicated groups
Add group access to SaaS apps
Manage group settings
Create advanced rules
Set up self-service groups
Troubleshoot
View access and usage reports
Azure AD reporting
Known networks
Reporting guide
Understand reports
Manage passwords
Update your own password
Understand password management
Understand policies and restrictions
Reset passwords
Set expiration policies
Enable Password Management
Manage devices
Register your device
Register a Windows 10 device
Conditional access
Azure AD Join
Certificate-based Authentication
Manage apps
Overview
Getting started
Cloud App Discovery
Give remote access to your apps
Understand SSO for apps
Integrate SaaS apps
Manage enterprise apps
Develop
Manage access to apps
Use SCIM provision users
Document library
Manage your directory
Custom domain names
Customize the sign-in page
Administer your directory
Multiple directories
O365 directories
Self-service signup
Enterprise State Roaming
Integrate partners with Azure AD B2B
Integrate on-premises identities using Azure AD Connect
Delegate access to resources
Administrator roles
Administrative units
Resource access in Azure
Role-Based Access Control
Configure token lifetimes
Secure your identities
Azure AD Identity Protection
Privileged Identity Management
Deploy 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 a hybrid identity solution
Determine requirements
Plan for data security
Plan your identity lifecycle
Next steps
Tools comparison
Deploy AD FS in Azure
High availability
Change signature hash algorithm
Troubleshoot
Reference
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
Pricing
MSDN forum
Stack Overflow
Videos
Service updates
Azure feedback forum
1/17/2017 5 min to read Edit on GitHub
Azure Active Directory (Azure AD) is Microsofts multi-tenant cloud based directory and identity management
service.
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 Office365, Azure or Dynamics CRM Online customer, you might not realize that you are already
using Azure AD. Every Office365, 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, youll 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.
What are the benefits of Azure AD?

Your organization can use Azure AD to improve employee productivity, streamline IT processes, improve security
and cut costs in many ways:
Quickly adopt cloud services, providing employees and partners with an easy single-sign on experience
powered by Azure ADs fully automated SaaS app access management and provisioning services capabilities.
Empower employees with access to world class cloud apps and self-service capabilities from wherever they
need to work on the devices they love to use.
Easily and securely manage employee and vendor access to your corporate social media accounts.
Improve application security with Azure AD multifactor authentication and conditional access.
Implement consistent, self-service application access management, empowering business owners to move
quickly while cutting IT costs and overheads.
Monitor application usage and protect your business from advanced threats with security reporting and
monitoring.
Secure mobile (remote) access to on-premises applications.
How does Azure AD compare to on-premises Active Directory Domain

Services (AD DS)?
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.
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.
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.
You can use Azure AD Connect to sync your on-premises identities with Azure AD.
Authentication and authorization details

Azure AD
SAML , WS-Federation , Interactive with supported credentials, OAuth 2.0, OpenID Connect
On-premises AD DS
SAML , WS-Federation , NTLM, Kerberos, MD5, Basic
Object repository details

Azure AD
Access via Azure AD Graph and Microsoft Graph
On-premises AD DS
X.500 LDAP
Programmatic access details

Azure AD
MS/Azure AD Graph REST APIs
On-premises AD DS
LDAP
SSO to applications details

Azure AD
OpenID Connect , SAML
On-premises AD DS
Open-ID Connect , SAML , WS-Fed
Access management details

Azure AD
Resource-defined scope and role based access control, Client-define delegated and application permissions,
Consent Framework (enforces proper user/admin consent, as defined/requested by resource/client)
Via app role, can be applied individually or through groups, supports: Admin managed, Self-service application
access, User consent
On-premises AD DS
Via ACLs, can be applied individually or through groups, supports: Admin managed
Group management details

Azure AD
Admin managed , Rule/dynamic managed, Self-service group management
On-premises AD DS
Admin managed , External system (FIM, or other) required for Rule/dynamic managed |
Supported credentials details

Azure AD
Username + password , Smartcard
On-premises AD DS
Username + password , Smartcard
How can I get started?

If you are an IT admin:
Try it out! - you can sign up for a free 30 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
Where can I learn more?

We have a ton of great resources online to help you learn all about Azure AD. Heres 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
Azure Active Directory editions
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, described below.
Azure Active Directory is a comprehensive, highly available identity and access management cloud solution that
combines core directory services, advanced identity governance, and application access management. Azure
Active Directory also offers a rich, standards-based platform that enables developers to deliver access control to
their applications, based on centralized policy and rules. 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 learn more about Azure Active Directory, read What is Azure AD?
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.
Office 365 subscriptions include additional Azure Active Directory features described in the comparison table
below.
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.
To sign up and start using Active Directory Premium today, see Getting started with Azure Active Directory
Premium.
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?
Comparing generally available features

NOTE
For a different view of this data, see the Azure Active Directory Capabilities.
Common Features
Directory Objects
User/Group Management (add/update/delete)/ User-based provisioning, Device registration
Single Sign-On (SSO)
Self-Service Password Change for cloud users
Connect (Sync engine that extends on-premises directories to Azure Active Directory)
Security / Usage Reports
Basic Features
Group-based access management / provisioning
Self-Service Password Reset for cloud users
Company Branding (Logon Pages/Access Panel customization)
Application Proxy
SLA 99.9%
Premium P1 Features
Self-Service Group and app Management/Self-Service application additions/Dynamic Groups
Self-Service Password Reset/Change/Unlock with on-premises write-back
Multi-Factor Authentication (Cloud and On-premises (MFA Server))
MIM CAL + MIM Server
Cloud App Discovery
Connect Health
Automatic password rollover for group accounts
Premium P2 Features
Identity Protection
Azure Active Directory Join Windows 10 only related features
Join a device to Azure AD, Desktop SSO, Microsoft Passport for Azure AD, Administrator Bitlocker recovery
MDM auto-enrollment, Self-Service Bitlocker recovery, Additional local administrators to Windows 10 devices
via Azure AD Join
Common Features
Directory Objects
Type: Common Features
The default usage quota is 150,000 objects. An object is an entry in the directory service, represented by its
unique distinguished name. An example of an object is a user entry used for authentication purposes. If you need
to exceed this default quota, please contact support. The 500K object limit does not apply for Office 365,
Microsoft Intune or any other Microsoft paid online service that relies on Azure Active Directory for directory
services.
Availability:
PREMIUM (P1 AND P2)

FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY
Up to 500,000 objects No object limit No object limit No object limit for Office
365 user accounts
User/Group Management (add/update/delete), User-based provisioning, Device registration

Availability:
PREMIUM (P1 AND P2)

More details:
Administer your Azure AD directory
Azure Active Directory Device Registration overview
Availability:
PREMIUM (P1 AND P2)

10 apps per user (1) 10 apps per user (1) No Limit (2) 10 apps per user (1)
1. With Azure AD Free and Azure AD Basic, end-users are entitled to get single sign-on access for up to 10
applications.
2. Self-service integration of any application supporting SAML, SCIM, or forms-based authentication by using
templates provided in the application gallery menu. For more details, see Configuring single sign-on to
applications that are not in the Azure Active Directory application gallery.
More details:
Managing Applications with Azure Active Directory (AD)
Self-Service Password Change for cloud users
Availability:
PREMIUM (P1 AND P2)

More details:
How to update your own password
Connect (Sync engine that extends on-premises directories to Azure Active Directory )
Availability:
PREMIUM (P1 AND P2)

More details:
Integrating your on-premises identities with Azure Active Directory
Security/Usage Reports
Availability:
PREMIUM (P1 AND P2)

3 Basic reports 3 Basic reports Advanced reports 3 Basic reports
More details:
View your access and usage reports
Premium and Basic Features

Group-based access management/provisioning
Type: Basic Features
Availability:
PREMIUM (P1 AND P2)

More details:
Using a group to manage access to SaaS applications
Self-Service Password Reset for cloud users
Availability:
PREMIUM (P1 AND P2)

More details:
Azure AD Password Reset for Users and Admins
Company Branding (Logon Pages/Access Panel customization )
Availability:
PREMIUM (P1 AND P2)

More details:
Add company branding to your Sign In and Access Panel pages
Application Proxy
Availability:
PREMIUM (P1 AND P2)

More details:
How to provide secure remote access to on-premises applications
SLA 99.9%
Availability:
PREMIUM (P1 AND P2)

More details:
Service Level Agreements
Premium Features
Self-Service Group and app Management/Self-Service application additions/Dynamic Groups
Type: Premium Features
Availability:
PREMIUM (P1 AND P2)

Self-Service Password Reset/Change/Unlock with on-premises write-back

Availability:
PREMIUM (P1 AND P2)

Multi-Factor Authentication (Cloud and On-premises (MFA Server))

Availability:
PREMIUM (P1 AND P2)

Limited to cloud only for

Office 365 Apps
More details:
What is Azure Multi-Factor Authentication?
MIM CAL + MIM Server
Microsoft Identity Manager Server software rights are granted with Windows Server licenses (any edition).
Because Microsoft Identity Manager runs on the Windows Server operating system, as long as the server is
running a valid, licensed copy of Windows Server, then Microsoft Identity Manager can be installed and used on
that server. No other separate license is required for Microsoft Identity Manager Server.
Availability:
PREMIUM (P1 AND P2)

Cloud App Discovery

Availability:
PREMIUM (P1 AND P2)

More details:
Finding unmanaged cloud applications with Cloud App Discovery
Azure AD Connect Health
Availability:
PREMIUM (P1 AND P2)

More details:
Monitor your on-premises identity infrastructure and synchronization services in the cloud
Automatic password rollover for group accounts
Availability:
PREMIUM (P1 AND P2)

Identity Protection
FREE EDITION BASIC EDITION PREMIUM P2 EDITION OFFICE 365 APPS ONLY

FREE EDITION BASIC EDITION PREMIUM P2 EDITION OFFICE 365 APPS ONLY
Azure Active Directory Join Windows 10 only related features

Join a device to Azure AD, Desktop SSO, Microsoft Passport for Azure AD, Administrator Bitlocker recovery
Type: Azure Active Directory Join Windows 10 only related features
Availability:
PREMIUM (P1 AND P2)

MDM auto-enrollment, Self-Service Bitlocker recovery, Additional local administrators to Windows 10 devices via Azure AD Join
Availability:
PREMIUM (P1 AND P2)

Availability:
PREMIUM (P1 AND P2)

More details:
Azure AD preview features

In addition to the generally available features of the Free, Basic, and Premium (P1 and P2) editions, Azure AD also
provides you with a collection of preview features. You can use the preview features to get an impression of what
is coming in the near future and to determine whether these features can help improving your environment.
Available preview features:
B2B collaboration
Administrative Units
HR application Integration
Certificate-based authentication on iOS
Certificate-based authentication on Android
What's next
Getting started with Azure Active Directory Premium
The fundamentals of Azure identity management
Managing identity is just as important in the public cloud as it is on premises. To help with this, Azure supports
several different cloud identity technologies. They include these:
You can run Windows Server Active Directory (commonly called just AD) in the cloud using virtual machines
created with Azure Virtual machines. This approach makes sense when you're using Azure to extend your on-
premises datacenter into the cloud.
You can use Azure Active Directory to give your users single sign-on to Software as a Service (SaaS)
applications. Microsoft's Office 365 uses this technology, for example, and applications running on Azure or
other cloud platforms can also use it.
Applications running in the cloud or on-premises can use Azure Active Directory Access Control to let users log
in using identities from Facebook, Google, Microsoft, and other identity providers.
This article describes all three of these options.
Table of Contents
Running Windows Server Active Directory in virtual machines
Using Azure Active Directory
Using Azure Active Directory Access Control
Running Windows Server Active Directory in virtual machines

Running Windows Server AD in Azure virtual machines is much like running it on-premises. Figure 1 shows a
typical example of how this looks.
Figure 1: Windows Server Active Directory can run in Azure virtual machines connected to an organization's on-
premises datacenter using Azure Virtual Network.
In the example shown here, Windows Server AD is running in VMs created using Azure Virtual Machines, the
platform's IaaS technology. These VMs and a few others are grouped into a virtual network connected to an on-
premises datacenter using Azure Virtual Network. The virtual network carves out a group of cloud virtual machines
that interact with the on-premises network via a virtual private network (VPN) connection. Doing this lets these
Azure virtual machines look like just another subnet to the on-premises datacenter. As the figure shows, two of
those VMs are running Windows Server AD domain controllers. The other virtual machines in the virtual network
might be running applications, such as SharePoint, or being used in some other way, such as for development and
testing. The on-premises datacenter is also running two Windows Server AD domain controllers.
There are several options for connecting the domain controllers in the cloud with those running on premises:
Make all of them part of a single Active Directory domain.
Create separate AD domains on-premises and in the cloud that are part of the same forest.
Create separate AD forests in the cloud and on-premises, then connect the forests using cross-forest trusts or
Windows Server Active Directory Federation Services (AD FS), which can also run in virtual machines on Azure.
Whatever choice is made, an administrator should make sure that authentication requests from on-premises users
go to cloud domain controllers only when necessary, since the link to the cloud is likely to be slower than on-
premises networks. Another factor to consider in connecting cloud and on-premises domain controllers is the
traffic generated by replication. Domain controllers in the cloud are typically in their own AD site, which allows an
administrator to schedule how often replication is done. Azure charges for traffic sent out of an Azure datacenter,
although not for bytes sent in, which might affect the administrator's replication choices. It's also worth pointing
out that while Azure does provide its own Domain Name System (DNS) support, this service is missing features
required by Active Directory (such as support for Dynamic DNS and SRV records). Because of this, running
Windows Server AD on Azure requires setting up your own DNS servers in the cloud.
Running Windows Server AD in Azure VMs can make sense in several different situations. Here are some examples:
If you're using Azure Virtual Machines as an extension of your own datacenter, you might run applications in
the cloud that need local domain controllers to handle things such as Windows Integrated Authentication
requests or LDAP queries. SharePoint, for example, interacts frequently with Active Directory, and so while it's
possible to run a SharePoint farm on Azure using an on-premises directory, setting up domain controllers in the
cloud will significantly improve performance. (It's important to realize that this isn't necessarily required,
however; plenty of applications can run successfully in the cloud using only on-premises domain controllers.)
Suppose a faraway branch office lacks the resources to run its own domain controllers. Today, its users must
authenticate to domain controllers on the other side of the world - logins are slow. Running Active Directory on
Azure in a closer Microsoft datacenter can speed this up without requiring more servers in the branch office.
An organization that uses Azure for disaster recovery might maintain a small set of active VMs in the cloud,
including a domain controller. It can then be prepared to expand this site as needed to take over for failures
elsewhere.
There are also other possibilities. For example, you're not required to connect Windows Server AD in the cloud to
an on-premises datacenter. If you wanted to run a SharePoint farm that served a particular set of users, for
instance, all of whom would log in solely with cloud-based identities, you might create a standalone forest on
Azure. How you use this technology depends on what your goals are. (For more detailed guidance on using
Windows Server AD with Azure, see here.)
Using Azure Active Directory

As SaaS applications become more and more common, they raise an obvious question: What kind of directory
service should these cloud-based applications use? Microsoft's answer to that question is Azure Active Directory.
There are two main options for using this directory service in the cloud:
Individuals and organizations that use only SaaS applications can rely on Azure Active Directory as their sole
directory service.
Organizations that run Windows Server Active Directory can connect their on-premises directory to Azure
Active Directory, then use it to give their users single sign-on to SaaS applications.
Figure 2 illustrates the first of these two options, where Azure Active Directory is all that's required.
Figure 2: Azure Active Directory gives an organization's users single sign-on to SaaS applications, including Office
365.
As the figure shows, Azure AD is a multi-tenant service. This means that it can simultaneously support many
different organizations, storing directory information about users at each of them. In this example, a user at
organization A is trying to access a SaaS application. This application might be part of Office 365, such as
SharePoint Online, or it might be something else - non-Microsoft applications can also use this technology.
Because Azure AD supports the SAML 2.0 protocol, all that's required from an application is the ability to interact
using this industry standard. (In fact, applications that use Azure AD can run in any datacenter, not just an Azure
datacenter.)
The process begins when the user accesses a SaaS application (step 1). To use this application, the user must
present a token issued by Azure AD.
This token contains information that identifies the user, and it's digitally signed by Azure AD. To get the token, the
user authenticates himself to Azure AD by providing a username and password (step 2). Azure AD then returns the
token he needs (step 3).
This token is then sent to the SaaS application (step 4), which validates the token's signature and uses its contents
(step 5). Typically, the application will use the identity information the token contains to decide what information
the user is allowed to access and perhaps in other ways.
If the application needs more information about the user than what's contained in the token, it can request this
directly from Azure AD using the Azure AD Graph API (step 6). In the initial version of Azure AD, the directory
schema is quite simple: It contains just users and groups and relationships among them. Applications can use this
information to learn about connections between users. For example, suppose an application needs to know who
this user's manager is to decide whether he's allowed access to some chunk of data. It can learn this by querying
Azure AD through the Graph API.
The Graph API uses an ordinary RESTful protocol, which makes it straightforward to use from most clients,
including mobile devices. The API also supports the extensions defined by OData, adding things such as a query
language to let clients access data in more useful ways. (For more on OData, see Introducing OData.) Because the
Graph API can be used to learn about relationships between users, it lets applications understand the social graph
that's embedded in the Azure AD schema for a particular organization (which is why it's called the Graph API). And
to authenticate itself to Azure AD for Graph API requests, an application uses OAuth 2.0.
If an organization doesn't use Windows Server Active Directory - it has no on-premises servers or domains - and
relies solely on cloud applications that use Azure AD, using just this cloud directory would give the firm's users
single sign-on to all of them. Yet while this scenario gets more common every day, most organizations still use on-
premises domains created with Windows Server Active Directory. Azure AD has a useful role to play here as well,
as Figure 3 shows.
Figure 3: An
organization can federate Windows Server Active Directory with Azure Active Directory to give its users single
sign-on to SaaS applications.
In this scenario, a user at organization B wishes to access a SaaS application. Before she does this, the
organization's directory administrators must establish a federation relationship with Azure AD using AD FS, as the
figure shows. Those admins must also configure data synchronization between the organization's on-premises
Windows Server AD and Azure AD. This automatically copies user and group information from the on-premises
directory to Azure AD. Notice what this allows: In effect, the organization is extending its on-premises directory into
the cloud. Combining Windows Server AD and Azure AD in this way gives the organization a directory service that
can be managed as a single entity, while still having a footprint both on-premises and in the cloud.
To use Azure AD, the user first logs in to her on-premises Active Directory domain as usual (step 1). When she tries
to access the SaaS application (step 2), the federation process results in Azure AD issuing her a token for this
application (step 3). (For more on how federation works, see Claims-Based Identity for Windows: Technologies and
Scenarios.) As before, this token contains information that identifies the user, and it's digitally signed by Azure AD.
This token is then sent to the SaaS application (step 4), which validates the token's signature and uses its contents
(step 5). And is in the previous scenario, the SaaS application can use the Graph API to learn more about this user if
necessary (step 6).
Today, Azure AD isn't a complete replacement for on-premises Windows Server AD. As already mentioned, the
cloud directory has a much simpler schema, and it's also missing things such as group policy, the ability to store
information about machines, and support for LDAP. (In fact, a Windows machine can't be configured to let users
log in to it using nothing but Azure AD - this isn't a supported scenario.) Instead, the initial goals of Azure AD
include letting enterprise users access applications in the cloud without maintaining a separate login and freeing
on-premises directory administrators from manually synchronizing their on-premises directory with every SaaS
application their organization uses. Over time, however, expect this cloud directory service to address a wider
range of scenarios.
Using Azure Active Directory Access Control

Cloud-based identity technologies can be used to solve a variety of problems. Azure Active Directory can give an
organization's users single sign-on to multiple SaaS applications, for example. But identity technologies in the
cloud can also be used in other ways.
Suppose, for instance, that an application wishes to let its users log in using tokens issued by multiple identity
providers (IdPs). Lots of different identity providers exist today, including Facebook, Google, Microsoft, and others,
and applications frequently let users sign in using one of these identities. Why should an application bother to
maintain its own list of users and passwords when it can instead rely on identities that already exist? Accepting
existing identities makes life simpler both for users, who have one less username and password to remember, and
for the people who create the application, who no longer need to maintain their own lists of usernames and
passwords.
But while every identity provider issues some kind of token, those tokens aren't standard - each IdP has its own
format. Furthermore, the information in those tokens also isn't standard. An application that wishes to accept
tokens issued by, say, Facebook, Google, and Microsoft is faced with the challenge of writing unique code to handle
each of these different formats.
But why do this? Why not instead create an intermediary that can generate a single token format with a common
representation of identity information? This approach would make life simpler for the developers who create
applications, since they now need to handle only one kind of token. Azure Active Directory Access Control does
exactly this, providing an intermediary in the cloud for working with diverse tokens. Figure 4 shows how it works
Figure 4: Azure Active Directory Access Control makes it easier for applications to accept identity tokens issued by
different identity providers.
The process begins when a user attempts to access the application from a browser. The application redirects her to
an IdP of her choice (and that the application also trusts). She authenticates herself to this IdP, such as by entering a
username and password (step 1), and the IdP returns a token containing information about her (step 2).
As the figure shows, Access Control supports a range of different cloud-based IdPs, including accounts created by
Google, Yahoo, Facebook, Microsoft (formerly known as Windows Live ID), and any OpenID provider. It also
supports identities created using Azure Active Directory and, through federation with AD FS, Windows Server
Active Directory. The goal is to cover the most commonly used identities today, whether they're issued by IdPs in
the cloud or on-premises.
Once the user's browser has an IdP token from her chosen IdP, it sends this token to Access Control (step 3). Access
Control validates the token, making sure that it really was issued by this IdP, then creates a new token according to
the rules that have been defined for this application. Like Azure Active Directory, Access Control is a multi-tenant
service, but the tenants are applications rather than customer organizations. Each application can get its own
namespace, as the figure shows, and can define various rules about authorization and more.
These rules let each application's administrator define how tokens from various IdPs should be transformed into an
Access Control token. For example, if different IdPs use different types for representing usernames, Access Control
rules can transform all of these into a common username type. Access Control then sends this new token back to
the browser (step 4), which submits it to the application (step 5). Once it has the Access Control token, the
application verifies that this token really was issued by Access Control, then uses the information it contains (step
6).
While this process might seem a little complicated, it actually makes life significantly simpler for the creator of the
application. Rather than handle diverse tokens containing different information, the application can accept
identities issued by multiple identity providers while still receiving only a single token with familiar information.
Also, rather than require each application to be configured to trust various IdPs, these trust relationships are
instead maintained by Access Control - an application need only trust it.
It's worth pointing out that nothing about Access Control is tied to Windows - it could just as well be used by a
Linux application that accepted only Google and Facebook identities. And even though Access Control is part of the
Azure Active Directory family, you can think of it as an entirely distinct service from what was described in the
previous section. While both technologies work with identity, they address quite different problems (although
Microsoft has said that it expects to integrate the two at some point).
Working with identity is important in nearly every application. The goal of Access Control is to make it easier for
developers to create applications that accept identities from diverse identity providers. By putting this service in the
cloud, Microsoft has made it available to any application running on any platform.
About the Author

David Chappell is Principal of Chappell & Associates www.davidchappell.com in San Francisco, California.
Preview of the Azure Active Directory management
experience in the Azure portal
The Azure Active Directory (Azure AD) management experience is in preview in the Azure portal. You can try it
out by signing in to the Azure portal as a global administrator of your directory. Then, select Azure Active
Directory in the services list if it is visible, or select More services to view the list of all services. You do not need
an Azure subscription to use the Azure AD management experience in the Azure portal.
Learn about what you can do in the preview experience

The preview experience enables you to manage many directory resources such as users, groups, applications,
and directory settings in the Azure portal. We are improving this experience to include all the capabilities that
exist in the Azure AD management experience in the Azure classic portal. Until then, there are some directory
management tasks that you must still complete in the classic portal.
Manage the same Azure AD tenants

The preview experience reads and writes to the same Azure Active Directory tenant as the classic portal and the
Office 365 Admin center. Changes that are made in any of these portals are reflected in all the other portals.
Use the same authorization logic

The preview experience uses the same authorization logic as existing Active Directory clients. Users are
authorized to make changes to directory resources based on their directory role, such as global administrator,
user administrator, and password administrator. Having a role on Azure resources or an Azure subscription
doesn't give users the authorization to manage directory resources. For more information about Azure AD
management roles, see Assigning administrator roles in Azure Active Directory.
The preview experience is optimized for global administrators. If you use the preview experience while signed in
as a user that is not a global administrator, you might have a degraded experience. For example, you might be
able to select a button that lets you begin a task that you can't complete in the directory. We will be improving
this experience soon.
Tell us what you think

You can provide feedback on the preview experience in the admin portal section of the Azure AD feedback
forum.
1 min to read
Edit on Git Hub
To sign up for Active Directory Premium, you have several options:

Azure or Office 365 - As an Azure or Office 365 subscriber, you can buy 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 (formerly Enterprise Mobility Suite) is a cost
effective way for organizations to use the following services together under one licensing plan: Active Directory
Premium, Azure Rights Management, Microsoft Intune. For more information, see the Enterprise Mobility +
Security web site. To get e free 30-day trial, click here.
Microsoft Volume Licensing - Azure Active Directory Premium is available through a Microsoft Enterprise
Agreement (250 or more licenses) or the Open Volume License (5250 licenses) program.
This topic shows you how to get started with an Azure Active Directory Premium you have purchased through the
Volume Licensing program. If you are not yet familiar with the different editions of Azure Active Directory, see
Azure Active Directory editions.
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.
Step 1: Sign up for Active Directory Premium

To sign up, see How to purchase through Volume Licensing.
Step 2: Activate your license plan

Is this your first license plan purchase through the Enterprise Volume Licensing program from Microsoft? In this
case, you get a confirmation email when your purchase has been completed. You need this email to activate your
first license plan.
On any subsequent purchase for this directory, the licenses are automatically activated in the same directory.
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. You
need to sign in with the global administrator credentials from the directory where the licenses must
be activated.
If you want to create a new Azure Active Directory 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.
Step 3: Activate your Azure Active Directory access
If you have used Microsoft Azure before, you can proceed to Step 4.
When the licenses are provisioned to 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 Suite licenses and features.
If you make an attempt to activate your access to Azure Active Directory prior to receiving the Welcome email,
you get the following error message.
If you Please try again in a few minutes once you have received the email.
New administrators in your subscription can also activate their access to the Azure classic portal through this link.
To activate your Azure Active Directory access, perform the following steps:
1. In your Welcome email, click Sign In.
2. When you have signed in successfully, you need to complete a second factor authentication in form of a
mobile verification:
The activation can take a few minutes. Once your access is active, the brown bar disappears and you are able to
click Portal.
In this case, your Azure access is limited to Azure Active Directory.
You may already have had access to Azure from prior usage; in addition, you can upgrade your Access Azure
Active Directory to full Azure access by activating additional Azure subscriptions. In these cases, the Azure classic
portal has more capabilities.
Step 4: Assign license to user accounts

Before you can start using the plan you purchased, you need to manually assign licenses to user accounts within
your organization so that they can use the rich features provided with Premium. Use the following steps to assign
licenses to users so they can use Azure Active Directory Premium features.
To assign licenses to users, perform the following steps:
1. Sign into the Azure classic portal as the global administrator of the directory you wish to customize.
2. Click Active Directory, and then select the directory where you want to assign licenses.
3. Select the Licenses tab, select Active Directory Premium or Enterprise Mobility Suite, and then click
Assign.
4. In the dialog box, select the users you want to assign licenses to, and then click the check mark icon to save
the changes.
License restrictions
Some license plans are subsets or supersets of other license plans. Typically, a user cannot be assigned a license
plan that has already been assigned to them. If it is your intention to assign a license plan that is a superset, you
need to first remove the subset license plan.
License requirements
When you assign a license to a user, you can specify a primary usage location in the properties of their account. If
a usage location is not specified, the tenants location is automatically assigned to the user.
The availability of services and features for a Microsoft cloud service varies by country or region. A service, such
as Voice over Internet Protocol (VoIP), may be available in one country or region, and not available in another.
Features within a service can be restricted for legal reasons in certain countries or regions. To see if a service or
feature is available with or without restrictions, look for your country or region on license restrictions site of a
service.
What's next
How Azure subscriptions are associated with Azure
Active Directory
This article covers information about signing in to Microsoft Azure and related issues, such as the relationship
between an Azure subscription and Azure Active Directory (Azure AD).
Accounts that you can use to sign in

Lets start with the accounts that you can use to sign in. There are two types: a Microsoft account (formerly known
as Microsoft Live ID) and a work or school account, which is an account stored in Azure AD.
MICROSOFT ACCOUNT AZURE AD ACCOUNT
The consumer identity system run by Microsoft The business identity system run by Microsoft
Authentication to services that are consumer-oriented, such Authentication to services that are business-oriented, such as
as Hotmail and MSN Office 365
Consumers create their own Microsoft accounts, such when Companies and organizations create and manage their own
they sign up for email work or school accounts
Identities are created and stored in the Microsoft account Identities are created by using Azure or another service such
system as Office 365, and they are stored in an Azure AD instance
assigned to the organization
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both
systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD
authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft
account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate
guest Microsoft accounts as well as native Azure AD accounts.
For example, here a user with a Microsoft account signs in to the Azure classic portal.
NOTE
To sign in to the Azure classic portal, msmith@hotmail.com must have a subscription to Azure. The account must be either a
Service administrator or a co-administrator of the subscription.
Because this Hotmail address is a consumer account, the sign in is authenticated by the Microsoft account
consumer identity system. The Azure AD identity system trusts the authentication done by the Microsoft account
system and will issue a token to access Azure services.
How an Azure subscription is related to Azure AD
Every Azure subscription has a trust relationship with an Azure AD instance. This means that it trusts that directory
to authenticate users, services, and devices. Multiple subscriptions can trust the same directory, but a subscription
trusts only one directory. You can see which directory is trusted by your subscription under the Settings tab. You
can edit the subscription settings to change which directory it trusts.
This trust relationship that a subscription has with a directory is unlike the relationship that a subscription has with
all other resources in Azure (websites, databases, and so on), which are more like child resources of a subscription.
If a subscription expires, then access to those other resources associated with the subscription also stops. But the
directory remains in Azure, and you can associate another subscription with that directory and continue to manage
the directory users.
Similarly, the Azure AD extension you see in your subscription doesnt work like the other extensions in the Azure
classic portal. Other extensions in the Azure classic portal are scoped to the Azure subscription. What you see in
the Azure AD extension does not vary based on subscription it shows only directories based on the signed-in
user.
All users have a single home directory which authenticates them, but they can also be guests in other directories.
In the Azure AD extension, you will see every directory your user account is a member of. Any directory that your
account is not a member of will not appear. A directory can issue tokens for work or school accounts in Azure AD
or for Microsoft account users (because Azure AD is federated with the Microsoft account system).
This diagram shows a subscription for Michael Smith after he signed up by using a work account for Contoso.
How to manage a subscription and a directory

The administrative roles for an Azure subscription manage resources tied to the Azure subscription. These roles
and the best practices for managing your subscription are covered at Assigning administrator roles in Azure Active
Directory.
By default, you are assigned the Service Administrator role when you sign up. If others need to sign in and access
services using the same subscription, you can add them as co-administrators. The Service Administrator and co-
administrators can be either Microsoft accounts or work or school accounts from the directory that the Azure
subscription is associated with.
Azure AD has a different set of administrative roles to manage the directory and identity-related features. For
example, the global administrator of a directory can add users and groups to the directory, or require multifactor
authentication for users. A user who creates a directory is assigned to the global administrator role and they can
assign administrator roles to other users.
As with subscription administrators, the Azure AD administrative roles can be either Microsoft accounts or work or
school accounts. Azure AD administrative roles are also used by other services such as Office 365 and Microsoft
Intune. For more information, see Assigning administrator roles.
But the important point here is that Azure subscription admins and Azure AD directory admins are two separate
concepts. Azure subscription admins can manage resources in Azure and can view the Active Directory extension
in the Azure classic portal (because the Azure classic portal is an Azure resource). Directory admins can manage
properties in the directory.
A person can be in both roles but this isnt required. A user can be assigned to the directory global administrator
role but not be assigned as Service administrator or co-administrator of an Azure subscription. Without being an
administrator of the subscription, this user cannot sign in to the Azure classic portal. But the user could perform
directory administration tasks using other tools such as Azure AD PowerShell or Office 365 Admin Center.
Why can't I manage the directory with my current user account?

Sometimes a user may try to sign in to the Azure classic portal using a work or school account prior to signing up
for an Azure subscription. In this case, the user will receive a message that there is no subscription for that account.
The message will include a link to start a free trial subscription.
After signing up for the free trial, the user will see the directory for the organization in the Azure classic portal but
be unable to manage it (that is, be unable to add users, or edit any existing user properties) because the user is not
a directory global administrator. The subscription allows the user to use the Azure classic portal and see the Azure
Active Directory extension, but the additional permissions of a global administrator are needed to manage the
directory.
Using your work or school account to manage an Azure subscription

that was created by using a Microsoft account
As a best practice, you should sign up for Azure as an organization and use a work or school account to manage
resources in Azure. Work or school accounts are preferred because they can be centrally managed by the
organization that issued them, they have more features than Microsoft accounts, and they are directly
authenticated by Azure AD. The same account provides access to other Microsoft online services that are offered to
businesses and organizations, such as Office 365 or Microsoft Intune. If you already have an account that you use
with those other properties, you likely want to use that same account with Azure. You will also already have an
Active Directory instance backing those properties that you will want your Azure subscription to trust.
Work or school accounts can also be managed in more ways than a Microsoft account. For example, an
administrator can reset the password of an a work or school account, or require multifactor authentication for it.
In some cases, you may want a user from your organization to be able to manage resources that are associated
with an Azure subscription for a consumer Microsoft account. For more information about how to transition to
have different accounts manage subscriptions or directories, see Manage the directory for your Office 365
subscription in Azure.
Signing in when you used your work email for your Microsoft account
If at some point of time in the past you created a consumer Microsoft account using your work email as a user
identifier, you may see a page asking you to select from either the Microsoft Azure Account system or the
Microsoft Account system.
You have user accounts with the same name, one in Azure AD and the other in the consumer Microsoft account
system. You should pick the account that is associated with the Azure subscription you want to use. If you get an
error saying a subscription does not exist for this user, you likely just chose the wrong option. Sign out and try
again. For more information about errors that can prevent sign in, see Troubleshooting "We were unable to find
any subscriptions associated with your account" errors.
Manage the directory for your Office 365 subscription in Azure

Let's say you signed up for Office 365 before you sign up for Azure. Now you want to manage the directory for the
Office 365 subscription in the Azure classic portal. There are two ways to do this, depending on whether you have
signed up for Azure or you have not.
I do not have a subscription for Azure
In this case, just sign up for Azure using the same work or school account that you use to sign in to Office 365.
Relevant information from the Office 365 account will be prepopulated in the Azure sign-up form. Your account
will be assigned to the Service Administrator role of the subscription.
I do have a subscription for Azure using my Microsoft account
If you signed up for Office 365 using a work or school account and then signed up for Azure using a Microsoft
account, then you have two directories: one for your work or school and a Default directory that was created when
you signed up for Azure.
To manage both of the directories in the Azure classic portal, complete these steps.
NOTE
These steps can only be completed while a user is signed in with a Microsoft account. If the user is signed in with a work or
school account, the option Use existing directory is not available because a work or school account can be authenticated
only by its home directory (that is, the directory where the work or school account is stored, and which is owned by the
work or school).
1. Sign in to the Azure classic portal using your Microsoft account.

2. Click New > App services > Active Directory > Directory > Custom Create.
3. Click Use existing directory and check I am ready to be signed out now and click the check mark to
complete the action.
4. Sign in to the Azure classic portal using an account that has global admin rights for the work or school
directory.
5. When prompted to Use the Contoso directory with Azure?, and click continue.
6. Click Sign out now.
7. Sign back in to the Azure classic portal using your Microsoft account. Both directories will appear in the Active
Directory extension.
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 to assign roles in Azure AD, see Assigning administrator roles in Azure Active
Directory
Sign up for Azure as an organization
What is Microsoft Azure Active Directory licensing?
Description
Azure Active Directory (Azure AD) is Microsoft's Identity as a Service (IDaaS) solution and platform. Azure AD is
offered in a number of functional and technical versions ranging from Azure AD Free, which is available with any
Microsoft service such as Office 365, Dynamics, Microsoft Intune and Azure (Azure AD does not generate any
consumption charges in this mode), to Azure AD paid versions such as Enterprise Mobility Suite (EMS), Azure AD
Premium and Basic, as well as Azure Multi-Factor Authentication (MFA). Like many of Microsoft online services,
most Azure AD paid versions are delivered through per-user entitlements as they are in Office 365, Microsoft
Intune, and Azure AD. In these cases, the service purchase is represented with one or more subscriptions, and each
subscription includes a pre-purchase number of licenses in your tenant. Per-user entitlements are achieved
through license assignment, creating a link between the user and the product, enabling the service components for
the user, and consuming one of the prepaid licenses.
Try Azure AD premium now.
NOTE
Azure AD administration portal is a part of the Azure classic portal. While using Azure AD does not require any Azure
purchases, accessing this portal requires an active Azure subscription or an Azure trial subscription.
For a broad overview of Azure AD service capabilities, see What is Azure AD. Learn more about Azure AD service
levels
NOTE
Azure pay as you go subscriptions are different: while also represented in your directory, these subscriptions enable creation
of Azure resources and map them to your payment method. In this case there are NO license counts associated with the
subscription. Users' association with the subscription, the users' access to managing subscription resources, is achieved by
granting them permissions to operate on Azure resources mapped to the subscription.
How does Azure AD licensing work?

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.
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. Your subscription information,
including status, next lifecycle event, and the number of assigned or available licenses is available through the
Azure classic portal under the Licenses tab for the specific directory. This is also to best place to manage your
license assignments.
Each subscription consists of one or more service plans, each mapping the included functional level of the service
type; for example, Azure AD, Azure MFA, Microsoft Intune, Exchange Online, or SharePoint Online. Azure AD license
management does NOT require service plan level management. This is different from Office 365 which relies on
this advanced configuration mode to manage access to included services. Azure AD relies on in service
configuration, to enable features and manage individual permissions.
In general, Azure AD subscription information is managed through the Azure classic portal, under the Licenses tab
for the specific directory. Azure AD subscriptions, with the exception of Azure AD Premium, do NOT show up in the
Office portal.
IMPORTANT
Azure AD Premium and Basic, as well as Enterprise Mobility Suite subscriptions, are confined to their provisioned
directory/tenant. Subscriptions cannot be split between directories or used to entitle users in other directories. Moving a
subscription between directories is possible but requires submitting a support ticket or cancellation and re-purchase in the
case of direct purchases.
When purchasing Azure AD or Enterprise Mobility Suite through Volume Licensing subscription activation will happen
automatically when the agreement includes other Microsoft Online services, e.g. Office 365.
Paid Azure AD features span the breadth of the directory. Examples include:
Group-based assignment to applications, which is enabled under the specific application you are managing.
Advanced and self-service group management capabilities are available under the directory configuration or
within the specific group.
Premium security reports are on the Reporting tab
Cloud application discovery shows up in the Azure portal under Identity.
Assigning licenses
While obtaining a subscription is all you need to configure paid capabilities, using your Azure AD paid features
requires distributing licenses to the right individuals. In general, any user who should have access to or who is
managed through an Azure AD paid feature must be assigned a license. A license assignment is a mapping
between a user and a purchased service, such as Azure AD Premium, Basic, or Enterprise Mobility Suite.
Managing which users in your directory should have a license is simple. It can be accomplished by assigning to a
group to create assignment rules through the Azure AD administration portal or by assigning licenses directly to
the right individuals through a portal, PowerShell, or APIs. When assigning licenses to a group, all group members
will be assigned a license. If users are added or removed from the group they will be assigned or removed the
appropriate license. Group assignment can utilize any group management available to you and is consistent with
group-based assignment to applications. Using this approach, you can set up rules such that all users in your
directory are automatically assigned, ensure that everyone with the appropriate job title has a license or even
delegate the decision to other managers in the organization.
With group-based license assignment, any user missing a usage location will inherit the directory location during
assignment. This location can be changed by the administrator at any time. In cases where the automated
assignment failed due to error, the user information under that license type will reflect that state.
Getting started with Azure AD licensing

Getting started with Azure AD is easy; you can always create your directory as a part of signing up to a free Azure
trial. Learn more about signing up as an organization. The following can help you make sure that your directory is
best aligned with other Microsoft services you may be consuming or are planning to consume, and your goals in
obtaining the service.
Here are a couple of best practices:
If you are already using any of Microsoft's organizational services, you already have an Azure AD directory. In
this case, you should continue to use the same directory for other services, so that core identity management,
including provisioning and hybrid SSO, can be utilized across the services. Your users will have a single logon
experience and will benefit from richer capabilities across the services. As a result, if you decide to buy an Azure
AD paid service for your workforce, we recommend that you use the same directory to do this.
If you are planning to use Azure AD for a different set of users (partners, customers, and so on), or if you would
like to evaluate Azure AD services and would like to do that in isolation of your production service, or if you are
looking to setup a sandbox environment for your services, we recommend that you first create a new directory
through the Azure Azure classic portal. Learn more about creating a new Azure AD directory in the Azure classic
portal. The new directory will be created with your account as an external user with global administrator
permissions. When you sign in to the Azure classic portal with this account, you will be able to see this directory
and access all directory administration tasks. We recommend that you create a local account with appropriate
privileges to manage other Microsoft services (those not accessible through the Azure classic portal). Learn
more about creating user accounts in Azure AD.
NOTE
Azure AD supports external users, which are user accounts in an instance of Azure AD that were created using either a
Microsoft Account (MSA) or an Azure AD identity from another directory. While we are busy extending this capability into all
of Microsoft's organizational services, right now these accounts are not supported in some of the services' experiences; for
example, the Office 365 administration portal does not currently support these users. As a result, external users with
Microsoft accounts will not be able to access the Office 365 administration portal at all, while external users from other Azure
AD directories will be ignored. In the latter case, only the users local account, the Azure AD or Office 365 directory where the
user was originally created, would be accessible through these experiences.
As indicated, Azure AD has different paid versions. These versions have some minor differences in their purchase
availability:
MPN USE DIRECT

PRODUCT EA/VL OPEN CSP RIGHTS PURCHASE TRIAL
Enterprise X X X X X
Mobility Suite
Azure AD X X X X X
Premium
Azure AD X X X X
Basic
Select one or more license trials

In all cases, you can activate an Azure AD Premium or Enterprise Mobility Suite trial subscription by selecting the
specific trial you want on the Licenses tab in your directory. Either trial contains a 30-day subscription with 100
licenses.
Assign licenses
Once the subscription is active, you should assign a license to yourself and refresh the browser to ensure you are
seeing all your features. The next step is to assign licenses to the users that will need to access or be included in
paid Azure AD features. As we mentioned above in "Assigning licenses," the best way to do this is to identify the
group representing the desired audience and assign it to the license; in this way, users who are added or removed
from the group over its lifecycle will be assigned to or removed from the license.
To assign a license to a group or individual users, select the license plan you would like to assign and click Assign
on the command bar.
Once in the assignment dialog for the selected plan, you can select users and adding them to the Assign column
on the right. You can page through the user list or search for specific individuals using the looking glass on the top
right of the user grid. To assign groups, select "Groups" from the Show menu and then click the check button on
the right to refresh the assignments that are displayed.
You can now search or page through groups and add them to the Assign column in the same way. You can use
these to assign a combination of users and groups in a single operation. To complete the assignment process, click
the check button in the bottom right corner of the page.
When a group is assigned, its members inherit the licenses within 30 minutes, but usually within 1-2 minutes.
Assignment errors can occur during Azure AD license assignment, but are relatively rare. 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 will require removing the previous one.
Exceeded available licenses - when the number of users in assigned groups exceed available licenses, the users'
assignment status will reflect a failure to assign due to missing licenses.
View assigned licenses
A summary view of assigned licenses including available, assigned, and next subscription lifecycle event are
displayed on the Licenses tab.
A detailed list of assigned users and groups, including assignment status and path (direct or inherited from one or
more groups) is available when navigating into a license plan.
Removing licenses is just as easy as assigning them. If the user is directly assigned or for an assigned group, you
can remove the license by selecting the license type, selecting Remove, adding the user or group to the remove
list, and confirming the action. Alternatively, you can open a license type, select the specific user or group, and tap
Remove on the command bar. To end a users inheritance of a license from a group, simply remove the user from
the group.
Extending trials
Trial extensions for customers are available as self-service through the Office 365 portal. A customer admin can
navigate to the Office portal (access depends on permissions for the Office portal) and select your Azure AD
Premium trial. Click the Extend trial link and follow the instructions. You will need to enter a credit card, but it will
not be charged.
Customers can also request a trial extension by submitting a support request. A customer admin can navigate to
the Office 365 portal support page (access depends on permissions for the Office support page). On this page
select Subscriptions and Trials under Features and Trial questions under Symptom. Finally, enter information
on the circumstances
Next steps
Now you might be ready to configure and use some Azure AD Premium features.
Self-service password reset
Self-service group management
Azure AD Connect heath
Group assignment to applications
Azure Multi-Factor Authentication
Direct purchase of Azure AD Premium licenses
Until recently, you could only sign up for a new Microsoft Azure subscription using your Microsoft account
(Windows Live ID). Azure now supports using either of the following two account methods to sign up:
Microsoft accounts (created by you for personal use) - Provide access to all consumer-oriented Microsoft
products and cloud services, such as Outlook (Hotmail), Messenger, OneDrive, MSN, Xbox LIVE, or Office 365.
Signing up for an Outlook.com mailbox automatically creates a Microsoft account. After a Microsoft account is
created, it can be used to access consumer-related Microsoft cloud services or Azure. Learn more
Work or school accounts (issued by an admin for business/academic use) - Provide access to all small,
medium, and enterprise business-level Microsoft cloud services, such as Azure, Microsoft Intune, or Office
365. When you sign up to one of these services as an organization, a cloud-based directory is automatically
provisioned in Azure Active Directory to represent your organization. Learn more
After this directory has been created, an admin can then create users and assign licenses to them based on
which cloud service subscriptions they need access to, such as Azure.
Want to sign up for Azure as an organization? Sign up now
Additional Resources
Microsoft Azure blog
What is Azure AD?
Use your on-premises identity infrastructure in the cloud
Azure Active Directory FAQ
Azure Active Directory is a comprehensive Identity as a Service (IDaaS) solution that spans all aspects of identity,
access management, and security.
For more details, see What is Azure Active Directory?.
Accessing Azure and Azure Active Directory

Q: Why do I get No subscriptions found when I try to access Azure AD in the Azure classic portal
(https://manage.windowsazure.com)?
A: Accessing the Azure classic portal requires each user to have permissions on an Azure subscription. If you have a
paid Office 365 or Azure AD navigate to http://aka.ms/accessAAD for a one-time activation step, otherwise you will
need to activate a full Azure trial or a paid subscription.
For more details, see:
How Azure subscriptions are associated with Azure Active Directory
Manage the directory for your Office 365 subscription in Azure
Q: Whats the relationship between Azure AD, Office 365, and Azure?
A: Azure Active Directory provides you with common identity and access capabilities to all Microsoft online
services. Whether you are using Office 365, Microsoft Azure, Intune or others, you are already using an Azure AD to
enable sign-on and access management for all of these services.
In fact, all the users you have enabled for Microsoft Online services are defined as user accounts in one or more
Azure AD instances. You can enable these accounts for free Azure AD capabilities such as cloud application access.
Additionally, Azure AD paid services (e.g.: Azure AD basic, Premium, EMS, etc.) complement other Online services
such as Office 365 and Microsoft Azure with comprehensive enterprise scale management and security solutions.
Q: Why can I sign-in to the Azure portal but not the classic portal? A: The new Azure portal does not require
a valid subscription whereas the classic portal does require you to have a valid subscription. If you do not have a
subscription, you will not be able to sign-in to the classic portal.
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
Administrator 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 using the same subscription, you can add them as co-administrators. This role has the same
access privileges as the Service Administrator, but cant change the association of subscriptions to Azure
directories. For additional information on Subscription Administrators see here. and here
Azure AD has a different set of administrative roles to manage the directory and identity-related features. These
administrators will have access to various features in the Azure portal or Azure classic portal and, depending on
their role, will be able to create or edit users, assign administrative roles to others, reset user passwords, manage
user licenses, and manage domains, among other things. For additional information on Azure AD Directory
Administrators and their roles see here.
Getting started with Hybrid Azure AD
Q: How can I connect my on-premises directory to Azure AD?
A: You can connect your on-premises directory to Azure AD using Azure AD Connect.
For more details, 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 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 ADFS or by
configuring password hash sync. You can easily deploy both options using the Azure AD Connect configuration
wizard.
For more details, see Integrating your on-premises identities with Azure Active Directory.
Q: Does Azure Active Directory provide a self-service portal for users in my organization?
A: Yes, Azure Active Directory 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 the Introduction to the Access Panel.
Q: Does Azure AD help me manage my on-premises infrastructure?

A: Yes, it does. The Azure AD Premium edition provides you with Connect Health. Azure AD Connect Health helps
you monitor and gain insight into your on-premises identity infrastructure and the synchronization services.
For more details, 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? (AKA, I would like to use Azure AD
SSPR with password write-back but I dont want my passwords stored in the cloud?)
A: You do not need to synchronize your AD passwords to Azure AD in order to enable write-back. In a federated
environment, Azure AD 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 AD on-premises?

A: Password write-back operates in real-time.
For more details, see Getting started with Password Management
Q: Can I use password write-back with passwords that are managed by an administrator?
A: Yes, if you have password write-back enabled, the password operations performed by an administrator 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 cannot 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. If your organization has enabled self-service password
reset then you can try this. This may or may not work depending on how self-serive password reset has been
configured. For more information see How does the password reset portal work.
For Office 365 users, your administrator can reset the password using the steps outlined here.
For Azure AD accounts, administrators can reset passwords using one of the following:
Reset accounts in the Azure portal
Reset accounts in the classic portal
Using PowerShell
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 over 2600 pre-integrated applications from Microsoft, application service providers, or partners.
All pre-integrated applications support SSO. SSO enables you to 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 you want. Depending on your applications
capabilities and your preferences, you can configure SSO and automated provisioning.
For more details, see:
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 into applications using Azure Active Directory?

A: Azure Active directory 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-on 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 Active Directory enables authentication and single sign-on to
applications?
A: Azure Active Directory 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.
For more information, see:
Authentication Scenarios for Azure AD
Active Directory Authentication Protocols
How does single sign-on with Azure Active Directory work?
Q: Can I add applications Im 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 you are accessing your SaaS apps in Azure Active
Directory. There is no need for a VPN or changing your network infrastructure.
For more details, see How to provide secure remote access to on-premises applications.
Q: How do I require MFA for users accessing 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 MFA at all times, or when users are not connected to the local network.
For more details, see Securing access to Office 365 and other apps connected to Azure Active Directory.
Q: What is Automated User Provisioning for SaaS Apps?

A: Azure Active Directory allows you to automate the creation, maintenance, and removal of user identities in many
popular cloud (SaaS) applications.
For more information, see Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active
Directory
Q: Can I setup a secure LDAP connection with Azure Active Directory? A: No. Azure AD does not support
using the LDAP protocol.
List of Tutorials on How to Integrate SaaS Apps with
Azure Active Directory
To help you integrate all of your cloud (SaaS) applications with Azure Active Directory, we have developed a
collection of tutorials that show you each of the necessary configuration steps.
For the comprehensive list of SaaS apps that have been pre-integrated into Azure AD, please see the Active
Directory Marketplace.
List of Tutorials
LOGO APP NAME
&frankly
@Task
10,000ft Plans
15Five
23 Video
360 Online
8x8 Virtual Office
Abintegro
Adaptive Suite
LOGO APP NAME
Adobe EchoSign
ADP eTime
ADP GlobalView
Aha!
AirWatch
Alcumus Info Exchange
Allocadia
Amazon Web Services (AWS)
Anaplan
AnswerHub
AppBlade
AppDynamics
Aravo
LOGO APP NAME
ArcGIS
Ariba
Asana
Asset Bank
Atlassian Cloud
Atomic Learning
Autotask
Bamboo HR
BeeLine
Benefitsolver
BenSelect
BetterWorks
BGS Online
LOGO APP NAME
Bime
Birst Agile Business Analytics
Blackboard Learn - Shibboleth
Blackboard Learn
BlueJeans
Bonus.ly
Boomi
Box
Brightspace by Desire2Learn
Bynder
CA PPM
Canvas LMS
Capriza
LOGO APP NAME
Central Desktop
Ceridian Dayforce HCM
Certify
Cezanne HR Software
Cherwell
Chromeriver
Cimpl
Cisco Spark
Cisco Webex
Citrix GoToMeeting
Citrix ShareFile
Clarizen
Clever
LOGO APP NAME
ClickTime
Cloud Management Portal for Microsoft Azure
CloudPassage
Concur
Condeco
Cornerstone OnDemand
Coupa
CS Stars
Degreed
Deputy
Directions on Microsoft
DocuSign
Domo
LOGO APP NAME
Dow Jones Factiva
Dropbox for Business
Druva
e-Builder
eDigitalResearch
Egnyte
EmpCenter
Envoy
EthicsPoint Incident Management (EPIM)
eTouches
EverBridge
Evidence.com
Expensify
LOGO APP NAME
Fieldglass
FileCloud
Flatter Files
FM:Systems
Freshdesk
FreshGrade
FreshService
Front
Fuse
GaggleAMP
Gigya
Google Apps
Greenhouse
LOGO APP NAME
HackerOne
Halogen Software
Halosys
Heroku
Hightail
HireVue
Hosted Graphite
HPE SaaS
HR2day by Merces
Huddle
IBM Kenexa Survey Enterprise
Icertis Contract Management Platform
ICIMS
LOGO APP NAME
IdeaScale
Igloo Software
Image Relay
Innotas
InsideView
Insperity ExpensAble
Intacct
Intralinks
ITRP
Jitbit Helpdesk
Jive
Jobscience
JobScore
LOGO APP NAME
Jostle
Keylight
Kindling
Kintone
Kiteworks
KnowBe4
Kontiki
Kronos
Kudos
Learning at Work
Learningpool
LearnUpon
Lesson.ly
LOGO APP NAME
Lifesize Cloud
Litmos
LogicMonitor
Lucidchart
Lynda.com
Marketo
MCM
M-Files
Mimecast Admin Console
Mimecast Personal Portal
Mindflash
Mixpanel
MOVEit Transfer
LOGO APP NAME
Moxtra
Mozy Enterprise
Namely
NetDocuments
Netsuite
New Relic
Nexonia
Nomadesk
Novatus
O. C. Tanner - AppreciateHub
OfficeSpace Software
Onit
OpsGenie
LOGO APP NAME
Optimizely
Origami
Overdrive Books
Pacific Timesheet
Pagerduty
Panopto
Panorama9
Pantheon
People
PerformanceCentre
Picturepark
Pluralsight
PolicyStat
LOGO APP NAME
PostBeyond
Predictix Assortment Planning
Predictix Ordering
Predictix Price Reporting
Printix
Projectplace
Promapp
Proofpoint on Demand
Qlik Sense Enterprise
Qualtrics
Questetra BPM Suite
QuickHelp
Rally Software
LOGO APP NAME
Recognize
RedVector
Replicon
Reward Gateway
RightAnswers
RightScale
RunMyProcess
Salesforce Sandbox
Salesforce
Samanage
SanSan
SAP Business ByDesign
SAP Cloud for Customer

LOGO APP NAME
SAP HANA Cloud Platform
SAP NetWeaver
SCC LifeCycle
Sciforma
SciQuest Spend Director
ScreenSteps
SD Elements
SECURE DELIVER
ServiceNow
ShiftPlanning
Showpad
SilkRoad Life Suite
SimpleNexus
LOGO APP NAME
Skilljar
Skydesk Email
Slack
Small Improvements
SmarterU
Soonr Workplace
Splunk Enterprise and Splunk Cloud
Spring CM
Sprinklr
StatusPage
SuccessFactors
SugarCRM
SumoLogic
LOGO APP NAME
Syncplicity
Synergi
Tableau Online
Tableau Server
TalentLMS
Tangoe Command Premium Mobile
TargetProcess
TeamSeer
The Funding Portal
Thirdlight
Thoughtworks Mingle
ThousandEyes
Tidemark
LOGO APP NAME
TigerText Secure Messenger
TimeOffManager
Tinfoil Security
TiViTz
TOPdesk - Public
TOPdesk - Secure
Trakopolis
Trakstar
Trello
UltiPro
UserEcho
UserVoice
Veracode
LOGO APP NAME
Veritas Enterprise Vault.cloud SSO
Voyance
vxMaintain
Weekdone
Wikispaces
Wizergos Productivity Software
Work.com
Workday Inbound Synchronization
Workday
Workplace by Facebook
Workrite
xMatters OnDemand
Yardi eLearning
LOGO APP NAME
Yonyx Interactive Guides
YouEarnedIt
Zendesk
Zoho Mail
Zoom
Zscaler Beta
Zscaler One
Zscaler Two
Zscaler ZSCloud
Zscaler
Related Articles
Article Index for Application Management in Azure Active Directory
List of Tutorials on How to Integrate SaaS Apps
Add new users to Azure Active Directory preview
This article explains how to add new users in your organization in the Azure Active Direstory (Azure AD) preview.
What's in the preview?
1. Sign in to the Azure portal with an account that's a global admin for the 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 All users, and then select Add.
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 "foo.onmicrosoft.com" domain name, or a verified, non-federated
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 the Profile blade, the Groups blade, or the Directory
role blade for the user. For more information about user and administrator roles, see Assigning administrator
roles in Azure AD.
7. On the User blade, select Create.
8. Securely distribute the generated password to the new user so that the user can sign in.
What's next
Add an external user
Reset a user's password in the new Azure portal
Change a user's work information
Delete a user in your Azure AD
Assign a user to a role in your Azure AD
Add new users or users with Microsoft accounts to
Add users to populate your directory. This article explains how to add new users in your organization, and how to
add users who have Microsoft accounts. For more information about adding users from other directories in Azure
Active Directory or adding users from partner companies, see Add users from other directories or partner
companies in Azure Active Directory. Added users don't have administrator permissions by default, but you can
assign roles to them at any time.
Add a user
1. Sign in to the Azure classic portal with an account that's a global admin for the directory.
2. Select Active Directory, and then select the name of your organization directory.
3. Select the Users tab, and then, in the command bar, select Add User.
4. On the Tell us about this user page, under Type of user, select either:
New user in your organization adds a new user account in your directory.
User with an existing Microsoft account adds an existing Microsoft consumer account to your
directory (for example, an Outlook account)
5. Depending on Type of user, enter a user name (for new user) or an email address (for a user with a Microsoft
account).
6. On the user Profile page, provide a first and last name, a user-friendly name, and a user role from the Roles
list. For more information about user and administrator roles, see Assigning administrator roles in Azure AD.
Specify whether to Enable Multi-Factor Authentication for the user.
7. On the Get temporary password page, select Create.
IMPORTANT
If your organization uses more than one domain, you should know about the following issues when you add a user account:
TO add user accounts with the same user principal name (UPN) across domains, first add, for example,
geoffgrisso@contoso.onmicrosoft.com, followed by geoffgrisso@contoso.com.
Don't add geoffgrisso@contoso.com before you add geoffgrisso@contoso.onmicrosoft.com. This order is important, and
can be cumbersome to undo.
Change user information

You can change any user attribute except for the object ID.
1. Open your directory.
2. Select the Users tab, and then select the display name of the user you want to change.
3. Complete your changes, and then click Save.
If the user that you're changing is synchronized with your on-premises Active Directory service, you can't change
the user information using this procedure. To change the user, use your on-premises Active Directory
management tools.
Guest user management and limitations
Guest accounts are users from other directories who were invited to your directory to access SharePoint
documents, applications, or other Azure resources. A guest account in your directory has its underlying UserType
attribute set to "Guest." Regular users (specifically, members of your directory) have the UserType attribute
"Member."
Guests have a limited set of rights in the directory. These rights limit the ability for Guests to discover information
about other users in the directory. However, guest users can still interact with the users and groups associated
with the resources they're working on. Guest users can:
See other users and groups associated with an Azure subscription to which they're assigned
See the members of groups to which they belong
Look up other users in the directory, if they know the full email address of the user
See only a limited set of attributes of the users they look up--limited to display name, email address, user
principal name (UPN), and thumbnail photo
Get a list of verified domains in the directory
Consent to applications, granting them the same access that Members have in your directory
Set guest user access policies

The Configure tab of a directory includes options to control access for guest users. These options can be changed
only in Azure classic portal by a directory global administrator. Currently, there's no PowerShell or API method.
To open the Configure tab in the Azure classic portal, select Active Directory, and then select the name of the
directory.
Then you can edit the options to control access for guest users.
What's next
Add users from other directories or partner companies in Azure Active Directory
Administering Azure AD
Manage passwords in Azure AD
Manage groups in Azure AD
Add users from other directories or partner
companies in Azure Active Directory preview
This article explains how to add users either from other directories in Azure Active Directory (Azure AD) preview or
from partner companies. What's in the preview? For information about adding new users in your organization, and
adding users who have Microsoft accounts, 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.
Add a user
3. On the Users and groups blade, select Users, and then select Add.
4. On the User blade, provide a display name in Name and the user's sign-in name in User name.
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, select Profile to add the users first and last name, a job title, and a department name.
Select Groups to add the user to one or more groups.
Select Organizational role to assign the user to a role from the Roles list. For more information
about user and administrator roles, see Assigning administrator roles in Azure AD.
7. Select Create.
8. Securely distribute the generated password to the new user so that the user can sign in.
IMPORTANT
If you change information for a user whose identity is synchronized with your on-premises Active Directory
service, you can't change the user information in the Azure classic portal. To change the user information, use your
on-premises Active Directory management tools.
What's next
Add a user
Add users from other directories or partner
companies in Azure Active Directory
This article explains how to add users from other directories in Azure Active Directory or add users from partner
companies. For information about adding new users in your organization, and adding users who have Microsoft
accounts, 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.
Add a user
1. Sign in to the Azure classic portal with an account that's a global admin for the directory.
2. Select Active Directory, and then open your directory.
3. Select the Users tab, and then, in the command bar, select Add User.
4. On the Tell us about this user page, under Type of user, select either:
User in another Azure AD directory adds a user account to your directory that's sourced from
another Azure AD directory. You can select a user in another directory only if you're also a member of
that directory.
Users in partner companies - to invite and authorize partner company users to your directory (See
Azure Active Directory B2B collaboration). You'll need to upload a CSV file specifying email addresses.
5. On the user Profile page, provide a first and last name, a user-friendly name, and a user role from the Roles
list. For more information about user and administrator roles, see Assigning administrator roles in Azure AD.
Specify whether to Enable Multi-Factor Authentication for the user.
6. On the Get temporary password page, select Create.
IMPORTANT
If you change information for a user whose identity is synchronized with your on-premises Active Directory
service, you can't change the user information in the Azure classic portal. To change the user information, use your
on-premises Active Directory management tools.
Add external users

You can also add users from another Azure AD directory to which you belong, or from partner companies by
uploading a CSV file. To add an external user, for Type of User, specify User in another Microsoft Azure AD
directory or Users in partner companies.
Users of either type are sourced from another directory and are added as external users. External users can
collaborate with other users in a directory without any requirement to add new accounts and credentials. External
users authenticate with their home directory when they sign in, and that authentication works for any other
directories to which they have been added.
External user management and limitations
When you add a user from another directory to your directory, that user is an external user in your directory. The
display name and user name are copied from their home directory and used for the external user in your directory.
From then on, properties of the external user account are entirely independent. If property changes are made to
the user in their home directory, those changes aren't propagated to the external user account in your directory.
The only linkage between the two accounts is that the user always authenticates against their home directory or
with their Microsoft account. That's why you don't see an option to reset the password or enable multi-factor
authentication for an external user. Currently, the authentication policy of the home directory or Microsoft account
is the only one that's evaluated when the user signs in.
NOTE
You can still disable the external user in the directory, which blocks access to your directory.
If a user is deleted in their home directory or they cancel their Microsoft account, the external user still exists in
your directory. However, the user in your directory can't access resources because they can't authenticate with a
home directory or Microsoft account.
Services that currently support access by Azure AD external users
Azure classic portal: allows an external user who's an administrator of multiple directories to manage each of
those directories.
SharePoint Online: if external sharing is enabled, allows an external user to access SharePoint Online
authorized resources.
Dynamics CRM: if the user is licensed via PowerShell, allows an external user to access authorized resources in
Dynamics CRM.
Dynamics AX: if the user is licensed via PowerShell, allows an external user to access authorized resources in
Dynamics AX. The limitations for Azure AD external users apply to external users in Dynamics AX as well.
Known limitations of Azure AD external users
External users who are admins can't add users from partner companies to directories (B2B collaboration)
outside their home directory
External users can't consent to multi-tenant applications in directories outside of their home directory
PowerBI doesn't currently support access by external users
Office Portal doesn't support licensing external users
With respect to Azure AD PowerShell, external users are logged into their home directory and cannot manage
directories in which they are external users
What's next
Add new users to Azure Active Directory
Delete a user from a directory in Azure Active
Directory preview
This article explains how to delete a user from a directory in Azure Active Directory (Azure AD) preview. What's in
the preview? For information about adding new users to your organization, see Add new users to Azure Active
Directory preview.
To delete a user
3. On the Users and groups blade, select Users.

4. On the Users and groups - Users blade, select a user from the list.
5. On the blade for the selected user, select Overview, and then in the command bar, select Delete.
Next steps
Reset the password for a user in Azure Active Directory preview
Assign a user to administrator roles in Azure Active Directory preview
Add or change profile information for a user in Azure Active Directory preview
Delete a user from a directory in Azure Active Directory preview
Add or change profile information for a user in
Azure Active Directory preview
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) preview. What's in the preview? For information
about adding new users in your organization, see Add new users to Azure Active Directory.
To change profile information


5. On the blade for the selected user, select Profile.
6. Add or change the profile information. Then, in the command bar, select Save.
Next steps
Reset the password for a user in Azure Active
Directory preview
How to reset the password for a user


5. On the blade for the selected user, select Overview, and then in the command bar, select Reset password.
6. On the Reset password blade, select Reset password.
What's next
Add a user
Add or change work information for a user in Azure
Active Directory preview
This article explains how to add or change work information such as phone numbers or department names for a
user in Azure Active Directory (Azure AD) preview. What's in the preview? For information about adding new
users in your organization, see Add new users to Azure Active Directory.
To change work information


5. On the blade for the selected user, select Work Info.
6. Add or change the work information. Then, in the command bar, select Save.
Next steps
Sharing accounts with Azure AD
Overview
Sometimes organizations need to use a single username and password for multiple people. This typically happens
in two cases:
When accessing applications that require a unique login and password for each user, whether on-premises apps
or consumer cloud services ( e.g. corporate social media accounts).
When creating multi-user environments. You may have a single, local account that has elevated privileges and
can be used to do core setup, administration, and recovery activities (e.g. the local "global administrator"
account for Office 365 or the root account in Salesforce).
Traditionally, these accounts would be shared by distributing the credentials (username/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 will
resort to risky practices. (e.g. writing down passwords).
You can't tell who has access to an application.
You can't tell who has accessed an application.
When you need to remove access to an application, you have to update the credentials and re-distribute 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 is the same account that 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 may 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, with some password SSO applications, you have the option
to have Azure AD periodically rollover (update) the password using large, complex passwords, increasing the
account security. The administrator can easily grant or revoke access to an application and also know who has
access to the account and who 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 will 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
Protecting apps with conditional access
Self-service group management/SSAA
Managing 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 preview 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 premise
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
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 for access management

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 new group in Azure Active Directory
preview
This article explains how to create and populate a new group in the Azure Active Directory (Azure AD) preview.
What's in the preview? 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.
Additional information
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
Managing groups in Azure Active Directory
One of the features of Azure Active Directory (Azure AD) user management is the ability to create groups of users.
You use a group to perform management tasks such as assigning licenses or permissions to a number of users at
once. You can also use groups to assign access permission to
Resources such as objects in the directory
Resources external to the directory such as SaaS applications, Azure services, SharePoint sites, or on-premises
resources
In addition, a resource owner can also assign access to a resource to an Azure AD group owned by someone else.
This assignment grants the members of that group access to the resource. Then, the owner of the group manages
membership in the group. Effectively, the resource owner delegates to the owner of the group the permission to
assign users to their resource.
How do I create a group?

Depending on the services to which your organization has subscribed, you can create a group using one of the
following:
the Azure classic portal
the Office 365 account portal
the Windows Intune account portal
We'll describe tasks as performed in the Azure classic portal. For more information about using non-Azure portals
to manage your Azure AD directory, see Administering your Azure AD directory.
1. In the Azure classic portal, select Active Directory, and then select the name of the directory for your
organization.
2. Select the Groups tab.
3. Select Add Group.
4. In the Add Group window, specify the name and the description of a group.
How do I add or remove individual users in a security group?

To add an individual user to a group
organization.
3. Open the group to which you want to add members. Open the Members tab of the selected group if it not
already displaying.
4. Select Add Members.
5. On the Add Members page, select the name of the user or a group that you want to add as a member of this
group. Make sure that this name is added to the Selected pane.
To remove an individual user from a group
organization.
3. Open the group from which you want to remove members.
4. Select the Members tab, select the name of the member that you want to remove from this group, and then
click Remove.
5. Confirm at the prompt that you want to remove this member from the group.
How can I manage the membership of a group dynamically?

In Azure AD, you can very easily set up a simple rule to determine which users are to be members of the group. A
simple rule is one that makes only a single comparison. For example, if a group is assigned to a SaaS application,
you can set up a rule to add users who have a job title of "Sales Rep." This rule then grants access to this SaaS
application to all users with that job title in your directory.
When any attributes of a user change, the system evaluates all dynamic group rules in a directory to see if the
attribute change of the user would trigger any group adds or removes. If a user satisfies a rule on a group, they
are added as a member to that group. If they no longer satisfy the rule of a group they are a member of, they are
removed as a members from that group.
NOTE
You can set up a rule for dynamic membership on security groups or Office 365 groups. Nested group memberships aren't
currently supported for group-based assignment to applications.
Dynamic memberships for groups require an Azure AD Premium license to be assigned to
The administrator who manages the rule on a group
All members of the group
To enable dynamic membership for a group

organization.
2. Select the Groups tab, and open the group you want to edit.
3. Select the Configure tab, and then set Enable Dynamic Memberships to Yes.
4. Set up a simple single rule for the group to control how dynamic membership for this group functions. Make
sure the Add users where option is selected, and then select a user property from the list (for example,
department, jobTitle, etc.),
5. Next, select a condition (Not Equals, Equals, Not Starts With, Starts With, Not Contains, Contains, Not Match,
Match).
6. Specify a comparison value for the selected user property.
To learn about how to create advanced rules (rules that can contain multiple comparisons) for dynamic group
membership, see Using attributes to create advanced rules.
Azure Active Directory preview cmdlets for group
management
The following document will provide you with examples of how to use PowerShell to manage your groups in
Azure Active Directory (Azure AD). It also provides information on how to get set up with the Azure AD PowerShell
preview module. First, you must download the Azure AD PowerShell module.
Installing the Azure AD PowerShell module

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

---------- ------- ---- ----------------
Binary 1.1.146.0 azureadpreview {Add-AzureADAdministrati...}
Now you can start using the cmdlets in the module. For a full description of the cmdlets in the AzureAD Preview
module, please refer to the online reference documentation.
Connecting to the directory

Before you can start managing groups using Azure AD PowerShell preview cmdlets, you must connect your
PowerShell session to the directory you want to manage. To do this, use the following command:
PS C:\Windows\system32> Connect-AzureAD
The cmdlet will prompt 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 will return 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 preview cmdlets to manage groups in your directory.
Retrieving groups
To retrieve existing groups from your directory you can 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 will return all groups in the connected directory.

You can use the -objectID parameter to retrieve a specific group for which you specify the groups objectID:
PS C:\Windows\system32> get-azureadgroup -ObjectId e29bae11-4ac0-450c-bc37-6dae8f3da61b
The cmdlet will now return 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 that the AzureAD PowerShell cmdlets implement the OData query standard, more information can be found
here.
Creating 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"
Updating groups
To update an existing group, use the Set-AzureADGroup cmdlet. In this example, were changing the DisplayName
property of the group Intune Administrators. First, were 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, were 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 : {}
Deleting 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
Managing members of groups

If you need 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.
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
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

To verify the group membership(s) 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
Managing 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:
PS C:\Windows\system32> Get-AzureADGroupOwner -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df
The cmdlet will return 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 Remove-AzureADGroupOwner:
PS C:\Windows\system32> remove-AzureADGroupOwner -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -OwnerId

e831b3fd-77c9-49c7-9fca-de43e109ef67
Next steps
You can find more Azure Active Directory PowerShell documentation at Azure Active Directory Cmdlets.
Manage the members for a group in Azure Active
Directory preview
This article explains how to manage the members for a group in Azure Active Directory (Azure AD) preview. What's
in the preview?
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.
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.
Assigning group ownership

To add an owner to a group
1. In the Azure classic portal, select Active Directory, and then open your organizations directory.
2. Select the Groups tab, 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.
To remove an owner from a group
2. Select the Groups tab, and then open the group that you want to remove an owner from.
3. Select the Owners tab.
4. Select the owner that you want to remove from this group, and then select Remove.
Manage the groups your group is a member of in
Groups can contain other groups in Azure Active Directory preview. What's in the preview? Here's how to manage
those memberships.
How do I find the groups my group is a member of?


5. On the Group - *groupname* blade, 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. On the groupname blade, 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
View all existing groups in Azure Active Directory
preview
This article explains how to view all groups in Azure Active Directory (Azure AD) preview. What's in the preview?
One of the features of Azure Active Directory (Azure AD) user management is the ability to create groups that you
can populate with your users. You use a group 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.
See existing groups
Dedicated groups in Azure Active Directory
In Azure Active Directory (Azure AD), the dedicated groups feature automatically creates and populates
membership for Azure AD predefined groups. Members of dedicated groups cannot be added or removed using
the Azure classic portal, Windows PowerShell cmdlets, or programmatically.
NOTE
Dedicated groups require that an Azure AD Premium license is assigned to
the administrator who manages the rule on a group
all users who are selected by the rule to be a member of the group
To enable dedicated groups

2. Select the Groups tab, and then open the group you want to edit.
3. Select the Configure tab, and then set Enable Dedicated Groups to Yes.
Once the Enable Dedicated Groups switch is set to Yes, you can further enable the directory to automatically create
the All Users dedicated group by setting the Enable All Users Group switch to Yes. You can then also edit the
name of this dedicated group by typing it in the Display Name for All Users Group field.
The All Users group can be used to assign the same permissions to all the users in your directory. For example, you
can grant all users in your directory access to a SaaS application by assigning access for the All Users dedicated
group to this application.
The dedicated All Users group includes all users in the directory, including guests and external users. If you need a
group that excludes external users, then you can accomplish this by creating a group with an attribute-based
dynamic rule such as the following:
(user.userPrincipalName -notContains "#EXT#@")
For a group that excludes all Guests, use a rule such as the following:
(user.userType -ne "Guest")
To learn about how to create advanced rules (rules that can contain multiple comparisons) for dynamic group
membership, see Using attributes to create advanced rules.
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.
To assign access for a group to a SaaS application
1. In the Azure classic portal, select Active Directory on the navigation bar on the left hand side.
2. Select the Directory tab, and then open the directory in which you want to assign access for a group to a SaaS
application.
3. Select the Applications tab. Select an application that you added from the Application Gallery, and then click
the Users and Groups tab.
4. On the Users and Groups tab, in the Starting with field, enter the name of the group to which you want to
assign access, and then select the check mark in the upper right. You only need to type the first part of a
group's name.
5. Select the group, then then select the Assign Access button. Select Yes when you see the confirmation
message. Nested group memberships are not supported for group-based assignment to applications at this
time.
6. You can also see which users are assigned to the application, either directly or by membership in a group. To
do this, change the Show dropdown from 'Groups' to 'All Users'. The list shows users in the directory and
whether or not each user is assigned to the application. The list also shows whether the assigned users are
assigned to the application directly (assignment type shown as 'Direct'), or by virtue of group membership
(assignment type shown as 'Inherited.')
NOTE
You can see the Users and Groups tab only after you have enabled Azure AD Premium or Azure AD Basic.
Related Articles
Manage the settings for a group in Azure Active
Directory preview
This article explains how to change the settings for a group in Azure Active Directory (Azure AD) preview. What's in
the preview?
How do I find and change the settings?


5. On the Group - *groupname* blade, select Properties.
6. When you finish changing properties for the group, select Save.
See existing groups
Azure Active Directory cmdlets for configuring group
settings
The following settings for unified groups can be configured in your directory:
1. Classifications: the comma-separated list of classifications that users can set on a group. Examples would be
Classified, Secret, and Top Secret.
2. Usage Guidelines URL: a URL that points users to the terms of use for using Unified Groups, as defined by your
organization. This URL will show up in the user interface where users use groups.
3. Group creation enabled: whether none, some or all users are allowed to create Unified Groups. When set to on,
all users can create groups. When set to off, no users can create groups. When off, you can also specify a
security group whose users who are still allowed to create groups.
These settings are configured using a Settings and SettingsTemplate objects. Initially, you will not see any Settings
objects in your directory. This means your directory is configured with the default settings. To change the default
settings, you will create a new settings object using a settings template. Settings templates are defined by
Microsoft.
You can download the module containing the cmdlets used for these operations from the Microsoft Connect site.
Create settings at the directory level

These steps create settings at directory level, which apply to all Office groups in the directory.
1. If you do not know which SettingTemplate to use, this cmdlet returns the list of settings templates:
Get-MsolAllSettingTemplate
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-MsolSettingTemplate TemplateId 62375ab9-6b52-47ed-826b-58e47e0e304b
3. Next, create a new settings object based on that template:

$setting = $template.CreateSettingsObject()
4. Then update the usage guideline value:

$setting["UsageGuidelinesUrl"] = "<https://guideline.com>"
5. Finally, apply the settings:

New-MsolSettings SettingsObject $setting
Here are the settings defined in the Group.Unified SettingsTemplate.

SETTING DESCRIPTION
ClassificationList A comma-delimited list of valid classification values that can

Type: String be applied to Unified Groups.
Default:
EnableGroupCreation The flag indicating whether Unified Group creation is allowed

Type: Boolean in the directory.
Default: True
GroupCreationAllowedGroupId GUID of the security group that is allowed to create Unified

Type: String Groups even when EnableGroupCreation == false.
Default:
UsageGuidelinesUrl A link to the Group Usage Guidelines.

Type: String
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-MsolAllSettings
2. Read all settings for a specific group:

Get-MsolAllSettings -TargetType Groups -TargetObjectId <groupObjectId>
3. Read specific directory settings, using SettingId GUID:

Get-MsolSettings SettingId dbbcb0ea-a6ff-4b44-a1f3-9d7cef74984c
Update settings at the directory level

These steps update settings at directory level, which apply to all Office groups in the directory.
1. Get the existing Settings object:
$setting = Get-MsolSettings SettingId dbbcb0ea-a6ff-4b44-a1f3-9d7cef74984c
2. Get the value you want to update:

$value = $Setting.GetSettingsValue()
3. Update the value:

$value["AllowToAddGuests"] = "false"
4. Update the setting:

Set-MsolSettings SettingId dbbcb0ea-a6ff-4b44-a1f3-9d7cef74984c SettingsValue $value
Remove settings at the directory level
This step removes settings at directory level, which apply to all Office groups in the directory.
`Remove-MsolSettings SettingId dbbcb0ea-a6ff-4b44-a1f3-9d7cef74984c`
Cmdlet syntax reference

SettingsTemplate object reference (Group.Unified SettingsTemplate

object)
"name": "EnableGroupCreation", "type": "System.Boolean", "defaultValue": "true", "description": "A boolean flag
indicating if the Unified Group creation feature is on."
"name": "GroupCreationAllowedGroupId", "type": "System.Guid", "defaultValue": "", "description": "GUID of the
security group that is whitelisted to create Unified Groups."
"name": "ClassificationList", "type": "System.String", "defaultValue": "", "description": "A comma-delimited list of
valid classification values that can be applied to Unified Groups."
"name": "UsageGuidelinesUrl", "type": "System.String", "defaultValue": "", "description": "A link to the Group
Usage Guidelines."
NAME TYPE DEFAULTVALUE DESCRIPTION
"EnableGroupCreation" "System.Boolean" "true" "A boolean flag indicating if

the Unified Group creation
feature is on."
"GroupCreationAllowedGrou "System.Guid" "" "GUID of the security group

pId" that is whitelisted to create
Unified Groups."
"ClassificationList" "System.String" "" "A comma-delimited list of

valid classification values
that can be applied to
Unified Groups."
"UsageGuidelinesUrl" "System.String" "" "A link to the Group Usage

Guidelines."
Next steps
Additional instruction from Microsoft program manager Rob de Jong is available at Rob's Groups Blog.
Using attributes to create advanced rules for group
membership in Azure Active Directory preview
The Azure portal provides you with the ability to create advanced rules to enable more complex attribute-based
dynamic memberships for Azure Active Directory (Azure AD) preview groups. What's in the preview? This article
details the rule attributes and syntax to create these advanced rules.
To create the advanced rule


4. On the Users and groups - All groups blade, select the Add command.
5. 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. For the attributes used for device rules, see Using attributes to create
rules for device objects.
6. On the Dynamic membership rules blade, enter your rule into the Add dynamic membership advanced
rule box, press Enter, and then select Create at the bottom of the blade.
7. Select Create on the Group blade to create the group.
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 required for the entire binary expression, double quotes are required for the
right constant, 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 case insensitive. 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
Query error remediation

The following table lists potential errors and how to correct them if they occur
QUERY PARSE ERROR ERROR USAGE CORRECTED USAGE
Error: Attribute not supported. (user.invalidProperty -eq "Value") (user.department -eq "value")
Property should match one from the
supported properties list.
Error: Operator is not supported on (user.accountEnabled -contains true) (user.accountEnabled -eq true)
attribute. Property is of type boolean. Use the
supported operators (-eq or -ne) on
boolean type from the above list.
Error: Query compilation error. (user.department -eq "Sales") -and (user.department -eq "Sales") -and
(user.department -eq "Marketing") (user.department -eq "Marketing")
(user.userPrincipalName -match Logical operator should match one
"*@domain.ext") from the supported properties list
above.(user.userPrincipalName -match
".*@domain.ext")or(user.userPrincipalNa
me -match "@domain.ext$")Error in
regular expression.
Error: Binary expression is not in right (user.department eq Sales) (user.accountEnabled -eq true) -and
format. (user.department -eq "Sales") (user.userPrincipalName -contains
(user.department-eq"Sales") "alias@domain")<br/>Query has
multiple errors. Parenthesis not in right
place.
Error: Unknown error occurred during (user.accountEnabled -eq "True" AND (user.accountEnabled -eq true) -and
setting up dynamic memberships. user.userPrincipalName -contains (user.userPrincipalName -contains
"alias@domain") "alias@domain")<br/>Query has
place.
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 null (user.dirSyncEnabled -eq true)
Properties of type string

Allowed operators
-eq
-ne
-notStartsWith
-StartsWith
-contains
-notContains
-match
-notMatch
city Any string value or $null (user.city -eq "value")
country Any string value or $null (user.country -eq "value")
department Any string value or $null (user.department -eq "value")
displayName Any string value (user.displayName -eq "value")
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 (user.mail -eq "value")

address 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")
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
POPERTIES ALLOWED VALUES USAGE
otherMails Any string value (user.otherMails -contains

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

alias@domain alias@domain")
Extension attributes and custom attributes

Extension attributes and custom attributes are supported in dynamic membership rules.
Extension attributes are synced from on premise 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 premise 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 now populate members in a group based on the manager attribute of a user.
To configure a group as a Manager group
1. Follow steps 1-5 in 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 Direct Reports for {obectID_of_manager}. An example of a valid rule for Direct Reports is
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 in the Azure AD on the Profile tab of the user page for the user who is the manager.
3. When saving this rule, all users that satisfy the rule will be joined as members of the group. It can take some
minutes for the group to initially populate.
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:
displayName any string value (device.displayName -eq "Rob Iphone)
deviceOSType any string value (device.deviceOSType -eq "IOS")
deviceOSVersion any string value (device.OSVersion -eq "9.1")
isDirSynced true false null (device.isDirSynced -eq "true")
isManaged true false null (device.isManaged -eq "false")
isCompliant true false null (device.isCompliant -eq "true")
These articles provide additional information on groups in Azure Active Directory.
See existing groups
Using attributes to create advanced rules
The Azure classic portal provides you with the ability to create advanced rules to enable more complex attribute-
based dynamic memberships for Azure Active Directory (Azure AD) groups.
When any attributes of a user change, the system evaluates all dynamic group rules in a directory to see if the
attribute change of the user would trigger any group adds or removes. If a user satisfies a rule on a group, they are
added as a member to that group. If they no longer satisfy the rule of a group they are a member of, they are
removed as a members from that group.
NOTE
You can set up a rule for dynamic membership on security groups or Office 365 groups. Nested group memberships aren't
currently supported for group-based assignment to applications.
Dynamic memberships for groups require an Azure AD Premium license to be assigned to
The administrator who manages the rule on a group
All members of the group
To create the advanced rule

3. Select the Configure tab, select the Advanced rule option, and then enter the advanced rule into the text box.
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 required for the entire binary expression, double quotes are required for the right
constant, 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.
Note that the property must be prefixed with the correct object type: user or device. The below rule will fail the
validation: mail ne null
The correct rule would be:
user.mail ne null
The total length of the body of your advanced rule cannot exceed 2048 characters.
NOTE
String and regex operations are case insensitive. Strings containing quotes " should be escaped using 'character, for example,
user.department -eq `"Sales". Only use quotes for string type values, and only use English quotes.
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
Operator precedence
All Operators are listed below per precedence from lower to higher, operator in same line are in equal precedence
-any -all -or -and -not -eq -ne -startsWith -notStartsWith -contains -notContains -match notMatch
All operators can be used with or without hyphen prefix.
Note that parenthesis are not always needed, you only need to add parenthesis 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")
Query error remediation

The following table lists potential errors and how to correct them if they occur
QUERY PARSE ERROR ERROR USAGE CORRECTED USAGE
Error: Attribute not supported. (user.invalidProperty -eq "Value") (user.department -eq "value")
Property should match one from the
supported properties list.
Error: Operator is not supported on (user.accountEnabled -contains true) (user.accountEnabled -eq true)
attribute. Property is of type boolean. Use the
supported operators (-eq or -ne) on
boolean type from the above list.
Error: Query compilation error. (user.department -eq "Sales") -and (user.department -eq "Sales") -and
(user.department -eq "Marketing") (user.department -eq "Marketing")
(user.userPrincipalName -match Logical operator should match one
"*@domain.ext") from the supported properties list
above.(user.userPrincipalName -match
".*@domain.ext")or(user.userPrincipalNa
me -match "@domain.ext$")Error in
regular expression.
Error: Binary expression is not in right (user.department eq Sales) (user.accountEnabled -eq true) -and
format. (user.department -eq "Sales") (user.userPrincipalName -contains
(user.department-eq"Sales") "alias@domain")<br/>Query has
place.
Error: Unknown error occurred during (user.accountEnabled -eq "True" AND (user.accountEnabled -eq true) -and
setting up dynamic memberships. user.userPrincipalName -contains (user.userPrincipalName -contains
"alias@domain") "alias@domain")<br/>Query has
place.
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
accountEnabled true false user.accountEnabled -eq true)
dirSyncEnabled true false null (user.dirSyncEnabled -eq true)
Properties of type string

Allowed operators
-eq
-ne
-notStartsWith
-StartsWith
-contains
-notContains
-match
-notMatch
city Any string value or $null (user.city -eq "value")
country Any string value or $null (user.country -eq "value")
department Any string value or $null (user.department -eq "value")
displayName Any string value (user.displayName -eq "value")
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")
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
POPERTIES ALLOWED VALUES USAGE
otherMails Any string value (user.otherMails -contains

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

alias@domain alias@domain")
Use of Null values

To specify a null value in a rule, you can use "null" or $null. Example:
user.mail ne null is equivalent to 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 premise 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 premise 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.
Support for multi-value properties

To include a multi-value property in a rule, use the "-any" operator, as in
user.assignedPlans -any assignedPlan.service -startsWith "SCO"
Direct Reports Rule

You can populate members in a group based on the manager attribute of a user.
To configure a group as a Manager group
1. In the Azure classic portal, click Active Directory, and then click the name of your organizations directory.
3. Select the Configure tab, and then select ADVANCED RULE.
4. Type the rule with the following syntax:
Direct Reports for Direct Reports for {obectID_of_manager}. An example of a valid rule for Direct Reports is
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 in the Azure AD on the Profile tab of the user page for the user who is the manager.
5. When saving this rule, all users that satisfy the rule will be joined as members of the group. It can take some
minutes for the group to initially populate.
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:
displayName any string value (device.displayName -eq "Rob Iphone)
deviceOSType any string value (device.deviceOSType -eq "IOS")
deviceOSVersion any string value (device.OSVersion -eq "9.1")
isDirSynced true false null (device.isDirSynced -eq true)
isManaged true false null (device.isManaged -eq false)
isCompliant true false null (device.isCompliant -eq true)
deviceCategory any string value (device.deviceCategory -eq "")
deviceManufacturer any string value (device.deviceManufacturer -eq

"Microsoft")
deviceModel any string value (device.deviceModel -eq "IPhone 7+")
deviceOwnership any string value (device.deviceOwnership -eq "")
domainName any string value (device.domainName -eq

"contoso.com")
enrollmentProfileName any string value (device.enrollmentProfileName -eq "")
isRooted true false null (device.isRooted -eq true)

managementType any string value (device.managementType -eq "")
organizationalUnit any string value (device.organizationalUnit -eq "")
deviceId a valid deviceId (device.deviceId -eq "d4fe7726-5966-

431c-b3b8-cddc8fdb717d"
NOTE
These device rules cannot be created using the "simple rule" dropdown in the Azure classic portal.
Troubleshooting dynamic memberships for groups
Setting up Azure Active Directory for self-service
group management
Self-service group management enables users to create and manage 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. In this way, day-to-day control of group
membership can be delegated to 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 comprises 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 others
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 others 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.
Making a group available for end user self-service

1. In the Azure classic portal, open your Azure AD directory.
2. On the Configure tab, set Delegated group management to Enabled.
3. Set Users can create security groups or Users can create Office groups to Enabled.
When Users can create security groups is 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. If
Users can create security groups is 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 use self-service for security groups to achieve a more fine-grained access
control over self-service group management for your users. When Users can create groups is enabled, all users
in your directory are allowed to create new groups and add members to these groups. By also setting Users who
can use self-service for security groups 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 to All, you enable all users in your directory to create new groups.
You can also use the Group that can use self-service for security groups box to specify a custom name for a
group whose members can use self-service.
Troubleshooting dynamic memberships for groups
I configured a rule on a group but no memberships get updated in the group

Verify that the Enable delegated group management setting is set to Yes in the Configure tab. You will see
this setting only if you are signed in as a user to whom an Azure Active Directory Premium license is assigned.
Verify the values for user attributes on the rule: are there users that satisfy the rule?
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 dont 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.
This documentation is part of the Azure Active Directory Reporting Guide.

You can use Azure Active Directory's access and usage reports to gain visibility into the integrity and security of
your organizations directory. With this information, a directory admin can better determine where possible
security risks may lie so that they can adequately plan to mitigate those risks.
In the Azure Management Portal, reports are categorized in the following ways:
Anomaly reports Contain sign in events that we found to be anomalous. Our goal is to make you aware of
such activity and enable you to be able to make a determination about whether an event is suspicious.
Integrated Application reports 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.
NOTE
Some advanced anomaly and resource usage reports are only available when you enable Azure Active Directory
Premium. Advanced reports help you improve access security, respond to potential threats and get access to analytics
on device access and application usage.
Reports
REPORT DESCRIPTION
Anomalous activity reports
Sign ins from unknown sources May indicate an attempt to sign in without being traced.
Sign ins after multiple failures May indicate a successful brute force attack.
Sign ins from multiple geographies May indicate that multiple users are signing in with the same
account.
Sign ins from IP addresses with suspicious activity May indicate a successful sign in after a sustained intrusion
attempt.
Sign ins from possibly infected devices May indicate an attempt to sign in from possibly infected
devices.
Irregular sign in activity May indicate events anomalous to users sign in patterns.
REPORT DESCRIPTION
Users with anomalous sign in activity Indicates users whose accounts may have been
compromised.
Users with leaked credentials Users with leaked credentials
Activity logs
Audit report Audited events in your directory
Password reset activity Provides a detailed view of password resets that occur in
your organization.
Password reset registration activity Provides a detailed view of password reset registrations that
occur in your organization.
Self service groups activity Provides an activity log to all group self service activity in
your directory
Integrated applications
Application usage Provides a usage summary for all SaaS applications

integrated with your directory.
Account provisioning activity Provides a history of attempts to provision accounts to

external applications.
Password rollover status Provides a detailed overview of automatic password rollover

status of SaaS applications.
Account provisioning errors Indicates an impact to users access to external applications.
Rights management
RMS usage Provides a summary for Rights Management usage
Most active RMS users Lists top 1000 active users who accessed RMS-protected files
RMS device usage Lists devices used for accessing RMS-protected files
RMS enabled application usage Provides usage of RMS enabled applications
Report editions
REPORT FREE BASIC PREMIUM
Anomalous activity
reports
Sign ins from unknown

sources
REPORT FREE BASIC PREMIUM
Sign ins after multiple

failures
Sign ins from multiple

geographies
Sign ins from IP addresses

with suspicious activity
Sign ins from possibly

infected devices
Irregular sign in activity
Users with anomalous sign

in activity
Users with leaked

credentials
Activity logs
Audit report
Password reset activity
Password reset registration

activity
Self service groups activity
Integrated applications
Application usage
Account provisioning
activity
Password rollover status
Account provisioning errors
Rights managment
RMS usage RMS Only
Most active RMS users RMS Only
RMS device usage RMS Only
RMS enabled application RMS Only

usage
Anomalous activity reports
The anomalous sign in activity reports flag suspicious sign in activity to Office365, Azure Management Portal,
Azure AD Access Panel, Sharepoint Online, Dynamics CRM Online, and other Microsoft online services.
All of these reports, except the "Sign ins after multiple failures" report, also flag suspicious federated sign ins to
the aforementioned services, regardless of the federation provider.
The following reports are available:
Sign ins from unknown sources.
Sign ins after multiple failures.
Sign ins from multiple geographies.
Sign ins from IP addresses with suspicious activity.
Irregular sign in activity.
Sign ins from possibly infected devices.
Users with anomalous sign in activity.
Users with leaked credentials
Activity logs
Audit report
DESCRIPTION REPORT LOCATION
Shows a record of all audited events within the last 24 hours, Directory > Reports tab
last 7 days, or last 30 days.
For more information, see Azure Active Directory Audit
Report Events

Shows all password reset attempts that have occurred in Directory > Reports tab
your organization.
Password reset registration activity

Shows all password reset registrations that have occurred in Directory > Reports tab
your organization
Self service groups activity

Shows all activity for the self-service managed groups in your Directory > Users > User > Devices tab
directory.
Integrated applications reports

Application usage: summary
Use this report when you want to see usage for all the SaaS Directory > Reports tab
applications in your directory. This report is based on the
number of times users have clicked on the application in the
Access Panel.
This report includes sign ins to all applications that your directory has access to, including pre-integrated
Microsoft applications.
Pre-integrated Microsoft applications include Office 365, Sharepoint, the Azure Management Portal, and others.
Application usage: detailed
Use this report when you want to see how much a specific Directory > Reports tab
SaaS application is being used. This report is based on the
number of times users have clicked on the application in the
Access Panel.
Application dashboard
This report indicates cumulative sign ins to the application by Directory > Application > Dashboard tab
users in your organization, over a selected time interval. The
chart on the dashboard page will help you identify trends for
all usage of that application.
Error reports
Use this to monitor errors that occur during the Directory > Reports tab
synchronization of accounts from SaaS applications to Azure
Active Directory.
User-specific reports
Devices
Use this report when you want to see the IP address and Directory > Users > User > Devices tab
geographical location of devices that a specific user has used
to access Azure Active Directory.
Activity
Shows the sign in activity for a user. The report includes Directory > Users > User > Activity tab
information like the application signed into, device used, IP
address, and location. We do not collect the history for users
that sign in with a Microsoft account.
Sign in events included in the User Activity report

Only certain types of sign in events will appear in the User Activity report.
EVENT TYPE INCLUDED?
Sign ins to the Access Panel Yes
Sign ins to the Azure Management Portal Yes
Sign ins to the Microsoft Azure Portal Yes
Sign ins to the Office 365 portal Yes
Sign ins to a native application, like Outlook (see exception Yes

below)
EVENT TYPE INCLUDED?
Sign ins to a federated/provisioned app through the Access Yes

Panel, like Salesforce
Sign ins to a password-based app through the Access Panel, Yes

like Twitter
Sign ins to a custom business app that has been added to No (Coming soon)
the directory
Sign ins to an Azure AD Application Proxy app that has been No (Coming soon)
added to the directory
Note: To reduce the amount of noise in this report, sign ins by the Microsoft Online Services Sign-In Assistant
are not shown.
Things to consider if you suspect security breach

If you suspect that a user account may be compromised or any kind of suspicious user activity that may lead to a
security breach of your directory data in the cloud, you may want to consider one or more of the following
actions:
Contact the user to verify the activity
Reset the user's password
Enable multi-factor authentication for additional security
View or download a report

1. In the Azure classic portal, click Active Directory, click the name of your organizations directory, and then
click Reports.
2. On the Reports page, click the report you want to view and/or download.
NOTE
If this is the first time you have used the reporting feature of Azure Active Directory, you will see a message to Opt
In. If you agree, click the check mark icon to continue.
3. Click the drop-down menu next to Interval, and then select one of the following time ranges that should
be used when generating this report:
Last 24 hours
Last 7 days
Last 30 days
4. Click the check mark icon to run the report.
Up to 1000 events will be shown in the Azure classic portal.
5. If applicable, click Download to download the report to a compressed file in comma-separated values (CSV)
format for offline viewing or archiving purposes.
Up to 75,000 events will be included in the downloaded file.
For more data, check out the Azure AD Reporting API.
Ignore an event
If you are viewing any anomaly reports, you may notice that you can ignore various events that show up in
related reports. To ignore an event, simply highlight the event in the report and then click Ignore. The Ignore
button will permanently remove the highlighted event from the report and can only be used by licensed global
admins.
Automatic email notifications

For more information about Azure AD's reporting notifications, check out Azure Active Directory Reporting
Notifications.
What's next
Getting started with Azure Active Directory
Reporting
What it is
Azure Active Directory (Azure AD) includes security, activity, and audit reports for your directory. Here's a list of the
reports included:
Security reports
Sign-ins from unknown sources
Sign-ins after multiple failures
Sign-ins from multiple geographies
Sign-ins from IP addresses with suspicious activity
Irregular sign-in activity
Sign-ins from possibly infected devices
Users with anomalous sign-in activity
Activity reports
Application usage: summary
Application usage: detailed
Application dashboard
Individual user devices
Individual user Activity
Groups activity report
Password Reset Registration Activity Report
Audit reports
Directory audit report
TIP
For more documentation on Azure AD Reporting, check out View your access and usage reports.
How it works
Reporting pipeline
The reporting pipeline consists of three main steps. Every time a user signs in, or an authentication is made, the
following happens:
First, the user is authenticated (successfully or unsuccessfully), and the result is stored in the Azure Active
Directory service databases.
At regular intervals, all recent sign ins are processed. At this point, our security and anomalous activity
algorithms are searching all recent sign ins for suspicious activity.
After processing, the reports are written, cached, and served in the Azure classic portal.
Report generation times
Due to the large volume of authentications and sign ins processed by the Azure AD platform, the most recent sign-
ins processed are, on average, one hour old. In rare cases, it may take up to 8 hours to process the most recent
sign-ins.
You can find the most recent processed sign-in by examining the help text at the top of each report.
TIP
Getting started
Sign into the Azure classic portal
First, you'll need to sign into the Azure classic portal as a global or compliance administrator. You must also be an
Azure subscription service administrator or co-administrator, or be using the "Access to Azure AD" Azure
subscription.
Navigate to Reports
To view Reports, navigate to the Reports tab at the top of your directory.
If this is your first time viewing the reports, you'll need to agree to a dialog box before you can view the reports.
This is to ensure that it's acceptable for admins in your organization to view this data, which may be considered
private information in some countries.
Explore each report

Navigate into each report to see the data being collected and the sign-ins processed. You can find a list of all the
reports here.
Download the reports as CSV
Each report can be downloaded as a CSV (comma-separated value) file. You can use these files in Excel, PowerBI or
third-party analysis programs to further analyze your data.
To download any report as a CSV, navigate to the report and click "Download" at the bottom.
TIP
Next steps
Customize alerts for anomalous sign in activity
Navigate to the "Configure" tab of your directory.
Scroll to the "Notifications" section.
Enable or disable the "Email Notifications of Anomalous sign-ins" section.
Integrate with the Azure AD Reporting API

See Getting started with the Reporting API.
Engage Multi-Factor Authentication on users
Select a user in a report.
Click the "Enable MFA" button at the bottom of the screen.
TIP
Learn more
Audit events
Learn about what events are audited in the directory in Azure Active Directory Reporting Audit Events.
API Integration
See Getting started with the Reporting API and the API reference documentation.
Get in touch
Email aadreportinghelp@microsoft.com for feedback, help, or any questions you might have.
TIP
Known networks
You can use Azure Active Directory's access and usage reports to gain visibility into the integrity and security of
your organizations directory. With this information, a directory admin can better determine where possible
security risks may lie so that they can adequately plan to mitigate those risks.
It is possible that the Sign ins from multiple geographies and Sign ins from IP addresses with suspicious activity
reports incorrectly flag IP addresses that are actually owned by your organization.
This can, for example, happen when:
A user in your Boston office has signed in remotely to your data center in San Francisco triggers the Sign ins
from multiple geographies report
A user of your organization tries to sign-on several times with an incorrect password triggers the Sign ins from
IP addresses with suspicious activity report
To prevent these cases from generating misleading security reports, you should add known IP address ranges to
the list of your organization's public IP address.
To add your organizations public IP address ranges, perform the following steps:
1. Sign-on to the Azure management portal.
2. In the left pane, click Active Directory.
3. In the Directory tab, select your directory.

4. In the menu on the top, click Configure.
5. On the Configure tab, go to your organizations public IP address ranges
6. Click Add Known IP Address Ranges.

7. Add your address ranges in the dialog box that appears, and then click the check button when you are done.
Additional resources:
Sign ins from IP addresses with suspicious activity
Sign ins from multiple geographies
Azure Active Directory Reporting Guide
Azure Active Directory reporting - preview

Getting started with the Azure AD Reporting API
Azure Active Directory Reporting Audit Events
Azure Active Directory Reporting Retention
Azure Active Directory reporting - preview

With reporting in the Azure Active Directory preview, you get all the information you need to determine how your
environment is doing. What's in the preview?
There are two main areas of reporting:
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
Depending on the scope of the data you are looking for, you can access these reports either by clicking Users and
groups or Enterprise applications in the services list in the Azure portal.
Sign-in activities
User sign-in activities
With the information provided by the user sign-in report, you 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?
Whats the status of these sign-ins?
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.
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?
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.
By using the column chooser, you can select the data fields you want to display.
Filtering sign-ins
You can filter sign-ins to limit the amount of displayed data using the following fields:
Date and time
User's user principal name
Application name
Client name
Sign-in status
Another method to filter the entries of the sign-in activities is to search for specific entries. The search method
enables you to scope your sign-ins around specific users, groups or applications.
Audit logs
The auditing logs in Azure Active Directory provide records of system activities for compliance.
There are three main categories for auditing related activities in the Azure portal:
Users and groups
Applications
Directory
For a complete list of audit report activities, see the list of audit report events.
Your entry point to all auditing data is Audit logs in the Activity section of Azure Active Directory.
An audit log has a list view that shows the actors (who), the activities (what) and the targets.
By clicking an item in the list view, you can get more details about it.
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 Users and Groups.
Application 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 applications, you can find a filtered view under Audit logs
in the Activity section of Enterprise applications.
Filtering audit logs
You can filter sign-ins to limit the amount of displayed data using the following fields:
Date and time
Actor's user principal name
Activity type
Activity
The content of the Activity Type list, is tied to your entry point to this blade.
If your entry point is Azure Active Directory, this list contains all possible activity types:
Application
Group
User
Device
Directory
Policy
Other
The listed activities are scoped by activity type. For example, if you have Group selected as Activity Type, the
Activity list only contains group related activities.
Another method to filter the entries of a audit log is to search for specific entries.
Next steps
See the Azure Active Directory Reporting Guide.
Getting started with the Azure Active Directory
reporting API
This topic is part of the Azure Active Directory Reporting Guide.

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 all other APIs, see the Azure AD
reports and events (preview) article.
For questions, issues or feedback, please contact AAD Reporting Help.
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 of the available Azure AD Graph API endpoints by navigating to
https://graph.windows.net/tenant-name/reports/$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.
Who can access the data?

Users 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 Admins
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 PowerShells
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
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
activityType
Supported operators: eq
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 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:
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.windows.net"
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.windows.net/'
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.
If you would like to find out more about Azure Active Directory reporting, see the Azure Active Directory
Reporting Guide.
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 prepare your access to the reporting API, you must:
1. Create an application in your Azure AD tenant
2. Grant the application appropriate permissions to access the Azure AD data
3. Gather configuration settings from your directory
Create an Azure AD application

To configure your directory to access the Azure AD reporting API, you must sign in to the Azure classic portal with
an Azure subscription 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.
1. In the Azure classic portal, on the left navigation pane, click Active Directory.
2. From the active directory list, select your directory.

3. In the menu on the top, click Applications.
4. On the bottom bar, click Add.
5. On the What do you want to do? dialog, click Add an application my organization is developing.
6. On the Tell us about your application dialog, perform the following steps:
a. In the Name textbox, type a name (e.g.: Reporting API Application).

b. Select Web application and/or web API.
c. Click Next.
7. On the App properties dialog, perform the following steps:
a. In the Sign-on URL textbox, type https://localhost .

b. In the App ID URI textbox, type https://localhost/ReportingApiApp .
c. Click Complete.
Grant your application permission to use the API

4. In the applications list, select your newly created application.
6. In the Permissions to other applications section, for the Azure Active Directory resource, click the
Application Permissions drop-down list, and then select Read directory data.
7. On the bottom bar, click Save.
Gather configuration settings from your directory

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
3. In the menu on the top, click Domains.
4. In the Domain Name column, copy your domain name.
Get the application's client ID


6. Copy your Client ID.
Get the 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.
6. In the Keys section, perform the following steps:
a. From the duration list, select a duration

b. On the bottom bar, click Save.
c. 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.
Reporting Guide.
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 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 Admins
permission)
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 PowerShells
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.
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.windows.net/"
$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.
Azure Active Directory audit report events

The Azure Active Directory Audit Report helps customers identify privileged actions that occurred in their Azure
Active Directory. Privileged actions include elevation changes (for example, role creation or password resets),
changing policy configurations (for example password policies), or changes to directory configuration (for
example, changes to domain federation settings). The reports provide the audit record for the event name, the
actor who performed the action, the target resource affected by the change, and the date and time (in UTC).
Customers are able to retrieve the list of audit events for their Azure Active Directory via the Azure Portal, as
described in View your Audit Logs.
List of Audit Report Events

EVENTS EVENT DESCRIPTION
User events
Add User Added a user to the directory.
Delete User Deleted a user from the directory.
Set license properties Set the license properties for a user in the directory.
Reset user password Reset the password for a user in the directory.
Change user password Changed the password for a user in the directory.
Change user license Changed the license assigned to a user in the directory. To see
what licenses were updated, look at the Update user
properties below
Update user Updated a user in the directory. See below for attributes that
can be updated.
Set force change user password Set the property that forces a user to change their password
on login.
Update user credentials User changed the password
Group events
Add group Created a group in the directory.
Update group Updated a group in the directory. To see what group

properties were updated, refer to Group Properties Audited in
the section below
Delete group Deleted a group from the directory.

CreateGroupSettings Created group settings
UpdateGroupSettings Updated group settings. To see what group settings were

updated, refer to Group Properties Audited in the section
below
DeleteGroupSettings Deleted group settings
SetGroupLicense Set group license.
SetGroupManagedBy Set group to be managed by user
AddGroupMember Added member to group
RemoveGroupMember Remove member from group
AddGroupOwner Added owner to group
RemoveGroupOwner Removed owner from group
Application events
Add service principal Added a service principal to the directory.
Remove service principal Removed a service principal from the directory.
Add service principal credentials Added credentials to a service principal.
Remove service principal credentials Removed credentials from a service principal.
Add delegation entry Created an OAuth2PermissionGrant in the directory.
Set delegation entry Updated an OAuth2PermissionGrant in the directory.
Remove delegation entry Deleted an OAuth2PermissionGrant in the directory.
Role events
Add role member to Role Added a user to a directory role.
Remove role member from Role Removed a user from a directory role.
AddRoleDefinition Added role definition.
UpdateRoleDefinition Updated role definition. To see what role settings were

updated, refer to Role Definition Properties Audited in the
section below
DeleteRoleDefinition Deleted role definition.
AddRoleAssignmentToRoleDefinition Added role assignment to role definition.

RemoveRoleAssignmentFromRoleDefinition Removed role assignment from role definition.
AddRoleFromTemplate Added role from template.
UpdateRole Updated role.
AddRoleScopeMemberToRole Added scoped member to role.
RemoveRoleScopedMemberFromRole Removed scoped member from role.
Device Events (all new events)
AddDevice Added device.
UpdateDevice Updated device. To see what device properties were updated,

refer to Device properties Audited in the section below
DeleteDevice Deleted device.
AddDeviceConfiguration Added device configuration.
UpdateDeviceConfiguration Updated device configuration. To see what device

configuration properties were updated, refer to Device
configuration properties Audited in the section below
DeleteDeviceConfiguration Deleted device configuration.
AddRegisteredOwner Added registered owner to device.
AddRegisteredUsers Added registered users to device.
RemoveRegisteredOwner Remove registered owner from device.
RemoveRegisteredUsers Remove registered users from device.
RemoveDeviceCredentials Remove device credentials.
B2B events
Batch invites uploaded. An administrator has uploaded a file containing invitations to

be sent to partner users.
Batch invites processed. A file containing invitations to partner users has been
processed.
Invite external user. An external user has been invited to the directory.
Redeem external user invite. An external user has redeemed their invitation to the
directory.
Add external user to group. An external user has been assigned membership to a group in
the directory.
Assign external user to application. An external user has been assigned direct access to an
application.
Viral tenant creation. A new tenant has been created in Azure AD by the invitation
redemption.
Viral user creation. A user has been created in an existing tenant in Azure AD by
the invitation redemption.
Administrative Units (all new events)
AddAdministrativeUnit Add administrative unit.
UpdateAdministrativeUnit Update administrative unit. To see what Administrative Unit

properties were updated, refer to Administrative Unit
Properties audited in the section below
DeleteAdministrativeUnit Delete administrative unit.
AddMemberToAdministrativeUnit Add member to administrative unit.
RemoveMemberFromAdministrativeUnit Remove member from administrative unit.
Directory events
Add partner to company Added a partner to the directory.
Remove Partner from company Removed a partner from the directory.
DemotePartner Demote partner.
Add domain to company Added a domain to the directory.
Remove domain from company Removed a domain from the directory.
Update domain Updated a domain on the directory. To see what Domain

properties were updated, refer to Domain Properties audited
in the section below
Set domain authentication Changed the default domain setting for the company.
Set Company contact information Set company-level contact preferences. This includes email
addresses for marketing, as well as technical notifications
about Microsoft Online Services.
Set federation settings on domain Updated the federation settings for a domain.
Verify domain Verified a domain on the directory.

Verify email verified domain Verified a domain on the directory using email verification.
Set DirSyncEnabled flag on company Set the property that enables a directory for Azure AD Sync.
Set Password Policy Set length and character constraints for user passwords.
Set Company Information Updated the company-level information. See the Get-
MsolCompanyInformation PowerShell cmdlet for more details.
SetCompanyAllowedDataLocation Set company allowed data location.
SetCompanyDirSyncEnabled Set DirSyncEnabled flag.
SetCompanyDirSyncFeature Set DirSync feature.
SetCompanyInformation Set Company Information.
SetCompanyMultiNationalEnabled Set company multinational feature enabled.
SetDirectoryFeatureOnTenant Set directory feature on tenant.
SetTenantLicenseProperties Set tenant license properties.
CreateCompanySettings Create company settings
UpdateCompanySettings Update company settings. To see what Company properties

were updated, refer to Company Properties audited in the
section below
DeleteCompanySettings Delete company settings
SetAccidentalDeletionThreshold Set accidental deletion threshold.
SetRightsManagementProperties Set rights management properties.
PurgeRightsManagementProperties Purge rights management properties.
UpdateExternalSecrets Update external secrets
Policy Events (all new events)
AddPolicy Add policy.
UpdatePolicy Update policy.
DeletePolicy Delete policy.
AddDefaultPolicyApplication Add policy to application.
AddDefaultPolicyServicePrincipal Add policy to service principal.

RemoveDefaultPolicyApplication Remove policy from application.
RemoveDefaultPolicyServicePrincipal Remove policy from service principal.
RemovePolicyCredentials Remove policy credentials.
Audit report retention

Events in the Azure AD Audit report are retained for 180 days. For more information about retention on reports,
see Azure Active Directory Report Retention Policies.
For customers interested in storing their audit events for longer retention periods, the Reporting API can be used
to regularly pull audit events into a separate data store. See Getting Started with the Reporting API for details.
Properties included with each audit event

PROPERTY DESCRIPTION
Date and Time The date and time that the audit event occurred
Actor The user or service principal that performed the action
Action The action that was performed
Target The user or service principal that the action was performed on
"Update User" attributes

The "Update user" audit event includes additional information about what user attributes were updated. For each
attribute, both the previous value and the new value is included.
ATTRIBUTE DESCRIPTION
AccountEnabled The user can sign in.
AssignedLicense All licenses that have been assigned to the user.
AssignedPlan Service plans resulting from the licenses assigned to the user.
LicenseAssignmentDetail Details on licenses assigned to the user. For instance, if group-

based licensing was involved, this would include the group
that granted the license.
Mobile The user's mobile phone.
OtherMail The user's alternate email address.
OtherMobile The user's alternate mobile phone.

StrongAuthenticationMethod A list of verification methods configured by the user for Multi-

Factor Authentication, such as Voice Call, SMS, or Verification
code from a mobile app.
StrongAuthenticationRequirement If Multi-Factor Authentication is enforced, enabled, or disabled

for this user.
StrongAuthenticationUserDetails The users phone number, alternative phone number and

email address used for Multi-Factor Authentication and
password reset verification.
StrongAuthenticationPhoneAppDetail Detail forof phone apps registered to perform 2FA login
TelephoneNumber The user's telephone number.
AlternativeSecurityId An alternative security ID for the object.
CreationType Creation method of the user (Either by invitation or viral).
InviteTicket List of invitation tickets for the user.
InviteReplyUrl List of urls to reply upon invitation acceptance.
InviteResources List of resources to which the user has been invited.
LastDirSyncTime Last time the object was updated because of synchronizing

from the authoritative (customer, on-premise) directory.
MSExchRemoteRecipientType Maps to MSO recipient types. Refer to [MSO recipient types]

https://msdn.microsoft.com/library/microsoft.office.interop.out
look.recipient.type.aspx for recipient types
PreferredDataLocation The preferred location for the user's, group's, contact's, public
folder's, or device's data.
ProxyAddresses The address by which an Exchange Server recipient object is

recognized in a foreign mail system.
StsRefreshTokensValidFrom Carries refresh token revocation information - any STS refresh

tokens issued before this time are considered expired.
UserPrincipalName The UPN that is an Internet-style logon name for a user.
UserState Status of User

PendingApproval/PendingAcceptance/Accepted/PendingVerifi
cation.
UserStateChangedOn TimeStamp of last change to UserState. Used to trigger

lifecycle workflows.
UserType Type of user. Member (0), Guest (1), Viral(2).

"Update Group" attributes
Classification The classification for a Unified Group (HBI, MBI, etc).
Description Human-readable descriptive phrases about the object.
DisplayName The display name for an object
DirSyncEnabled Indicates whether synchronization occurs from an

authoritative (customer, on-premise) directory.
GroupLicenseAssignment License assignment of a group
GroupType Type of Group, Unified (0)
IsMembershipRuleLocked Indicates that the MembershipRule property is set by the self-

service group management service and cannot be changed by
users. Applicable only to groups where GroupType includes
GroupType.DynamicMembership
IsPublic Flag to indicate if the group is public/private.
LastDirSyncTime Last time the object was updated as a result of synchronizing

from the authoritative (customer, on premise) directory.
Mail Primary e-mail address
MailEnabled Indicates whether this group has e-mail capability.
MailNickname Moniker for an address book object, typically the portion of its
email name preceding the "@" symbol.
MembershipRule A string expressing the criteria used by the self-service group

management service to determine which members should
belong to this group. See also IsMembershipRuleLocked.
Applicable only to groups where GroupType includes
GroupType.DynamicMembership.
MembershipRuleProcessingState An enum value defined by the self-service group management

service defining the status of membership processing for this
group. Applicable only to groups where GroupType includes
GroupType.DynamicMembership.
ProxyAddresses The address by which an Exchange Server recipient object is

recognized in a foreign mail system.
RenewedDateTime Timestamp record of when a group was most recently

renewed.
SecurityEnabled Indicates whether membership in the group may influence

authorization decisions.
WellKnownObject Labels a directory object, designating it as one of a pre-

defined set.
"Update Device" attributes

AccountEnabled Indicates whether a security principal can authenticate.
CloudAccountEnabled Indicates whether a security principal can authenticate.

Written by InTune when the device is mastered on premise.
CloudDeviceOSType Type of the device based on the OS e.g. Windows RT, iOS.
When set by a cloud service (such as Intune), this attribute
becomes authoritative in the directory for DeviceOSType.
CloudDeviceOSVersion Version of the OS. When set by a cloud service (such as

Intune), this attribute becomes authoritative in the directory
for DeviceOSVersion.
CloudDisplayName Value of the displayName LDAP attribute. When set by a

cloud service (such as Intune), this attribute becomes
authoritative in the directory for displayName.
CloudCreated Indicates whether the object was created by cloud services.
CompliantUntil Until what time device is deemed compliant.
DeviceMetadata Custom metadata for the device
DeviceObjectVersion This attribute is used to identify the schema version of the

device.
DeviceOSType Type of the device based on the OS e.g. Windows RT, iOS.
Written by the Registration Service and intended to be
updated by the MDM management service or STS light
management service.
DeviceOSVersion Version of the OS. Written by the Registration Service and

intended to be updated by the MDM management service or
STS light management service.
DevicePhysicalIds Multivalued attribute intended to store identifiers of the

physical device. This may include BIOS IDs, TPM thumbprints,
hardware specific IDs, etc.

authoritative (customer, on premise) directory.
IsCompliant This attribute is used to manage the mobile device

management status of the device.
IsManaged This attribute is used to indicate the device is managed by a

cloud MDM.
LastDirSyncTime Last time the object was updated because of synchronizing

from the authoritative (customer, on premise) directory.
"Update Device Configuration" attributes

MaximumRegistrationInactivityPeriod The maximum number of days a device can be inactive before

it is considered for removal.
RegistrationQuota Policy used to limit the number of device registrations allowed

for a single user.
"Update Service principal Configuration" attributes

AccountEnabled Indicates whether a security principal can authenticate.
AppPrincipalId External, application-defined identity for a security principal.
ServicePrincipalName A service principal name, containing "name/authority" where

name specifies an application class value and authority
contains at least hostname[:port] or "name" that specifies an
identifier for the service principal.
"Update App" attributes

AppAddress The set of addresses (redirect URLs) that are assigned to a

service principal.
AppId Application ID of the App
AppIdentifierUri Application URI, which identifies the application. It is usually

the application access URL.
AppLogoUrl The url for the application logo image stored in a CDN.
AvailableToOtherTenants True the application is multi-tenant application (i.e. can be

used by other tenants).
DisplayName The display name for an Application Name

Entitlement List of application entitlements.
ExternalUserAccountDelegationsAllowed Flag indicating whether resource application is a trusted one

and can create delegation entries for external user accounts.
GroupMembershipClaims The group membership claims policy.
PublicClient True if the client cannot keep secret (i.e. non-confidential client
in OAuth2.0)
RecordConsentConditions Types of consent conditions, as defined by the contract terms:

None (0), SilentConsentForPartnerManagedApp(1). This value
will be exposed in the Graph API schema and can only be
set/changed by tenant admins.
RequiredResourceAccess XML content of a Value of the RequiredResourceAccess

property.
WebApp If true, indicates that this application is a web app.
WwwHomepage The primary Web page.
"Update Role" attributes

AppAddress The set of addresses (redirect URLs) that are assigned to a

service principal.
BelongsToFirstLoginObjectSet If true, indicates that this object belongs to the set of objects
required to enable login of the first admin of a new tenant.
Builtin Indicates whether the lifetime of an object is owned by the

system.
Description Human-readable descriptive phrases about the object.
MailNickname Moniker for an address book object, typically the portion of its
email name preceding the "@" symbol.
RoleDisabled Indicates whether the role should be ignored for purposes of

access checks.
RoleTemplateId Identity of the role template.
ServiceInfo Service-specific provisioning information that may be

consumed by MOAC and/or other service instances (of the
same or different service types).
TaskSetScopeReference Identifies a TaskSet and a set of Scopes associated with a Role

or RoleTemplate.
ValidationError Information published by a federated service describing a

non-transient, service-specific error regarding the properties
or link from an object administrator action to resolve.
WellKnownObject Labels a directory object, designating it as one of a pre-

defined set.
"Update Role definition" attributes

AssignableScopes Collection of authorization scopes that can be referenced

when assigning this RoleDefinition to a security principal.
GrantedPermissions Permissions granted by this RoleDefinition.
"Update Administrative Unit" attributes

Description This property is updated when you change the description of

an administrative unit.
DisplayName This property is updated when you change the name of an

administrative unit.
"Update Company" attributes

AllowedDataLocation A location in which the company's users are allowed to be

provisioned.
AuthorizedServiceInstance Names of service instances to which a plan may be deployed.

authoritative (customer, on premise) directory.
DirSyncStatus Indicates whether synchronization of address book objects in

this tenant context occurs from an authoritative (customer, on
premise) directory; an expansion of the DirSyncEnabled
property on Company objects.
DirSyncFeatures Bit flag to keep track of set of enabled and disabled dirsync
features for the tenant.
DirectoryFeatures Enabled/disabled directory features.
DirSyncConfiguration Contains all DirSync configuration specific to the current

tenant.
IsMnc A Boolean flag set to "true" iff the company is enabled for the
multinational company feature.
ObjectSettings A collection of settings applicable to the scope of the object.
PartnerCommerceUrl URL to the Partner's commerce site.
PartnerHelpUrl URL to the Partner's help site.
PartnerSupportEmail URL to the Partner's support email.
PartnerSupportTelephone URL to the Partner's support telephone.
PartnerSupportUrl URL to the Partner's support site.
StrongAuthenticationDetails Details related to StrongAuthentication.
StrongAuthenticationPolicy Strong authentication policy for the company.
TechnicalNotificationMail E-Mail address to notify technical issues pertaining to a

company.
TelephoneNumber Telephone numbers that comply with the ITU

Recommendation E.123.
TenantType The type of a tenant. If this value is not specified, the tenant is
a Company. Otherwise, possible values are: MicrosoftSupport
(0), SyndicatePartner (1), BreadthPartner (2)
BreadthPartnerDelegatedAdmin (3)
ResellerPartnerDelegatedAdmin (4)
ValueAddedResellerPartnerDelegatedAdmin (5).
VerifiedDomain A set of DNS domain names bound to a Company.
"Update Domain" attributes

Capabilities Bit flags describing the capabilities of the domain, if any.
Default Indicates whether the domain is the default value; for

example, the default UserPrincipalName suffix when an
administrator creates a new user in MOAC.
Initial Indicates whether the domain is the initial domain for the
company, as allocated by OCP. The initial domain is a unique
sub-domain of a Microsoft Online domain;
e.g.contoso3.microsoftonline.com.
LiveType Type of the corresponding Windows Live namespace, if any.
Name Identifier for the endpoint.
PasswordNotificationWindowDays The number of days before a password expires the user is

notified.
PasswordValidityPeriodDays The number of days a password is good for before it must be

changed.
Audit records are a required control for many compliance regulations. For customers using the Azure Active
Directory Audit Report to meet their compliance regulations, it is recommended that the customer submit a copy
of this help topic with the copy of the customer's exported audit report to help explain the report details. If the
auditor would like to understand the compliance regulations that Azure currently meets, direct the auditor to the
Compliance page of the Microsoft Azure Trust Center.
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.
How can you get the collection of activity data started?
AZURE AD EDITION COLLECTION START
Premium and Premium 2 When you sign-up for a license
Free The first time you open the Azure Active Directory blade or
use the reporting APIs
When is your activity data available in the Azure portal?

Immediately - If you have already been working with reports in the Azure classic portal
Within 2 hours - If you havent turned reporting on in the Azure classic portal
How can you get the collection of security signals started?
For security signals, the collection process starts when you opt-in to use the Identity Protection Center.
For how long is the collected data stored?
Activity reports
REPORT AZURE AD FREE AZURE AD PREMIUM 1 AZURE AD PREMIUM 2
Directory Audit 7 days 30 days 30 days
Sign-in Activity 7 days 30 days 30 days
Security Signals
REPORT AZURE AD FREE AZURE AD PREMIUM 1 AZURE AD PREMIUM 2
Risky sign-ins 7 days 30 days 90 days

Azure Active Directory Report Latencies
REPORT MINIMUM AVERAGE MAXIMUM
Security Reports
Irregular sign-in activity 2 hours 4 hours 8 hours
Sign-ins from unknown 2 hours 4 hours 8 hours

sources
Sign-ins after multiple 2 hours 4 hours 8 hours

failures
Sign-ins from multiple 2 hours 4 hours 8 hours

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

with suspicious activity
Sign-ins from possibly 2 hours 4 hours 8 hours

infected devices
Users with anomalous sign- 2 hours 4 hours 8 hours

in activity
Users with leaked credentials 2 hours 4 hours 8 hours
Application Reports
Account provisioning activity 2 hours 4 hours 8 hours
Account provisioning errors 2 hours 4 hours 8 hours
Application usage 2 hours 4 hours 8 hours
Password rollover status 2 hours 4 hours 8 hours
Audit & Activity Reports
Audit report 1 minute 15 minutes 30 minutes
Password reset activity 2 hours 4 hours 8 hours

(Azure AD)
Password reset activity 2 hours 4 hours 8 hours

(Identity Manager)
REPORT MINIMUM AVERAGE MAXIMUM
Password reset registration 2 hours 4 hours 8 hours

activity (Azure AD)
Password reset registration 2 hours 4 hours 8 hours

activity (Identity Manager)
Self service groups activity 2 hours 4 hours 8 hours

(Azure AD)
Self service groups activity 2 hours 4 hours 8 hours

(Identity Manager)
RMS Reports
Most active RMS users 2 hours 4 hours 8 hours
RMS usage 2 hours 4 hours 8 hours
RMS device usage 2 hours 4 hours 8 hours
RMS enabled application 2 hours 4 hours 8 hours

usage
Private Preview Reports
All User Sign-in activity 2 hours 4 hours 8 hours

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 dont 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 classic 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 classic 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
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 successfully signed in using this account. We will send an email notification to the global admins if we
encounter 10 or more anomalous sign-in events within a span of 30 days or less. Please be sure to include aad-
alerts-noreply@mail.windowsazure.com in your safe senders list.
This report indicates users who have successfully signed in after multiple consecutive failed sign in attempts.
Possible causes include:
User had forgotten their password
User is the victim of a successful password guessing brute force attack
Results from this report will show you the number of consecutive failed sign-in attempts made prior to the
successful sign-in and a timestamp associated with the first successful sign-in.
Report Settings: You can configure the minimum number of consecutive failed sign in attempts that must occur
before it can be displayed in the report. When you make changes to this setting it is important to note that these
changes will not be applied to any existing failed sign ins that currently show up in your existing report. However,
they will be applied to all future sign-ins. Changes to this report can only be made by licensed admins.
Sign ins from IP addresses with suspicious activity
This report shows sign-ins from IP addresses where suspicious activity has been detected. Suspicious activity in
this case is defined to be an unusually high ratio of failed sign-ins to successful sign-ins, which may indicate that
an IP address is being used for malicious purposes.
This report includes successful sign-ins from a user where two sign-ins appeared to originate from different
regions and the time between the sign-ins makes it impossible for the user to have traveled between those
regions. Possible causes include:
User is sharing their password with other users
User is using a remote desktop to launch a web browser for sign-in
A hacker has signed in to the account of a user from a different country
User is using a VPN or proxy
User is signed in from multiple devices at the same time, such as a desktop and a mobile phone, and the IP
address of the mobile phone is unusual.
Results from this report will show you the successful sign-in events, together with the time between the sign-ins,
the regions where the sign-ins appeared to originate from, and the estimated travel time between those regions.
The travel time shown is only an estimate and may be different from the actual travel time between the locations.
Sign ins from possibly infected devices
This report attempts to identify your users' devices that that have become infected and are now part of a botnet.
We correlate IP addresses of users' sign-ins against IP addresses that we know to be in contact with botnet servers.
Recommendation: This report flags IP addresses, not user devices. We recommend that you contact the user and
scan all the user's devices to be certain. It is also possible that a user's personal device is infected, or that someone
other than the user, who was using the same IP address as the user, has an infected device.
For more information about how to address malware infections, see the Malware Protection Center.
Sign ins from unknown sources
This report indicates users who have successfully signed in to your directory while assigned a client IP address that
has been recognized by Microsoft as an anonymous proxy IP address (for example, a Tor IP address). These proxies
are often used by users that want to hide their computers IP address, and may be used for malicious intent.
Results from this report will show the number of times a user successfully signed in to your directory from that
address and the proxys IP address.
Users with anomalous sign in activity
This is an aggregate report that combines suspicious sign-ins from the following reports:
Sign ins from unknown sources
Sign-ins from possibly infected devices
Manage passwords in Azure Active Directory
If you are an administrator, you can reset a users password in Azure Active Directory (Azure AD) in the Azure
classic portal. Click the name of your directory and on the Users page, click the name of the user and at the bottom
of the portal click Reset Password.
This rest of this topic covers the full set of password management capabilities that Azure AD supports, including:
Self-service password change allows end users or administrators to change their expired or non-expired
passwords without calling an administrator or helpdesk for support.
Self-service password reset allows end users or administrators to reset their passwords automatically
without calling an administrator or helpdesk for support. Self-service password reset requires Azure AD
Premium or Basic. For more information, see Azure Active Directory editions.
Administrator-initiated password reset allows an administrator to reset an end users or another
administrators password from within the Azure classic portal.
Password management activity reports give administrators insights into password reset and registration
activity occurring in their organization.
Password writeback allows management of on-premises passwords from the cloud so all of the above
scenarios can be performed by, or on the behalf of, federated or password synchronized users. Password
writeback requires Azure AD Premium. For more information, see Getting started with Azure Active Directory
Premium.
NOTE
Azure AD Premium is available for Chinese customers using the world wide instance of Azure AD. Azure AD Premium is not
currently supported in the Microsoft Azure service operated by 21Vianet in China. For more information, contact us at the
Azure Active Directory Forum.
Use the following links to jump to the documentation you are most interested in:
Overview: password management in Azure AD
Self-service password reset in Azure AD: how to enable, configure, and test self-service password reset
Self-service password reset in Azure AD: how to customize password reset to meet your needs
Self-service password reset in Azure AD: deployment and management best practices
Password management reports in Azure AD: how to view password management activity in your tenant
Password writeback: how to configure Azure AD to manage on-premises passwords
Troubleshooting Azure AD password management
FAQ for Azure AD password management
What's next
Create or edit users in Azure AD
How to update your own password
If you are unsure how to manage your work or school account password, you've come to the right place! Read
below to learn how to perform common steps, like changing a password, resetting a password, or registering for
password reset.
Dont lose access to your account!
How to change your password from Office 365
How to change your password from the access panel
How to reset your password
How to unlock your account
Common problems and their solutions
Dont lose access to your account!

IMPORTANT
Why am I seeing this? If you followed a link to get here, you're probably seeing this because your administrator requires
you to register for password reset to gain access to your app. You might be asked for phone or email information, or to
set up security questions. Dont worry we wont use this information to spam you, just to keep your account more
secure. The steps presented here should help you to reach your goal.
The fastest way to register for password reset is to go to http://aka.ms/ssprsetup.

1. Navigate to http://aka.ms/ssprsetup.
2. Enter your username and password.
3. Choose an option to register for by clicking set it up now. In this case, I'll demonstrate registering my
authentication phone.
4. Select your country code from the dropdown and enter your full phone number + area code.
5. Select one of the text me or call me options. In this case, I'll select text me, which will send a 6 digit
code to my phone. Wait for the code to arrive on your phone.
6. Once the code arrives, enter it into the input box, and then click "verify."
7. When you see thanks, that's it! Now you can use what you registered for to reset your password at any
time by going to https://passwordreset.microsoftonline.com.
IMPORTANT
If your admin lets you register for more than one option, we highly recommend you also register a back-up
option in case you lose your phone or access to your email.
How to change your password from O365

Follow the steps below to change your work or school account password in Office 365. If you have forgotten
your password and want to reset it, follow the steps here.
1. Sign in to Office 365 with your work or school account.
2. Go to Settings > Office 365 settings > Password > Change password.
3. Type your old password, and then type a new password and confirm it.
4. Click Save.
You can read more about this on the Office 365 documentation center.
How to change your password from the access panel

Follow the steps below to change your work or school account password from the Access Panel. If you have
forgotten your password and want to reset it, follow the steps here.
1. Sign into https://myapps.microsoft.com with your work or school account.
2. Click on the profile tab.
3. Click on the change my password tile on the right hand side of the screen.
4. Type your old password, and then type a new password and confirm it.
5. Click Submit.
Run into a problem changing your password? Read about common problems and their solutions.
How to reset your password

Follow the steps below to reset your work or school account password from any work or school account sign in
screen.
IMPORTANT
This feature is only available to you if your admin has turned it on. If it's not turned on, you'll see a message indicating
your account is not enabled for this feature. You can use the "contact your administrator" link in this case to get in touch
with your admin to unlock your account.
If your admin has enabled you for this feature, you'll first need to sign up before you can use it. You can do that here:
http://aka.ms/ssprsetup.
1. On the any work or school account sign-in page, click on one of the "can't access your account?" or
"forgot your password?" links, or navigate to https://passwordreset.microsoftonline.com directly.
2. On the "who are you?" page, enter your work or school account ID and prove you aren't a robot by
passing the CAPTCHA challenge.
3. Click the "next" button.

4. Choose an option to reset your password. Depending on how your admin has configured the system, you
might see one or more of the following choices:
Email my alternate email - sends an email with a 6 digit code to either your alternate email or
authentication email (you choose).
Text my mobile phone - texts your phone with a 6 digit code to either your mobile phone or
Call my mobile phone - calls your mobile phone or authentication phone (you choose) - press
the # key to verify the call.
Call my office phone - calls your office phone - press the # key to verify the call.
Answer my security questions - displays your pre-registered security questions for you to answer.
5. We'll use the "text my mobile phone" option as an example. If you are using a phone based option, you'll
need to verify your phone number before we'll send a text. Enter your full phone number and then click
Next to verify it's correct and send a text.
6. When you receive the text, make sure you use the verification code in the message body, not the number
the code was sent from. It might take a few minutes to get the text, so grab a coffee!
7. Now, enter the code you just received on your phone into the input box on the page.
8. Your admin may require a second verification step, in which case repeat step 4 with a different option
selected.
9. On the "choose a new password" screen, select a new password and confirm your choice, then click
Finish.
10. Once you see the success page, you are good to go! You can now sign in with your new password.
Run into a problem resetting your password? Read about common problems and their solutions.
How to unlock your account

Follow the steps below to unlock your local account from any work or school account sign in screen. Note: You
will only be able to unlock your account if it has been locked on-premises.
IMPORTANT
This feature is only available to you if your admin has turned it on. If it's not turned on, you'll see a message indicating
your account is not enabled for this feature. You can use the "contact your administrator" link in this case to get in touch
with your admin to unlock your account.
If your admin has enabled you for this feature, you'll first need to sign up before you can use it. You can do that here:
1. On the any work or school account sign in page, click on one of the "can't access your account?" or
"forgot your password?" links, or navigate to https://passwordreset.microsoftonline.com directly.
2. On the "who are you?" page, enter your work or school account ID and prove you aren't a robot by
passing the CAPTCHA challenge.
3. Click the "next" button.

4. Choose an option to unlock your account. Depending on how your admin has configured the system, you
might see one or more of the following choices:
Email my alternate email - sends an email with a 6 digit code to either your alternate email or
Text my mobile phone - texts your phone with a 6 digit code to either your mobile phone or
Call my mobile phone - calls your mobile phone or authentication phone (you choose) - press
the # key to verify the call.
Call my office phone - calls your office phone - press the # key to verify the call.
Answer my security questions - displays your pre-registered security questions for you to answer.
5. We'll use the "text my mobile phone" option as an example. If you are using a phone based option, you'll
need to verify your phone number before we'll send a text. Enter your full phone number and then click
Next to verify it's correct and send a text.
6. When you receive the text, make sure you use the verification code in the message body, not the number
the code was sent from. It might take a few minutes to get the text, so grab a coffee!
7. Now, enter the code you just received on your phone into the input box on the page.
8. Your admin may require a second verification step, in which case you must repeat step 4 with a different
option selected.
9. Once you see the success page, you are good to go! Your on-premises account has been unlocked and
you can now sign in once more.
IMPORTANT
Make sure you update all your devices to your newest password, as often times a rogue app with an old password
(like your phone email client) can be the culprit behind why your account got locked out in the first place.
Run into a problem unlocking your account? Read about common problems and their solutions.
Common problems and their solutions

Here are some common error cases and their solutions:
Error Case What error do you see? Solution

I get a "please contact your admin" Please contact your admin You are seeing this message
page after entering my user ID because your administrator
We've detected that your user manages your password in your
account password is not managed on-premises environment and
by Microsoft. As a result, we are does not allow you to reset your
unable to automatically reset your password from the Can't access
password. your account link.
You will need to contact your To reset your password, please

admin or helpdesk for any further contact your administrator directly
assistance. for help, and let him or her know
you want to reset your password
from Office 365 so he or she can
enable this feature for you.
I get a "your account is not Your account is not enabled for You are seeing this message
enabled for password reset" error password reset because your administrator has
after entering my user ID not enabled password reset for
We're sorry, but your your organization from the Can't
administrator has not set up your access your account link, or
account for use with this service. hasn't licensed you to use the
feature.
If you'd like, we can contact an
administrator in your organization To reset your password, click the
to reset your password for you. contact an administrator link to
send an email to your company's
admin, and let him or her know
you want to reset your password
from Office 365 so he or she can
enable this feature for you.
I get a "we could not verify your We could not verify your account You are seeing this message
account" error after entering my because you are enabled for
user ID If you'd like, we can contact an password reset, but you have not
administrator in your organization registered to use the service. To
to reset your password for you. register for password reset, go to
http://aka.ms/ssprsetup after you
have regained access to your
account.
To reset your password, click the

contact an administrator link to
send an email to your company's
admin.
Links to password reset documentation

Below are links to all of the Azure AD Password Reset documentation pages:
How it works - learn about the six different components of the service and what each does
Getting started - learn how to allow you users to reset and change their cloud or on-premises passwords
Customize - learn how to customize the look & feel and behavior of the service to your organization's needs
Best practices - learn how to quickly deploy and effectively manage passwords in your organization
Get insights - learn about our integrated reporting capabilities
FAQ - get answers to frequently asked questions
Troubleshooting - learn how to quickly troubleshoot problems with the service
Learn more - go deep into the technical details of how the service works
How Password Management works
IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
password.
Password Management in Azure Active Directory is comprised of several logical components that are described
below. Click on each link to learn more about that component.
Password Management Configuration Portal Administrators can control different facets of how
passwords are managed in their tenants by navigating to their directorys Configure tab in the Azure
Management Portal.
User Registration Portal Users can self-register for password reset through this web portal.
User Password Reset Portal Users can reset their own passwords using a number of different challenges in
accordance with the administrator-controlled password reset policy
User Password Change Portal Users can change their own passwords at any time by entering their old
password and selecting a new password using this web portal
Password Management Reports Administrators can view and analyze password reset and registration
activity in their tenant by navigating to the Activity Reports section of their directorys Reports tab in the
Azure Management Portal
Password Writeback Component of Azure AD Connect Administrators can optionally enable the
Password Writeback feature when installing Azure AD Connect to enable management of federated or
password synchronized user passwords from the cloud.
Password Management Configuration Portal

You can configure Password Management policies for a specific directory using the Azure Management Portal by
navigating to the User Password Reset Policy section in the directorys Configure tab. From this configuration
page, you can control many aspects of how passwords are managed in your organization, including:
Enabling and disabling password reset for all users in a directory
Setting the number of challenges (either one or two) a user must go through to reset his or her password
Setting the specific types of challenges you want to enable for users in your organization from the choices
below:
Mobile Phone (a verification code via text or a voice call)
Office Phone (a voice call)
Alternate Email (a verification code via email)
Security Questions (knowledge-based authentication)
Setting the number of questions a user must register in order to use the security questions authentication
method (only visible if security questions are enabled)
Setting the number of questions a user must supply during reset to use the security questions authentication
method (only visible if security questions are enabled)
Using pre-canned, localized, security questions that a user may choose to use when registering for password
reset (only visible if security questions are enabled)
Defining the custom security questions that a user may choose to use when registering for password reset
(only visible if security questions are enabled)
Requiring users to register for password reset when they go to the application Access Panel at
http://myapps.microsoft.com.
Requiring users to re-confirm their previously registered data after a configurable number of days have
passed (only visible if enforced registration is enabled)
Providing a custom helpdesk email or URL that will be shown to users in case they have a problem resetting
their passwords
Enabling or disabling the Password Writeback capability (when Password Writeback has been deployed using
AAD Connect)
Viewing the status of the Password Writeback agent (when Password Writeback has been deployed using AAD
Connect)
Enabling email notifications to users when their own password has been reset (found in the Notifications
section of the Azure Management Portal)
Enabling email notifications to administrators when other administrators reset their own passwords (found in
the Notifications section of the Azure Management Portal
Branding the user password reset portal and password reset emails with your organizations logo and name
by using the tenant branding customization feature (found in the Directory Properties section of the Azure
Management Portal
To learn more about configuring Password Management in your organization, see Getting Started: Azure AD
Password Management.
User Registration Portal

Before users are able to use password reset, their cloud user accounts must be updated with the correct
authentication data to ensure that they can pass through the appropriate number of password reset challenges
defined by their administrator. Administrators can also define this authentication information on their users
behalf by using the Azure or Office web portals, DirSync / Azure AD Connect, or Windows PowerShell.
However, if youd rather have your users register their own data, we also provide a web page that users can go to
in order to provide this information. This page will allow users to specify authentication information in
accordance with the password reset policies that have been enabled in their organization. Once this data is
verified, it is stored in their cloud user account to be used for account recovery at a later time. Heres what the
registration portal looks like:
For more information, see Getting Started: Azure AD Password Management and Best Practices: Azure AD
Password Management.
User Password Reset Portal

Once you have enabled self-service password reset, set up your organizations self-service password reset policy,
and ensured that your users have the appropriate contact data in the directory, users in your organization will be
able to reset their own passwords automatically from any web page which uses a Work or School account for
sign in (such as portal.microsoftonline.com). On pages such as these, users will see a Cant access your
account? link.
Clicking on this link will launch the self-service password reset portal.
To learn more about how users can reset their own passwords, see Getting Started: Azure AD Password
Management.
User Password Change Portal
If users want to change their own passwords, they can do so by using the password change portal at any time.
Users can access the password change portal via the Access Panel profile page, or clicking the change password
link from within Office 365 applications. In the case when their passwords expire, users will also be asked to
change them automatically when signing in.
In both of these cases, if Password Writeback has been enabled and the user is either federated or password
syncd, these changed passwords are written back to your on-premises Active Directory. Heres what the
password change portal looks like:
To learn more about how users can change their own on-premises Active Directory passwords, see Getting
Started: Azure AD Password Management.
Password Management reports

By navigating to the Reports tab and looking under the Activity Logs section, you will see two Password
Management reports: Password reset activity and Password reset registration activity. Using these two
reports, you can get a view of users registering for and using password reset in your organization. Heres what
these reports look like in the Azure Management Portal:
For more information, see Get Insights: Azure AD Password Management Reports.
Password Writeback component of Azure AD Connect

If the passwords of users in your organization originate from your on-premises environment (either via
federation or password synchronization), you can install the latest version of Azure AD Connect to enable
updating those passwords directly from the cloud. This means that when your users forget or want to modify
their AD password, they can do so straight from the web. Heres where to find Password Writeback in the Azure
AD Connect installation wizard:
For more information about Azure AD Connect, see Get Started: Azure AD Connect. For more information about
Password Writeback, see Getting Started: Azure AD Password Management.

Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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 AD directory.
IMPORTANT
password.
UserPrincipalName policies that apply to all user accounts

Every user account that needs to sign in to the Azure AD authentication system must have a unique user principal
name (UPN) attribute value associated with that account. The following table outlines the polices that apply to both
on-premises Active Directory-sourced user accounts (synced to the cloud) and to cloud-only user accounts.
PROPERTY USERPRINCIPALNAME REQUIREMENTS
Characters allowed AZ
a-z
09
.-_!#^~
Characters not allowed Any '@' character that is not separating the user name
from the domain.</li> <li>Cannot contain a period
character '.' immediately preceding the '@' symbol
Length constraints Total length must not exceed 113 characters

64 characters before the @ symbol
48 characters after the @ symbol
Password policies that apply only 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 AZ
a-z
09
@#$%^&*-_!+=[]{}|\:,.?/`~();
PROPERTY REQUIREMENTS
Characters not allowed Unicode characters

Spaces
Strong passwords only: Cannot contain a dot
character '.' immediately preceding the '@' symbol
Password restrictions 8 characters minimum and 16 characters maximum

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

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

Value is configurable using the Set-
MsolPasswordPolicy cmdlet.
Password Expiry Default value: false days (indicates that password

expiry is enabled)
Value can be configured for individual user accounts
using the Set-MsolUser cmdlet.
Password history Last password cannot be used again.
Password history duration Forever
Account Lockout After 10 unsuccessful sign-in attempts (wrong password), the

user will be locked out for one minute. Further incorrect sign-
in attempts will lock out the user for increasing durations.
Next Steps
Are you here because you're having problems signing in? If so, here's how you can change and reset your
own password.
Manage your passwords from anywhere
How Password Management works
Getting started with Password Mangement
Customize Password Management
Password Management Best Practices
How to get Operational Insights with Password Management Reports
Password Management FAQ
Troubleshoot Password Management
Learn More
Reset the password for a user in Azure Active
Directory preview
How to reset the password for a user


5. On the blade for the selected user, select Overview, and then in the command bar, select Reset
password.
6. On the Reset password blade, select Reset password.
What's next
Add a user
Reset the password for a user
Whether you're responding to a user requesting a password reset after a lockout, or just attending to routine
security maintenance, sometimes you need to reset a user's password. Azure Active Directory (Azure AD) makes
this easy.
2. Select the Users tab, and then select the display name of the user you want to change.
3. In the command bar, select Reset Password.
4. In the reset password dialog, click reset.
5. Select the check mark to finish resetting the password.
What's next
Add new users to Azure Active Directory
Set password expiration policies in Azure Active
Directory
IMPORTANT
password.
As a global administrator for a Microsoft cloud service, you can use the Microsoft Azure Active Directory Module
for Windows PowerShell to set up 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 up not to expire. This article
provides help for cloud services, such as Microsoft Intune and Office 365, which rely on Microsoft Azure Active
Directory for identity and directory services.
NOTE
Only passwords for user accounts that are not synchronized through directory synchronization can be configured not to
expire. For more information about directory synchronization, see the list of topics in Directory synchronization roadmap.
To use Windows PowerShell cmdlets, you first must install them.
What do you want to do?

How to check expiration policy for a password
Set a password to expire
Set a password so that it will not expire
How to check expiration policy for a password

1. Connect to Windows PowerShell using your company administrator credentials.
2. Do one of the following:
To see whether a single users password is set to never expire, run the following cmdlet by using the user
principal name (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 will expire, run the following cmdlet by using the
user principal name (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 will 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 user principal
name (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
Next steps
own password.
Getting started with Password Management
IMPORTANT
password.
Enabling your users to manage their own cloud Azure Active Directory or on-premises Active Directory
passwords takes just a few simple steps. After ensuring that you've met a few simple prerequisites, you'll have
password change and reset enabled for your entire organization before you know it. This article will walk you
through the following concepts:
How to enable users to reset their cloud Azure Active Directory passwords
Self-service password reset prerequisites
Step 1: Configure password reset policy
Step 2: Add contact data for your test user
Step 3: Reset your password as a user
How to enable users to reset or change their on-premises Active Directory passwords
Password Writeback prerequisites
Step 1: Download the latest version of Azure AD Connect
Step 2: Enable Password Writeback in Azure AD Connect through the UI or PowerShell and verify
Step 3: Configure your firewall
Step 4: Set up the appropriate permissions
Step 5: Reset your AD password as a user and verify
Enable users to reset their Azure AD passwords

This section walks you through enabling self-service password reset for your AAD cloud directory, registering
users for self-service password reset, and then finally performing a test self-service password reset as a user.
Self-service password reset prerequisites
Step 3: Reset your password as a user
Prerequisites
Before you can enable and use self-service password reset, you must complete the following prerequisites:
Create an AAD tenant. For more information, see Getting Started with Azure AD
Obtain an Azure subscription. For more information, see What is an Azure AD tenant?.
Associate your AAD tenant with your Azure subscription. For more information, see How Azure
subscriptions are associated with Azure AD.
Upgrade to Azure AD Premium, Basic, or use an O365 paid license. For more information, see Azure
Active Directory Editions.
NOTE
To enable self-service password reset for cloud users, you must upgrade to Azure AD Premium, Azure AD Basic,
or a paid O365 license. To enable-self-service password reset for your on-premises users, you must upgrade to
Azure AD Premium. For more information, see Azure Active Directory Editions. This information includes detailed
instructions on how to sign up for Azure AD Premium or Basic, how to activate your license plan and activate
your Azure AD access, and how to assign access to administrator and user accounts.
Create at least one administrator account and one user account in your AAD directory.
Assign an AAD Premium, Basic, or O365 paid license to the administrator and user account that you created.
To configure user password reset policy, complete the following steps:
1. Open a browser of your choice and go to the Azure classic portal.
2. In the Azure classic portal, find the Active Directory extension on the navigation bar on the left hand
side.
3. Under the Directory tab, click the directory in which you want to configure the user password reset
policy, for example, Wingtip Toys.
4. Click the Configure tab.

5. Under the Configure tab, scroll down to the user password reset policy section. This is where you
configure every aspect of user password reset policy for a given directory.
NOTE
This policy applies only to end users in your organization, not administrators. For security reasons,
Microsoft controls the password reset policy for administrators. If you do not see this section, make sure that you
have signed up for the Azure Active Directory Premium or Basic and assigned a license to the administrator
account that is configuring this feature.
6. To configure the user password reset policy, slide the users enabled for password reset toggle to the
yes setting. This reveals several more controls which enable you to configure how this feature works in
your directory. Feel free to customize password reset as you see fit. If youd like to learn more about
what each of the password reset policy controls does, please see Customize: Azure AD Password
Management.
7. After configuring user password reset policy as desired for your tenant, click the Save button at the
bottom of the screen.
NOTE
A two challenge user password reset policy is recommended so that you can see how the functionality works in
the most complex case.
You have several options on how to specify data for users in your organization to be used for password reset.
Edit users in the Azure classic portal or the Office 365 Admin Portal
Use AAD Connect to synchronize user properties into Azure AD from an on-premises Active Directory
domain
Use Windows PowerShell to edit user properties
Allow users to register their own data by guiding them to the registration portal at http://aka.ms/ssprsetup
Require users to register for password reset when they sign in to the Access Panel at
http://myapps.microsoft.com by setting the Require users to register when signing in to the access
panel SSPR configuration option to Yes.
If you want to learn more about what data is used by password reset, as well as any formatting requirements
for this data, please see What data is used by password reset?.
To add user contact data via the User Registration Portal
1. In order to use the password reset registration portal, you must provide the users in your organization
with a link to this page (http://aka.ms/ssprsetup) or turn on the option to require users to register
automatically. Once they click this link, they are asked to sign in with their organizational account. After
doing so, they see the following page:
2. Here, users can provide and verify their mobile phone, alternate email address, or security questions.
This is what verifying a mobile phone looks like.
3. After a user specifies this information, the page will update to indicate that the information is valid (it has
been obfuscated below). By clicking the finish or cancel buttons, the user will be brought to the Access
Panel.
4. Once a user verifies both of these pieces of information, his or her profile will be updated with the data
he or she provided. In this example, the Office Phone number has been specified manually, so the user
can also use that as a contact method for resetting his or her password.
Step 3: Reset your Azure AD password as a user

Now that youve configured a user reset policy and specified contact details for your user, this user can perform
a self-service password reset.
To perform a self-service password reset
1. If you go to a site like portal.microsoftonline.com, youll see a login screen like the below. Click the
Cant access your account? link to test the password reset UI.
2. After clicking Cant access your account?, you are brought to a new page which will ask for a user ID
for which you wish to reset a password. Enter your test user ID here, pass the captcha, and click next.
3. Since the user has specified an office phone, mobile phone, and alternate email in this case, you see
that he or she has been given all of those as options to pass the first challenge.
4. In this case, choose to call the office phone first. Note that when selecting a phone-based method,
users will be asked to verify their phone number before they can reset their passwords. This is to
prevent malicious individuals from spamming phone numbers of users in your organization.
5. Once the user confirms their phone number, clicking call wall cause a spinner to appear and his or her
phone to ring. A message will play once he or she picks up your phone indicating that the user should
press # to verify his or her account. Pressing this key will automatically verify that the user possesses
the first challenge and advance the UI to the second verification step.
6. Once youve passed the first challenge, the UI is automatically updated to remove it from the list of
choices the user has. In this case, because you used your Office Phonefirst, only Mobile Phone and
Alternate Email remain as valid options to use as the challenge for the second verification step. Click on
the Email my alternate email option. After you have done that, pressing email will email the alternate
email on file.
7. Here is a sample of an email that users will see notice the tenant branding:
8. Once the email arrives, the page will update, and youll be able to enter the verification found in the
email in the input box shown below. After a proper code is entered, the next button lights up, and you
are able to pass through the second verification step.
9. Once youve met the requirements of the organizational policy, you are allowed to choose a new
password. The password is validated based it meets AAD strong password requirements (see Password
policy in Azure AD), and a strength validator appears to indicate to the user whether the password
entered meets that policy.
10. Once you provide matching passwords that meet the organizational policy, your password is reset and
you can log in with your new password immediately.
Enable users to reset or change their AD Passwords

This section walks you through configuring password reset to write passwords back to an on-premises Active
Directory.
Password Writeback prerequisites
Step 2: Enable Password Writeback in Azure AD Connect through the UI or PowerShell and verify
Step 4: Set up the appropriate permissions
Step 5: Reset your AD password as a user and verify
Writeback prerequisites
Before you can enable and use the Password Writeback, you must make sure you complete the following
prerequisites:
You have an Azure AD tenant with Azure AD Premium enabled. For more information, see Azure Active
Directory Editions.
Password reset has been configured and enabled in your tenant. For more information, see Enable users to
reset their Azure AD passwords
You have at least one administrator account and one test user account with an Azure AD Premium
license that you can use to test this feature. For more information, see Azure Active Directory Editions.
NOTE
Make sure that the administrator account that you use to enable Password Writeback is a cloud administrator
account (created in Azure AD), not a federated account (created in on-premises AD and synchronized into Azure
AD).
You have a single or multi-forest AD on-premises deployment running Windows Server 2008, Windows
Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 with the latest service packs
installed.
NOTE
If you are running an older version of Windows Server 2008 or 2008 R2, you can still use this feature, but will
need to download and install KB 2386717 before being able to enforce your local AD password policy in the
cloud.
You have the Azure AD Connect tool installed and you have prepared your AD environment for
synchronization to the cloud. For more information, see Use your on-premises identity infrastructure in
the cloud.
NOTE
Before you test password writeback, make sure that you first complete a full import and a full sync from both AD
and Azure AD in Azure AD Connect.
If you are using Azure AD Sync or Azure AD Connect TCP 443 outbound (and in some cases TCP 9350-
9354) need to be open. See Step 3: Configure your firewall for more information. Using DirSync for this
scenario is no longer supported. If you are still using DirSync, please upgrade to the latest version of
Azure AD Connect before deploying password writeback.
NOTE
We highly recommend anyone using the Azure AD Sync or DirSync tools upgrades to the latest version of Azure
AD Connect to ensure the best possible experience and new features as they are released.

Password Writeback is available in releases of Azure AD Connect, or the Azure AD Sync tool with version
number 1.0.0419.0911 or higher. Password Writeback with automatic account unlock is available in releases of
Azure AD Connect, or the Azure AD Sync tool with version number 1.0.0485.0222 or higher. If you are running
an older version, please upgrade to at least this version before proceeding. Click here to download the latest
version of Azure AD Connect.
To check the version of Azure AD Sync
1. Navigate to %ProgramFiles%\Azure Active Directory Sync\.
2. Find the ConfigWizard.exe executable.
3. Right-click the executable and select the Properties option from the context menu.
4. Click on the Details tab.
5. Find the File version field.
If this version number is greater than or equal to 1.0.0419.0911, or you are installing Azure AD Connect, you
can skip to Step 2: Enable Password Writeback in Azure AD Connect through the UI or PowerShell and verify.
NOTE
If this is your first time installing the Azure AD Connect tool, it is recommended that you follow a few best practices to
prepare your environment for directory synchronization. Before you install the Azure AD Connect tool, you must activate
directory synchronization in either the Office 365 Admin Portal or the Azure classic portal. For more information, see
Managing Azure AD Connect.
Step 2: Enable password writeback in Azure AD Connect

Now that you have the Azure AD Connect tool downloaded, you are ready to enable Password Writeback. You
can do this in one of two ways. You can either enable Password Writeback in the optional features screen of the
Azure AD Connect setup wizard, or you can enable it via Windows PowerShell.
To enable Password Writeback in the configuration wizard
1. On your Directory Sync computer, open the Azure AD Connect configuration wizard.
2. Click through the steps until you reach the optional features configuration screen.
3. Check the Password write-back option.
4. Complete the wizard, the final page will summarize the changes and will include the Password Writeback
configuration change.
NOTE
You can disable Password Writeback at any time by either re-running this wizard and deselecting the feature, or by
setting the Write Passwords Back to On-Premises Directory setting to No in the User Password Reset Policy
section of your directorys Configure tab in the Azure classic portal. For more information about customizing your
password reset experience, check out Customize: Azure AD Password Management.
To enable Password Writeback using Windows PowerShell

1. On your Directory Sync computer, open a new elevated Windows PowerShell window.
2. If the module is not already loaded, type in the import-module ADSync command to load the Azure AD
Connect cmdlets into your current session.
3. Get the list of Azure AD Connectors in your system by running the Get-ADSyncConnector cmdlet and storing
the results in $aadConnectorName , such as
$connectors = Get-ADSyncConnector|where-object {$\_.name -like "\*AAD"}
4. To get the current status of writeback for the current connector by running the following cmdlet:
Get-ADSyncAADPasswordResetConfiguration Connector $aadConnectorName.name
5. Enable Password Writeback by running the cmdlet:
Set-ADSyncAADPasswordResetConfiguration Connector $aadConnectorName.name Enable $true
NOTE
If prompted for a credential, make sure that the administrator account that you specify for AzureADCredential is a cloud
administrator account (created in Azure AD), not a federated account (created in on-premises AD and synchronized
into Azure AD.
NOTE
You can disable Password Writeback through PowerShell by repeating the same instructions above but passing $false
in step or by setting the Write Passwords Back to On-Premises Directory setting to No in the User Password Reset
Policy section of your directorys Configure tab in the Azure classic portal.
Verify that the configuration was successful

Once the configuration succeeds, you will see the message Password reset write-back is enabled in the
Windows PowerShell window, or a success message in the configuration UI.
You can also verify the service was installed correctly by opening Event Viewer, navigating to the application
event log, and looking for event 31005 - OnboardingEventSuccess from the source PasswordResetService.

After you have enabled Password Writeback, you need to make sure the machine running Azure AD Connect
can reach Microsoft cloud services to receive password writeback requests. This step involves updating the
connection rules in your network appliances (proxy servers, firewalls etc.) to allow outbound connections to
certain Microsoft-owned URLs and IP addresses over specific network ports. These changes may vary based on
the version of Azure AD Connect tool. For more context, you can read more about how password writeback
works and the password writeback security model.
Why do I need to do this?
In order for Password Writeback to function properly, the machine running Azure AD Connect needs to be able
to establish outbound HTTPS connections to *.servicebus.windows.net and specific IP address used by Azure, as
defined in the Microsoft Azure Datacenter IP Ranges list.
For Azure AD Connect tool versions 1.0.8667.0 and above:
Option 1: Allow all outbound HTTPS connections over port 443 (using URL or IP Address).
When to use this:
Use this option if you want the most straightforward configuration that does not need to be
updated as Azure Datacenter IP ranges change over time.
Steps required:
Allow all outbound HTTPS connections over port 443 using URL or IP address.
Option 2: Allow outbound HTTPS connections to specific IP ranges and URLs
When to use this:
Use this option if you are in a restricted network environment, or do not otherwise feel
comfortable with allowing outbound connections.
In this configuration, for password writeback to continue to work, you'll need to ensure your
networking appliances stay updated weekly with the latest IPs from the Microsoft Azure
Datacenter IP Ranges list. These IP ranges are available as an XML file which is updated every
Wednesday (Pacific Time) and put into effect the following Monday (Pacific Time).
Steps required:
Allow all outbound HTTPS connections to *.servicebus.windows.net
Allow all outbound HTTPS connections to all IPs in the Microsoft Azure Datacenter IP Ranges
list and keep this configuration updated weekly.
NOTE
If you have configured Password Writeback by following the instructions above and do not see any errors in the Azure
AD Connect event log, but you're getting connectivity errors when testing, then it may be the case that a networking
appliance in your environment is blocking HTTPS connections to IP addresses. For example, while a connection to
https://.servicebus.windows.net* is allowed, a connection to a specific IP address within that range may be blocked. To
resolve this, you'll need to either configure your networking environment to allow all outbound HTTPS connections over
port 443 to any URL or IP address (Option 1 above), or work with your networking team to explicitly allow HTTPS
connections to specific IP addresses (Option 2 above).
For older versions:

Allow outbound TCP connections over port 443, 9350-9354 and port 5671
Allow outbound connections to https://ssprsbprodncu-sb.accesscontrol.windows.net/
NOTE
If you are on a version of Azure AD Connect prior to 1.0.8667.0, Microsoft highly recommends you upgrade to the latest
version of Azure AD Connect, which includes a number of writeback networking enhancements to make configuration
easier.
Once the network appliances have been configured, reboot the machine running Azure AD Connect tool.
Step 4: Set up the appropriate Active Directory permissions
For every forest that contains users whose passwords will be reset, if X is the account that was specified for that
forest in the configuration wizard (during initial configuration), then X must be given the Reset Password,
Change Password, Write Permissions on lockoutTime , and Write Permissions on pwdLastSet , extended
rights on the root object of each domain in that forest. The right should be marked as inherited by all user
objects.
If you are not sure what account the above refers to, open the Azure Active Directory Connect configuration UI
and click on the Review Your Solution option. The account you need to add permission to is underlined in red
in the screenshot below.
Make sure you set this permission for each domain in each forest in your system, otherwise password
writeback will not work properly.
Setting these permissions will allow the MA service account for each forest to manage passwords on behalf of
user accounts within that forest. If you neglect to assign these permissions, then, even though writeback will
appear to be configured correctly, users will encounter errors when attempting to manage their on-premises
passwords from the cloud. Here are the detailed steps on how you can do this using the Active Directory
Users and Computers management snap-in:
NOTE
It could take up to an hour for these permissions to replicate to all objects in your directory.
To set up the right permissions for writeback to occur

1. Open Active Directory Users and Computers with an account that has the appropriate domain
administration permissions.
2. In the View Menu option, make sure Advanced Features is turned on.
3. In the left panel, right click the object that represents the root of the domain.
4. Click on the Security tab.
5. Then click Advanced.
6. On the Permissions tab, click Add.
7. Select the account you want to give permissions to (this is the same account that was specified while setting
up sync for that forest).
8. In the drop down on the top, select Descendent User objects.
9. In the Permission Entry dialog box that shows up, check the box for Reset Password, Change
Password, Write Permissions on lockoutTime , and Write Permissions on pwdLastSet .
10. Then click Apply/Ok through all the open dialog boxes.
Step 5: Reset your AD password as a user
Now that Password Writeback has been enabled, you can test that it works by resetting the password of a user
whose account has been synchronized into your cloud tenant.
To verify Password Writeback is working properly
1. Navigate to https://passwordreset.microsoftonline.com or go to any organizational ID login screen and
click the Cant access your account? link.
2. You should now see a new page which asks for a user ID for which you want to reset a password. Enter your
test user ID and proceed through the password reset flow.
3. After you reset your password, you will see a screen that looks similar to this. It means you have
successfully reset your password in your on-premises and/or cloud directories.
4. To verify the operation was successful or diagnose any errors, go to your Directory Sync computer,
open Event Viewer, navigate to the application event log, and look for event 31002 -
PasswordResetSuccess from the source PasswordResetService for your test user.
your own password.
Customize - learn how to customize the look & feel and behavior of the service to your organization's
needs
Deploying Password Management and training users
to use it
IMPORTANT
password.
After enabling password reset, the next step you need to take is to get users using the service in your
organization. To do this, you'll need to make sure your users are configured to use the service properly and also
that your users have the training they need to be successful in managing their own passwords. This article will
explain to you the following concepts:
How to get your users configured for Password Management
What makes an account configured for password reset
Ways you can to populate authentication data yourself
The best ways to roll out password reset to your organization
Email-based rollout + sample email communications
Create your own custom password management portal for your users
How to use enforced registration to force users to register at sign in
How to upload authentication data for user accounts
Sample user and support training materials (coming soon!)
How to get users configured for password reset

This section describes to you various methods by which you can ensure every user in your organization can use
self-service password reset effectively in case they forget their password.
What makes an account configured
Before a user can use password reset, all of the following conditions must be met:
1. Password reset must be enabled in the directory. Learn how to enable password reset by reading Enable users
to reset their Azure AD Passwords or Enable users to reset or change their AD Passwords
2. The user must be licensed.
For cloud users, the user must have any paid Office 365 license, or an AAD Basic or AAD Premium
license assigned.
For on-prem users (federated or hash synced), the user must have an AAD Premium license
assigned.
3. The user must have the minimum set of authentication data defined in accordance with the current
password reset policy.
Authentication data is considered defined if the corresponding field in the directory contains well-
formed data.
A minimum set of authentication data is defined as at least one of the enabled authentication options
if a one gate policy is configured, or at least two of the enabled authentication options if a two gate
policy is configured.
4. If the user is using an on-premises account, then Password Writeback must be enabled and turned on
Ways to populate authentication data
You have several options on how to specify data for users in your organization to be used for password reset.
Edit users in the Azure Management Portal or the Office 365 Admin Portal
Use Azure AD Sync to synchronize user properties into Azure AD from an on-premises Active Directory
domain
Use Windows PowerShell to edit user properties by following the steps here.
Allow users to register their own data by guiding them to the registration portal at http://aka.ms/ssprsetup
Require users to register for password reset when they sign in to their Azure AD account by setting the
Require users to register when signing in? configuration option to Yes.
Users need not register for password reset for the system to work. For example, if you have existing mobile or
office phone numbers in your local directory, you can synchronize them in Azure AD and we will use them for
password reset automatically.
You can also read more about how data is used by password reset and how you can populate individual
authentication fields with PowerShell.
What is the best way to roll out password reset for users?
The following are the general rollout steps for password reset:
1. Enable password reset in your directory by going to the Configure tab in the Azure Management Portal and
selecting Yes for the Users Enabled for Password Reset option.
2. Assign the appropriate licenses to each user to whom youd like to offer password reset in the by going to the
Licenses tab in the Azure Management Portal.
3. Optionally restrict password reset to a group of users to roll out the feature slowly over time by setting the
Restrict Access to Password Reset toggle to Yes and selecting a security group to enable for password reset
(note these users must all have licenses assigned to them).
4. Instruct your users to use password reset by either sending them an email instructing them to register,
enabling enforced registration on the access panel, or by uploading the appropriate authentication data for
those users yourself via DirSync, PowerShell, or the Azure Management Portal. More details on this are
provided below.
5. Over time, review users registering by navigating to the Reports tab and viewing the Password Reset
Registration Activity report.
6. Once a good number of users have registered, watch them use password reset by navigating to the Reports
tab and viewing the Password Reset Activity report.
There are several ways to inform your users that they can register for and use password reset in your
organization. They are detailed below.
Email-based rollout
Perhaps the simplest approach to inform your users about to register for or use password reset is by sending
them an email instructing them to do so. Below is a template you can use to do this. Feel free to replace the
colors / logos with those of your own choosing to customize it to fit your needs.
You can download the email template here.
Creating your own password portal
One strategy that works well for larger customers deploying password management capabilities is to create a
single "password portal" that your users can use to manage all things related to their passwords in a single place.
Many of our largest customers choose to create a root DNS entry, like https://passwords.contoso.com with links
to the Azure AD password reset portal, password reset registration portal, and password change pages. This way,
in any email communications or fliers you send out, you can include a single, memorable, URL that users can go
to when they have a second to get started with the service.
To get going here, we've created a simple page that uses the latest responsive UI design paradigms, and will
work on all browsers and mobile devices.
You can download the website template here. We recommend customizing the logo and colors to the need of
your organization.
Using enforced registration
If you want your users to register for password reset themselves, you can also force them to register when they
sign in to the access panel at http://myapps.microsoft.com. You can enable this option from your directorys
Configure tab by enabling the Require Users to Register when Signing in to the Access Panel option.
You can also optionally define whether or not they will be asked to re-register after a configurable period of time
by modifying the Number of days before users must confirm their contact data option to be a non-zero
value. See Customizing User Password Management Behavior for more information.
After you enable this option, when users sign in to the access panel, they will see a popup that informs them that
their administrator has required them to verify their contact information. They can use it to reset their password
if they ever lose access to their account.
Clicking Verify Now brings them to the password reset registration portal at http://aka.ms/ssprsetup and
requires them to register. Registration via this method can be dismissed by clicking the cancel button or closing
the window, but users are reminded every time they sign in if they do not register.
Uploading data yourself

If you want to upload authentication data yourself, then users need not register for password reset before being
able to reset their passwords. As long as users have the authentication data defined on their account that meets
the password reset policy you have defined, then those users will be able to reset their passwords.
To learn what properties you can set via AAD Connect or Windows PowerShell, see What data is used by
password reset.
You can upload the authentication data via the Azure Management Portal by following the steps below:
1. Navigate to your directory in the Active Directory extension in the Azure Management Portal.
2. Click on the Users tab.
3. Select the user you are interested in from the list.
4. On the first tab, you will find Alternate Email, which can be used as a property to enable password reset.
5. Click on the Work Info tab.

6. On this page, you will find Office Phone, Mobile Phone, Authentication Phone, and Authentication
Email. These properties can also be set to allow a user to reset his or her password.
See What data is used by password reset to see how each of these properties can be used.
See How to access password reset data for your users from PowerShell to see how you can read and set this data
with PowerShell.
Sample training materials

We are working on sample training materials that you can use to get your IT organization and your users up to
speed quickly on how to deploy and use password reset. Stay tuned!
your own password.
Azure AD Password Reset for IT Administrators
IMPORTANT
Are you here because you want to reset your Azure or O365 password? If so, please skip to this section.
Self-service has long been a key goal for IT departments across the world as a cost-reduction and labor-saving
measure. Indeed, the market is flooded with products that let you manage your on-premises groups, passwords, or
user profiles from the cloud or on-premises. Azure AD sets itself apart from these offerings by providing some of
the easiest to use and most powerful self-service capabilities available today.
Azure AD Password Management is a set of capabilities that allow your users to manage any password from
any device, at any time, from any location, while remaining in compliance with the security policies you define.
ADMINS: Learn about how to get started with Azure AD Password

Reset
If you're an admin who wants to enable Azure AD Password Reset, or just learn more about it, start with the links
below to get to what you're interested in.
TOPIC
Supported scenarios What is possible with Azure AD Password Reset?
Why use it? Why use Azure AD Password Reset?
Pricing and availability Pricing and availability
Enable password reset Enable password reset for your users
Customize how it works Customize password reset behavior
Roll it out to my users Configure your users to use password reset
View reports View password reset activity with integrated reports
Reset a user's password Manage your users' passwords
Set my organization's password policies Set password policies
Troubleshoot a problem Troubleshoot a problem
FAQ Read a FAQ
Technical details Understand the technical details
Newly released features Recent service updates

TOPIC
Links to other documentation Links to password reset documentation
What is possible with Azure AD Password Reset?

Here are some of the things you can do with Azure AD's password management capabilities.
Self-service password change allows end users or administrators to change their expired or non-expired
passwords without calling an administrator or helpdesk for support.
Self-service password reset allows end users or administrators to reset their passwords automatically
without calling an administrator or helpdesk for support. Self-service password reset requires Azure AD
Premium or Basic. For more information, see Azure Active Directory Editions.
Administrator-initiated password reset allows an administrator to reset an end users or another
administrators password from within the Azure Management Portal.
Password management activity reports give administrators insights into password reset and registration
activity occurring in their organization.
Password Writeback allows management of on-premises passwords from the cloud so all of the above
scenarios can be performed by, or on the behalf of, federated or password synchronized users. Password
Writeback requires Azure AD Premium. For more information, see Getting started with Azure AD Premium.
Why use Azure AD Password Reset?
Here are some of the reasons you should use Azure AD's password management capabilities
Reduce costs - support-assisted password reset is typically 20% of organization's IT spend
Improve user experiences - users don't want to call helpdesk and spend an hour on the phone every time
they forget their passwords
Lower helpdesk volumes - password management is the single largest helpdesk driver for most
organizations
Enable mobility - users can reset their passwords from wherever they are
Pricing and availability
Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:
Azure AD Free - cloud-only administrators can reset their own passwords
Azure AD Basic or any Paid O365 Subscription - cloud-only users and cloud-only administrators can reset
their own passwords
Azure AD Premium - any user or administrator, including cloud-only, federated, or password synced users,
can reset their own passwords (requires password writeback to be enabled)
For more information on Azure AD Premium or Basic pricing, visit the Active Directory Pricing Details page.
Enable password reset for your users

TOPIC
How do I enable password reset for cloud users? Enable users to reset their cloud Azure Active Directory
passwords
How do I enable password reset and change for on-premises Enable users to reset or change their on-premises Active
users? Directory passwords
How do I scope password reset to a specific set of users? Restrict password reset to specific users
TOPIC
How do I test cloud password reset? Reset your Azure AD password as a user
How do I test on-premises password reset? Reset your on-premises AD password as a user
How do I disable password reset at a later time? Setting: users enabled for password reset
Customize password reset behavior

TOPIC
How do I change what authentication methods are Setting: authentication methods available to users
supported?
How do I change number of authentication methods Setting: number of authentication methods required
required?
How do I set up custom security questions? Setting: custom security questions
How do I set up pre-canned localized security questions? Setting: knowledge-based security questions
How can I change how many security questions are required? Setting: number of security questions for registration or reset
How can I customize how a user gets in touch with an admin? Setting: customize the "contact your administrator" link
How can I allow users to unlock AD accounts without Setting: enable users to unlock their AD accounts without
resetting a password? resetting a password
How can I enable password reset notifications for users? Setting: notify users when their passwords have been reset
How can I enable password reset notifications for admins? Setting: notify other admins when an admin reset their own
password
How can I customize password reset look and feel? Setting: company name, branding, and logo
Configure your users to use password reset

TOPIC
How do I know if an account is configured for password reset? What makes an account configured for password reset?
How do I get my users configured for password reset? Ways to populate password reset authentication data for your
users
How do I manually upload data for my users? Uploading password reset data yourself
How do I use PowerShell to read or set data for my users? How to access password reset data for your users
How can I synchronize password reset data from on- What data is used by password reset
premises?
TOPIC
How can I use an email campaign to get my users to register Email-based rollout of password reset
for and use password reset?
How can I force my users to register when signing in? Enforced registration-based rollout of password reset
How can I force my users to re-confirm their registered Setting: number of days before users must re-confirm their
periodically? authentication data
What are best practices around communicating password Creating your own password portal for your users to use
reset to end users?
View password reset activity with integrated reports

TOPIC
Where do I go to see password reset reports? Overview of password management reports
Where can I see how users are using password reset in my View password reset activity
organization?
Where can I see how many users are registering, and what View password reset registration activity
they are registering for?
How can I get password reset reports from an API? Creating an azure ad application to access the reporting API
What kind of password reset reporting information is available Password reset and registration events available in the
through an API? reporting API
Manage your users' passwords

TOPIC
How do I reset a user's password from the O365 Reset a user's password in Office 365
management portal?
How do I reset a user's password using PowerShell? Reset a user's password with Set-MsolUserPassword
Set password policies

TOPIC
How do I set organization password expiration policy from Set password expiration policy
Office 365?
How do I set a specific user's passwords to never expire with Set individual user's password to never expire using
PowerShell? PowerShell
How do I find out whether a user's password is set to never Check individual user's password expiration status using
expire using PowerShell PowerShell
Troubleshoot a problem
TOPIC
What information should I provide to support if I need help? Information to include when you need help
How can I fix a problem with password reset Troubleshoot the password reset portal
How can I fix a problem with password writeback Troubleshoot password writeback
How can I fix a problem with password writeback connectivity Troubleshoot password writeback connectivity
How can I fix a problem with password reset configuration Troubleshoot password reset configuration in the azure
management portal
How can I fix a problem with password reset reports Troubleshoot password management reports in the azure
management portal
How can I fix a problem with password reset registration Troubleshoot the password reset registration portal
Password writeback event log error codes Password writeback event log error codes
Read a FAQ
TOPIC
I want to read a FAQ about password reset registration Password reset registration FAQ
I want to read a FAQ about password reset Password reset FAQ
I want to read a FAQ about password reset reports Password management reports FAQ
I want to read a FAQ about password writeback Password writeback FAQ
Understand the technical details

TOPIC
I want to learn about what password writeback is Password writeback overview
I want to learn about how password writeback works How does password writeback work?
I want to learn about what scenarios are supported by Scenarios supported for password writeback
password writeback
I want to learn about how password writeback is secured Password writeback security model
I want to learn about how the password reset portal works How does the password reset portal work?
I want to learn about what data is used by password reset What data is used by password reset?
Recent service updates
Enforce Password Reset Registration at Sign-In to Office 365 Apps - November 2015
Now, after enabling the enforced registration feature, your users will be required to register from anywhere
they sign in with a work or school account. This dramatically increases the speed at which many organizations
can onboard to password reset. With this new feature we've seen large organizations onboarding in as little as
2 weeks!
Support for Unlocking Active Directory Accounts without Resetting a Password - November 2015
Unlock only (without reset) is a huge helpdesk driver these days. In fact, many organizations spend up to 70%
of their password reset budget unlocking accounts! To meet this demand, now with Azure AD Password reset,
you can enable a feature to let your users unlock AD accounts separately from password reset. Check out how
to turn it on here: Setting: enable users to unlock their AD accounts without resetting a password.
Usability updates to Registration Page - October 2015
Now, when a user has data already registered, he or she can just click "looks good" to update the data without
needing to re-send the email or phone call.
Improved Reliability of Password Writeback - September 2015
As of the September release of Azure AD Connect, the password writeback agent will now more aggressively
retry connections and additional, more robust, failover capabilities.
API for Retrieving Password Reset Reporting Data - August 2015
Now, the data behind the password reset reports can be retrieved directly from the Azure AD Reports and
Events API.
Support for Azure AD Password Reset During Cloud Domain Join - August 2015
Now, any cloud user can reset his or her password right from the Windows 10 sign in screen during the cloud
domain join onboarding experience. Note, this is not yet exposed on the Windows 10 sign in screen.
Enforce Password Reset Registration at Sign-In to Azure and Federated Apps - July 2015
In addition to enforcing registration when signing into myapps.microsoft.com, we now support enforcing
registration during sign ins to the Azure Management Portal and any of your federated single-sign on
applications
Security Question Localization Support - May 2015
Now, you have the option to select pre-defined security questions which are localized in the full O365 language
set when configuring Security Questions for password reset.
Account Unlock Support during Password Reset - June 2015
If you're using password writeback and you reset your password when your account is locked, we'll
automatically unlock your Active Directory account!
Branded SSPR Registration - April 2015
The password reset registration page is now branded with your company logo!
Security Questions - March 2015
We released security questions to GA!
Account Unlock - March 2015
Now users can unlock their accounts when password reset occurs
Coming soon
Below are some of the cool features we're working on right now!
Support for Reminding Users to Update their Registered Data During Sign-in - Work in progress
Today, we support reminding users to update their registered data when accessing myapps.microsoft.com, but
we're working on the ability to do so for all sign ins.

own password.
Customizing Password Management to fit your
organization's needs
IMPORTANT
password.
In order to give your users the best possible experience, we recommend that you explore and play with all of the
Password Management configuration options available to you. In fact, you can start exploring this right away by
going to the configuration tab of the Active Directory extension in the Azure classic portal. This topic walks
you through all of the different Password Management customizations you can make as an administrator from
within Configure tab of your directory within the Azure classic portal, including:
TOPIC
How do I enable or disable password reset? Setting: users enabled for password reset
How do I scope password reset to a specific set of users? Restrict password reset to specific users
How do I change what authentication methods are Setting: authentication methods available to users
supported?
How do I change number of authentication methods Setting: number of authentication methods required
required?
How do I set up custom security questions? Setting: custom security questions
How do I set up pre-canned localized security questions? Setting: knowledge-based security questions
How can I change how many security questions are Setting: number of security questions for registration or reset
required?
How can I force my users to register when signing in? Enforced registration-based rollout of password reset
How can I force my users to re-confirm their registered Setting: number of days before users must re-confirm their
periodically? authentication data
How can I customize how a user gets in touch with an Setting: customize the "contact your administrator" link
admin?
How can I allow users to unlock AD accounts without Setting: enable users to unlock their AD accounts without
resetting a password? resetting a password
How can I enable password reset notifications for users? Setting: notify users when their passwords have been reset
How can I enable password reset notifications for admins? Setting: notify other admins when an admin reset their own
password
TOPIC
How can I customize password reset look and feel? Setting: company name, branding, and logo
Password management look and feel

The following table describes how each control affects the experience for users registering for password reset
and resetting their passwords. You can configure these options under the Directory Properties section of your
directorys Configure tab within the Azure Management Portal.
Policy Control Description Affects?
Directory Name Determines what organizational "Contact your administrator"

name users or admins see on emails:
password reset email
communications Determines the from address
friendly name, e.g. Microsoft
on behalf of Wingtip Toys
Determines the subject name of

the email, e.g. Wingtip Toys
account email verification code
Password reset emails:

Determines the from address
friendly name, e.g. Microsoft
on behalf of Wingtip Toys
Sign in and access panel page Determines if users visiting the Password reset portal:
appearance password reset page see the
Microsoft logo or your own Determines whether or not
custom logo. This configuration your logo is shown at the top
item also adds your branding to of the password reset portal
the access panel and sign in page. instead of the default Microsoft
logo.
You can learn more about the
tenant branding and customization Note: you may not see your
feature at Add company branding logo on the first page of the
to your Sign In and Access Panel password reset portal if you
pages. come to the password reset
page directly. Once a user
enters his or her userID and
clicks next, your logo will
appear. You can force your logo
to appear on page load by
passing the whr parameter to
the password reset page, like
this:
https://passwordreset.microsoft
online.com?
whr=wingtiptoysonline.com
Contact your administrator

emails:
Determines whether or not
your logo is shown at the
bottom of the emails sent to
admins when users choose to
contact you by clicking the
contact your administrator
link on the password reset UI.
Password reset emails:

Determines whether or not
your logo is shown at the
bottom of the emails sent to
users when they reset their
passwords.
Password Management behavior

The following table describes how each control affects the experience for users registering for password reset
and resetting their passwords. You can configure these options under the User Password Reset Policy section
of your directorys Configure tab in the Azure Management Portal.
NOTE
The administrator account you are using must have an AAD Premium license assigned in order to see these policy
controls.
These policy controls only apply to end users resetting their passwords, not administrators. Administrators have a
default policy of alternate email and/or mobile phone that is specified for them by Microsoft which cannot be
changed.
Users enabled for password reset Determines if password reset is Registration portal:
enabled for users in this directory.
If set to no, no users can
register their own challenge
data.
If set to yes, any end user in

the directory can register
challenge data by going to the
registration portal at
Note: users must have an

Azure AD Premium or Basic
license assigned before they
can register for password reset.
Password reset portal:

If set to no, users see a
message saying the must
contact their admin to reset
their password.
If set to yes, users are able to

reset their passwords
automatically by going to
http://passwordreset.microsofto
nline.com, or clicking on the
cant access your account link
on any Organizational ID sign-
in page.
Note: users must have an

Azure AD Premium or Basic
license assigned before they
can reset their passwords.
Restrict access to password reset Determines whether only a Registration portal:
particular group of users is allowed
to use password reset. (Only visible This setting does not affect
if users enabled for password users' access to the password
reset is set to yes). reset registration portal. If
Users enabled for password
reset is set to yes, all end users
in your directory can register
for password reset at
If set to no, then all end users
in your directory can reset their
passwords.
If set to yes, then only end

users specified in the group
that can perform password
reset control can reset their
passwords.
Group that can perform password Determines what group of end Note:
reset users is allowed to use password
reset. If no group is specified and you
click Save, an empty group
(Only visible if restrict access to called
password reset is set to yes). SSPRSecurityGroupUsers will
be created for you.
If youd like to specify your own

group, you can provide your
own display name.
Registration portal:
This setting does not affect
users' access to the password
reset registration portal. If
Users enabled for password
reset is set to yes, all end users
in your directory can register
for password reset at
If restrict access to password
reset is set to yes, then only
end users in this group will be
able to reset their passwords.
Authentication methods available Determines which challenges a Note:

to users user is allowed to use to reset his
or her password. At least one option must be
selected.
(Only visible if users enabled for
password reset is set to yes). We highly recommend enabling
at least 2 options to give your
users the most flexibility when
resetting their passwords.
If you are using security

questions, we highly
recommend you use them in
conjunction with another
authentication method, as
security questions can be less
secure than phone or email-
based password reset methods.
Which directory fields are used?

Office Phone corresponds to
the Office Phone attribute on
a user object in the directory.
Mobile Phone corresponds to

either the Authentication
Mobile attribute (which is not
publically visible) or the Mobile
Phone attribute (which is
publically visible) on a user
object in the directory. The
service first checks
Authentication Phone for
data, and if there is none
present, falls back to the
Mobile Phone attribute.
Alternate Email Address

corresponds to either the
Authentication Email attribute
(which is not publically visible)
or the Alternate Email
attribute on a user object in the
directory. The service first
checks Authentication Email
for data, and if there is none
present, falls back to the
Alternate Email attribute.
Security Questions are stored

privately and securely on a user
object in the directory and can
only be answered by users
during registration. For security
purposes, there is currently no
way for an administrator to edit
or see these answers.
Note: by default, only the

cloud attributes Office Phone
and Mobile Phone are
synchronized to your cloud
directory from your on-
premises directory. To learn
more about which on-premises
attributes are synced to the
cloud, see Attributes
synchronized to Azure AD.
Affects which authentication
methods are displayed when
users are registering. If you do
not enable a given
authentication method, users
will not be able to self-register
for that authentication method.
Note: users are currently not

able to register their own office
phone numbers; that
authentication method must be
defined by their administrator.

Determines which
authentication methods a user
can use as challenges for a
given verification step. For
example, if a user has data in
both the Office Phone and
Authentication Phone fields in
Azure Active Directory, then he
or she can use either of these
authentication methods to
recover his or her password.
Note: users will be able to reset

their password if and only if
they have data present in the
authentication methods you
have enabled as an
administrator.
Number of authentication Determines the minimum number Note:
methods required of the available authentication
methods a user must go through Can be set to 1 or 2
to reset his or her password. authentication methods
required.
password reset is set to yes).
Determines the minimum
number of authentication
methods a user must register
before being able to finish the
registration experience.

Affects number of verification
steps a user must go through
before being able to reset a
password. A verification step is
defined to be a user using one
piece of authentication
information (such as a call to
their office phone, or an email
to their alternate email) to
verify their account.
Note: If a user does not have

the required amount of
authentication information
defined on his or her account in
order to be successful resetting
his or her password in
accordance with the policy
youve set, he or she will see an
error page which will direct
them to request an
administrator to reset his or her
password.
Number of questions required to Determines the minimum number Note:
register of questions a user must answer
when registering for the security Can be set to 3 5 questions
questions option. required to register.
(Only visible if the Security Number of questions required

Questions checkbox is enabled). to register must be greater
than or equal to the number of
questions required to reset.
We recommend you set the

number of questions required
to register to be higher than
the number required to reset
so users have more flexibility
when resetting their passwords.
This is also a more secure
configuration because we will
randomly select questions for
the user to answer from the
pool of all of the questions they
have registered.
number of questions a user
must answer before the user is
considered fully registered for
password reset.
Number of questions required to Determines the minimum number Note:
reset of questions a user must answer
when resetting a password. Can be set to 3 5 questions
required to reset.
(Only visible if the Security
Questions checkbox is enabled). Number of questions required
to reset must be less than or
equal to the number of
questions required to register.

number of questions a user
must answer before the users
password can be reset.
At the time of password reset,

this number of questions will be
selected at random from the
users total list of registered
questions. For example, if the
user has 5 questions registered,
3 of those 5 questions will be
selected at random when the
user comes to reset a
password. The user must then
answer all of these questions
correctly before the password
can be reset.
Knowledge based security Defines the pre-canned security Note:
questions questions your users may choose
from when registering for All knowledge-based questions
password reset and when resetting will be localized into the full set
their passwords. of O365 languages based off of
the user's browser locale.
(Only visible if the Security
Questions checkbox is enabled). Up to 20 total questions can be
defined (the sum of your
custom and knowledge-based
questions).
Min answer character limit is 3

characters.
Max answer character limit is

40 characters.
Users may not answer the

same question twice.
Users may not provide the

same answer to two different
questions twice.
Any character set may be used

to define answers (including
Unicode characters).
The number of questions

defined must be greater than
or equal to the number of
Determines which questions a
user is able to provide answers
for when registering for
password reset.

user is able to use to reset a
password.
Custom Security questions Defines the security questions your Note:
users may choose from when
registering for password reset and Up to 20 total questions can be
when resetting their passwords. defined (the sum of your
custom and knowledge-based
(Only visible if the Security questions).
Questions checkbox is enabled).
Max question character limit is
200 characters.
Min answer character limit is 3

characters.
Max answer character limit is

40 characters.
Users may not answer the

same question twice.
Users may not provide the

same answer to two different
questions twice.
Any character set may be used

to define questions and
answers (including Unicode
characters).
The number of questions

defined must be greater than
or equal to the number of
Defining different questions for

different locales is not
supported for custom
questions. All custom questions
will be displayed in the
language in which you enter
them in the administrative UI,
even if the user's browser locale
is different. If you need these
questions to be localized, please
use the "knowledge based"
questions instead.
user is able to provide answers
for when registering for
password reset.

user is able to use to reset a
password.
Require users to register when Determines if a user is required to Note:
signing in? register contact data for password
reset the next time he or she signs If you disable this feature, you
in. can also manually send users to
http://aka.ms/ssprsetup to
This capability works on any sign- register their contact data.
in page that uses a work or school
account. Such pages include all of
Users can also reach the
Office 365, the Azure Management
registration portal by clicking
Portal, the Access Panel, and any
the register for password
federated or custom-developed
reset link under the profile tab
applications that use Azure AD to
in the access panel.
sign in.
Enforced registration will only Registration via this method
apply to users who are enabled for can be dismissed by clicking the
password reset, so if you have cancel button or closing the
used the "restrict access to window, but users will be
password reset" feature and nagged every time they sign in
scoped password reset to a specific if they do not register.
group of users, then only users in
that group will be required to
register for password reset when Registration portal:
signing in. This setting does not affect the
(Only visible if users enabled for behavior of the registration
password reset is set to yes). portal itself, rather, it
determines whether or not the
registration portal is shown to
users when they sign in to the
access panel.
Number of days before users must When require users to register is Note:
confirm their contact data turned on, this setting determines
the period of time which can Values between 0-730 days are
elapse before a user must re- accepted, with 0 days meaning
confirm their data. that users will never be asked
to re-confirm their contact
(Only visible if require users to data.
register when signing in to the
access panel is set to yes).
This setting does not affect the
behavior of the registration
portal itself, rather, it
determines whether or not the
registration portal is shown to
users when their contact data
needs to be reconfirmed.
Customize the contact your Controls whether or not the Note:
administrator link? contact your administrator link
(shown to the left) that appears on If you enable this setting, you
the password reset portal when an must choose a custom URL or
error occurs or a user waits too email address by filling out the
long on an operation points to a custom email address or url
custom URL or email address. field immediately below this
setting.
password reset is set to yes).
If set to no, users clicking the
highlighted link will dispatch an
email to the primary email
address of all tenant
administrators requesting that
his or her password be reset.
This email is dispatched by
following the logic below:
If there are password

administrators, send the
email to all password
administrators, up to a
maximum of 100 total
recipients.
If there are no password

email to all user
recipients.
If there are no user

email to all global
recipients.
If set to yes, this setting will

customize the behavior of the
highlighted link above to point
to a custom URL or email
address to which your users
can navigate to get help with
password reset.
If you specify a URL, it will be

opened in a new tab.
If you specify an email address,

well create a mailto link to that
email address.
Custom email address or URL Controls the email address or URL Note:
to which the contact your
administrator link points. Must be a valid intranet or
extranet URL or email address.
(Only visible if customize contact
your administrator link is set to
yes). Password reset portal:
Changes where the contact
your administrator link
points.
If you provide an email address,

the link will become a mailto
link to that email address.
If you provide a URL, the link

will become a standard href
pointing to that URL which will
open in a new tab.
Write back passwords to on- Controls whether or not Password Note:

premises directory Writeback is enabled for this
directory and, if writeback is on, This control only appears if you
indicates the status of the on- have installed Password
premises writeback service. Writeback by downloading the
latest version of Azure AD
This is setting is useful if you want Connect and enabling the
to temporarily disable the service Password Writeback option
without re-configuring Azure AD under the optional features
Connect. selection screen.
If you have enabled Password

Writeback and feel there is a
configuration issue with the
service, you can come to this
tab and look at the password
write back service status label
to see if something is wrong.
Statuses that can be shown are:
Configured
everything is working as
expected
Not configured you

have writeback installed,
but we cant reach the
service, check to make
sure you are not
blocking outbound
connections to 443 and
try re-installing the
service if you still have
problems.
If writeback is deployed and
configured and this switch is set
to no, then writeback will be
disabled, and federated and
password hash syncd users will
not be able to register for
password reset their passwords.
If the switch is set to yes, then

writeback will be enabled, and
federated and password hash
syncd users will be able to
reset their passwords.

If writeback is deployed and
configured and this switch is set
to no, then writeback will be
disabled, and federated and
password hash syncd users will
not be able to reset their
passwords.
If the switch is set to yes, then

writeback will be enabled, and
federated and password hash
syncd users will be able to
reset their passwords.
Allow users to unlock accounts Designates whether or not users Note:
without resetting their password who visit the password reset portal
should be given the option to In order to use this feature, you
unlock their on-premises Active must install the August 2015 or
Directory accounts without later release of Azure AD
resetting their password. By Connect (v. 1.0.8667.0 or
default, Azure AD will always greater).
unlock accounts when performing
a password reset, this setting Click here to download the
allows you to separate those two latest version of Azure AD
operations. Connect.
Note: In order to test this
If set to yes, then users will be feature, you will need enable
given the option to reset their password writeback, and use an
password and unlock the account, account that is sourced from
or to unlock without resetting the on-premises (like a federated or
password. password synchronized user)
and has a locked account. Users
If set to no, then users will only
who do not come from on
be able to perform a combined
premises and do not have a
password reset and account unlock
locked account will not see the
operation.
option to unlock their accounts.
After enabling this option,
when a user with an on-
premises account that is locked
arrives at the password reset
portal, he or she will be given
the option to unlock their
account without resetting their
password.
Note that if you are using

password writeback, accounts
are already automatically
unlocked when the password is
reset, and that this option
simply decouples those
operations.
This is an especially useful

option to enable if you find that
many of your helpdesk calls are
generated by account unlock
requests.
Password Management notifications

The following table describes how each control affects the experience for users and admins who receive
password reset notifications. You can configure these options under the Notifications section of your
directorys Configure tab in the Azure Management Portal.

Notify admins when other admins Determines whether or not all Password reset portal:
reset their own passwords global admins will be notified via
an email to their primary email If set to no, then no
address when another admin of notifications will be sent.
any type resets his or her own
password. If set to yes, then all other
global administrators will be
notified when any single admin
resets his or her own password.
This notification is sent via an

email to the primary email
addresses of all other global
admins in the organization.
Example:
If this option was enabled when
admin A resets his password,
and there are 3 other admins in
the tenant, B, C, and D, then
admins B, C, and D would
receive an email indicating
admin A reset his password.
Notify users and admins when Determines whether or not end Password reset portal:
their own password has been reset users or admins who reset their
own passwords will receive an If set to no, then no
email notification that their notifications will be sent.
password has been reset.
If set to yes, then whenever a
user or admin resets his own
password, he or she will receive
a notification indicating his or
her password has been reset.
This notification is sent via an

email to the users User
Principal Name, and alternate
(or authentication) email
address of the user who reset
his or her password.

your own password.
How to get operational insights with Password
Management reports
IMPORTANT
password.
This section describes how you can use Azure Active Directorys Password Management reports to view how
users are using password reset and change in your organization.
Password Management reports overview
How to view Password Management reports
View password reset registration activity in your organization
View password reset activity in your organization
Overview of Password Management reports

Once you deploy password reset, one of the most common next steps is to see how it is being used in your
organization. For example, you may want to get insight into how users are registering for password reset, or
how many password resets have been done in the last few days. Here are some of the common questions that
you will be able to answer with the Password Management reports that exist in the Azure Management Portal
today:
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 7 days?
What are the most common methods users or admins use to reset their passwords?
What are common issues 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?
How to view Password Management reports

To find the Password Management reports, follow the steps below:
1. Click on the Active Directory extension in the Azure Management Portal.
2. Select your directory from the list that appears in the portal.
3. Click on the Reports tab.
4. Look under the Activity Logs section.
5. Select either the Password reset activity report or the Password reset registration activity report.
How to access Password Management Reports from an API
As of August 2015, the Azure AD Reports and Events now supports retrieving all of the information included in
the Password Reset and Password Reset Registration reports.
To access this data, you'll need to write a small app or script to retrieve it from our servers. Learn how to get
started with the Azure AD Reporting API.
Once you have a working script, you'll next 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
View password Reset registration activity

The password reset registration activity report shows all password reset registrations that have occurred in your
organization. A password reset registration is displayed in this report for any user who has successfully
registered authentication information at the password reset registration portal (http://aka.ms/ssprsetup).
Max time range: 1 month
Max number of rows: unlimited
Downloadable: Yes, via CSV file
Description of report columns
The following list explains each of the report columns 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 what authentication data the user provided during password reset registration.
Description of report values
The following table describes the different values allowed for each column:
COLUMN ALLOWED VALUES AND THEIR MEANINGS
Data Registered Alternate Email user used alternate email or

authentication email to authenticate
Office Phone user used office phone to authenticate
Mobile Phone - user used mobile phone or
authentication phone to authenticate
Security Questions user used security questions to
authenticate
Any combination of the above (e.g. Alternate Email
+ Mobile Phone) occurs when a 2 gate policy is
specified and shows which two methods the user used
to authentication his password reset request.
View password reset activity

This report shows all password reset attempts that have occurred in your organization.
Max time range: 1 month
Max number of rows: unlimited
Downloadable: Yes, via CSV file
Description of report columns
The following list explains each of the report columns in detail:
1. User the user who attempted a password reset operation (based on the User ID field provided when the
user comes to reset a password).
2. Role the role of the user in the directory.
3. Date and Time the date and time of the attempt.
4. Method(s) Used what authentication methods the user used for this reset operation.
5. Result the end result of the password reset operation.
6. Details the details of why the password reset resulted in the value it did. Also includes any mitigation steps
you might take to resolve an unexpected error.
Description of report values
The following table describes the different values allowed for each column:
Methods Used Alternate Email user used alternate email or

authentication email to authenticate
Office Phone user used office phone to authenticate
Mobile Phone user used mobile phone or
authentication phone to authenticate
Security Questions user used security questions to
authenticate
Any combination of the above (e.g. Alternate Email
+ Mobile Phone) occurs when a 2 gate policy is
specified and shows which two methods the user used
to authentication his password reset request.
Result Abandoned user started password reset but then stopped

halfway through without completing
Blocked users account was prevented to use
password reset due to attempting to use the password
reset page or a single password reset gate too many
times in a 24 hour period
Cancelled user started password reset but then
clicked the cancel button to cancel the session part way
through
Contacted Admin user had a problem during his
session that he could not resolve, so the user clicked the
Contact your administrator link instead of finishing the
password reset flow
Failed user was not able to reset a password, likely
because the user was not configured to use the feature
(e.g. no license, missing authentication info, password
managed on-prem but writeback is off).
Succeeded password reset was successful.
Details See table below
Allowed values for details column

Below is the list of result types you may expect when using the password reset activity report:
DETAILS RESULT TYPE
User abandoned after completing the email verification Abandoned

option
User abandoned after completing the mobile SMS Abandoned

verification option
User abandoned after completing the mobile voice call Abandoned

verification option
User abandoned after completing the office voice call Abandoned

verification option
User abandoned after completing the security questions Abandoned

option
User abandoned after entering their user ID Abandoned
User abandoned after starting the email verification option Abandoned
User abandoned after starting the mobile SMS verification Abandoned

option
User abandoned after starting the mobile voice call Abandoned

verification option
DETAILS RESULT TYPE
User abandoned after starting the office voice call verification Abandoned
option
User abandoned after starting the security questions option Abandoned
User abandoned before selecting a new password Abandoned
User abandoned while selecting a new password Abandoned
User entered too many invalid SMS verification codes and is Blocked
blocked for 24 hours
User tried mobile phone voice verification too many times Blocked
and is blocked for 24 hours
User tried office phone voice verification too many times and Blocked
is blocked for 24 hours
User tried to answer security questions too many times and Blocked
is blocked for 24 hours
User tried to verify a phone number too many times and is Blocked
blocked for 24 hours
User cancelled before passing the required authentication Cancelled

methods
User cancelled before submitting a new password Cancelled
User contacted an admin after trying the email verification Contacted admin
option
User contacted an admin after trying the mobile SMS Contacted admin
verification option
User contacted an admin after trying the mobile voice call Contacted admin
verification option
User contacted an admin after trying the office voice call Contacted admin
verification option
User contacted an admin after trying the security question Contacted admin
verification option
Password reset is not enabled for this user. Enable password Failed
reset under the configure tab to resolve this
User does not have a license. You can add a license to the Failed
user to resolve this
User tried to reset from a device without cookies enabled Failed

DETAILS RESULT TYPE
User's account has insufficient authentication methods Failed

defined. Add authentication info to resolve this
User's password is managed on-premises. You can enable Failed

Password Writeback to resolve this
We could not reach your on-premises password reset Failed

service. Check your sync machine's event log
We encountered a problem while resetting the user's on- Failed

premises password. Check your sync machine's event log
This user is not a member of the password reset users Failed

group. Add this user to that group to resolve this.
Password reset has been disabled entirely for this tenant. See Failed
here to resolve this.
User successfully reset password Succeeded

your own password.
Learn more about Password Management
IMPORTANT
password.
If you have already deployed Password Management, or are just looking to learn more about the technical nitty
gritty of how it works before deploying, this section will give you a good overview of the technical concepts
behind the service. We'll cover the following:
Password writeback overview
How pasword writeback works
Scenarios supported for password writeback
Password writeback security model
Password writeback bandwidth usage
How does the password reset portal work?
What data is used by password reset?
How to access password reset data for your users
Password writeback overview

Password writeback is an Azure Active Directory Connect component that can be enabled and used by the
current subscribers of Azure Active Directory Premium. For more information, see Azure Active Directory
Editions.
Password writeback allows you to configure your cloud tenant to write passwords back to you on-premises
Active Directory. It obviates you from having to set up and manage a complicated on-premises self-service
password reset solution, and it provides a convenient cloud-based way for your users to reset their on-premises
passwords wherever they are. Read on for some of the key features of password writeback:
Zero delay feedback. Password writeback is a synchronous operation. Your users will be notified
immediately if their password did not meet policy or was not able to be reset or changed for any reason.
Supports resetting passwords for users using AD FS or other federation technologies. With password
writeback, as long as the federated user accounts are synchronized into your Azure AD tenant, they will be
able to manage their on-premises AD passwords from the cloud.
Supports resetting passwords for users using password hash sync. When the password reset service
detects that a synchronized user account is enabled for password hash sync, we reset both this accounts on-
premises and cloud password simultaneously.
Supports changing passwords from the access panel and Office 365. When federated or password
syncd users come to change their expired or non-expired passwords, well write those passwords back to
your local AD environment.
Supports writing back passwords when an admin reset them from the Azure Management Portal.
Whenever an admin resets a users password in the Azure Management Portal, if that user is federated or
password syncd, well set the password the admin selects on your local AD, as well. This is currently not
supported in the Office Admin Portal.
Enforces your on-premises AD password policies. When a user resets his/her password, we make sure
that it meets your on-premises AD policy before committing it to that directory. This includes history,
complexity, age, password filters, and any other password restrictions you have defined in your local AD.
Doesnt require any inbound firewall rules. Password writeback uses an Azure Service Bus relay as an
underlying communication channel, meaning that you do not 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 your on-premises Active
Directory. For more information about protected groups, see Protected Accounts and Groups in Active
Directory.
How password writeback works
Password writeback has three main components:
Password Reset cloud service (this is also integrated into Azure ADs password change pages)
Tenant-specific Azure Service Bus relay
On-prem password reset endpoint
They fit together as described in the below diagram:
When a federated or password hash syncd user comes to reset or change his or her password in the cloud, the
following occurs:
1. We check to see what type of password the user has. If we see the password is managed on premises, then we
ensure the writeback service is up and running. If it is, we let the user proceed, if it is not, we tell the user that
their password cannot be reset here.
2. Next, the user passes the appropriate authentication gates and reaches the reset password screen.
3. The user selects a new password and confirms it.
4. Upon clicking 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. Once the message reaches 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 in question by using the cloud anchor attribute. For this lookup to succeed,
the user object must exist in the AD connector space, it must be linked to the corresponding MV object, and it
must be linked to the corresponding AAD connector object. Finally, in order for sync to find this user account,
the link from AD connector object to MV must have the sync rule Microsoft.InfromADUserAccountEnabled.xxx
on the link. This is needed because when the call comes in from the cloud, the sync engine uses the
cloudAnchor attribute to look up the AAD connector space object, then follows the link back to the MV object,
and then follows the link back to the AD object. Because there could be multiple AD objects (multi-forest) for
the same user, the sync engine relies on the Microsoft.InfromADUserAccountEnabled.xxx link to pick the correct
one.
8. Once the user account is found, we attempt to reset the password directly in the appropriate AD forest.
9. If the password set operation is successful, we tell the user their password has been modified and that they
can go on their merry way.
10. If the password set operation fails, we return the error to the user and let them try again. The operation might
fail because the service was down, because the password they selected did not meet organization policies,
because we could not find the user in the local AD, or any number of reasons. We have a specific message for
many of these cases and tell the user what they can do to resolve the issue.
Scenarios supported for password writeback
The table below describes which scenarios are supported for which versions of our sync capabilities. In general, it
is highly recommended that you install the latest version of Azure AD Connect if you want to use password
writeback.
Password writeback security model

Password writeback is a highly secure and robust service. In order to ensure your information is protected, we
enable a 4-tiered security model that is described below.
Tenant specific service-bus relay When you set up the service, we set up a tenant-specific service bus
relay that is 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 which we use to encrypt the password as it comes over the wire.
This key lives only in your company's secret store in the cloud, which is heavily locked down and audited, just
like any password in the directory.
Industry standard TLS When a password reset or change operation occurs in the cloud, we take the
plaintext password and encrypt it with your public key. We then plop that into an HTTPS message which is
sent over an encrypted channel using Microsofts SSL certs to your service bus relay. After that message
arrives into Service Bus, your on-prem agent wakes up, authenticates to Service Bus using the strong
password that had been previously generated, picks up the encrypted message, decrypts it using the private
key we generated, and then attempts to set the password through the AD DS SetPassword API. This step is
what allows us to enforce your AD on-prem password policy (complexity, age, history, filters, etc) in the cloud.
Message expiration policies Finally, if for some reason the message sits in Service Bus because your on-
prem service is down, it will be timed out and removed after several minutes in order to increase security
even further.
Password writeback bandwidth usage
Password writeback is an extremely low bandwidth service that sends requests back to the on-premises agent
only under the following circumstances:
1. Two messages sent when enabling or disabling the feature through Azure AD Connect.
2. One message is sent once every 5 minutes as a service heartbeat for as long as the service is running.
3. Two messages are sent each time a new password is submitted, one message as a request to perform the
operation, and a subsequent message which contains the result of the operation. These messages are sent in
the following cirumstances.
4. Each time a new password is submitted during a user self-service password reset.
5. Each time a new password is submitted during a user password change operation.
6. Each time a new password is submitted during an admin-initiated user password reset (from the Azure admin
portals only)
Message size and bandwidth considerations
The size of each of the message described above is typically under 1kb, which means, even under extreme loads,
the password writeback service itself will be consuming at most a few kilobits per second of bandwidth. Since
each message is sent in real time, only when required by a password update operation, and since the message
size is so small, the bandwidth usage of the writeback capability is effectively too small to have any real
measurable impact.
How does the password reset portal work?

When a user navigates to the password reset portal, a workflow is kicked off to determine if that user account is
valid, what organization that users belongs to, where that users password is managed, and whether or not the
user is licensed to use the feature. Read through the steps below to learn about the logic behind the password
reset page.
1. User clicks on the Cant access your account link or goes directly to
https://passwordreset.microsoftonline.com.
2. User enters a user id and passes a captcha.
3. Azure AD verifies if the user is able to use this feature by doing the following:
Checks that the user has this feature enabled and an Azure AD license assigned.
If the user does not have this feature enabled or a license assigned, the user is asked to contact
his or her administrator to reset his or her password.
Checks that the user has the right challenge data defined on his or her account in accordance with
administrator policy.
If policy requires only one challenge, then it is ensured that the user has the appropriate data
defined for at least one of the challenges enabled by the administrator policy.
If the user is not configured, then the user is advised to contact his or her administrator to
reset his or her password.
If the policy requires two challenges, then it is ensured that the user has the appropriate data
defined for at least two of the challenges enabled by the administrator policy.
If the user is not configured, then we the user is advised to contact his or her
administrator to reset his or her password.
Checks whether or not the users password is managed on premises (federated or password hash
syncd).
If writeback is deployed and the users password is managed on premises, then the user is
allowed to proceed to authenticate and reset his or her password.
If writeback is not deployed and the users password is managed on premises, then the user is
asked to contact his or her administrator to reset his or her password.
4. If it is determined that the user is able to successfully reset his or her password, then the user is guided
through the reset process.
Learn more about how to deploy password writeback at Getting Started: Azure AD Password Management.
What data is used by password reset?
The following table outlines where and how this data is used during password reset and is designed to help you
decide which authentication options are appropriate for your organization. This table also shows any formatting
requirements for cases where you are providing data on behalf of users from input paths that do not validate this
data.
NOTE
Office Phone does not appear in the registration portal because users are currently not able to edit this property in the
directory.
Contact Method Azure Active Used / Settable Format requirements

Name Directory Data Where?
Element
Office Phone PhoneNumber Used in: +ccc xxxyyyzzzz (e.g. +1

1234567890)
e.g. Set-MsolUser - Password Reset Portal
UserPrincipalName Must provide a
JWarner@contoso.com Settable from: country code
-PhoneNumber "+1 PhoneNumber is
1234567890x1234" settable from
Must provide an
PowerShell, DirSync,
area code (where
Azure Management
applicable)
Portal, and the Office
Admin Portal
Must have provide a
+ in front of the
country code
Must have a space

between country
code and the rest of
the number
Extensions are not

supported, if you
have any extensions
specified, we will
strip it from the
number before
dispatching the
phone call.
Mobile Phone AuthenticationPhone Used in: +ccc xxxyyyzzzz (e.g. +1
1234567890)
OR Password Reset Portal
Must provide a
MobilePhone Registration Portal country code.
(Authentication Phone Settable from:
is used if there is data
AuthenticationPhone is Must provide an
present, otherwise this
settable from the area code (where
falls back to the mobile
password reset applicable).
phone field).
registration portal or
e.g. Set-MsolUser - MFA registration portal.
UserPrincipalName Must have provide a
JWarner@contoso.com MobilePhone is settable + in front of the
-MobilePhone "+1 from PowerShell, country code.
1234567890x1234" DirSync, Azure
Management Portal,
and the Office Admin Must have a space
Portal between country
code and the rest of
the number.
Extensions are not

supported, if you
have any extensions
specified, we ignore
it when dispatching
the phone call.
Alternate Email AuthenticationEmail Used in: user@domain.com or

@.
OR Password Reset Portal
Emails should follow
AlternateEmailAddresse Registration Portal standard formatting
s[0] as per .
Settable from:
(Authentication Email is
used if there is data AuthenticationEmail is
settable from the Unicode emails are
present, otherwise this
password reset supported.
falls back to the
Alternate Email field). registration portal or
MFA registration portal.
Note: the alternate
email field is specified as AlternateEmail is
an array of strings in settable from
the directory. We use PowerShell, the Azure
the first entry in this Management Portal,
array. and the Office Admin
Portal
e.g. Set-MsolUser -
UserPrincipalName
JWarner@contoso.com
-
AlternateEmailAddresse
s "email@live.com"
Security Questions and Not available to modify Used in: Security questions have
Answers directly in the directory. a max of 200 characters
Password Reset Portal and a min of 3
Registration Portal characters
Settable from: Answers have a max of
40 characters and a min
The only way to set of 3 characters
security questions is
through the Azure
Management Portal.
The only way to set
answers to security
questions for a given
user is through the
Registration Portal.
How to access password reset data for your users

Data settable via synchronization
The following fields can be synchronized from on-premises:
Mobile Phone
Office Phone
Data accessible with Azure AD PowerShell
The following fields are accessible with Azure AD PowerShell & the Graph API:
Alternate Email
Mobile Phone
Office Phone
Authentication Phone
Authentication Email
Data settable with registration UI only
The following fields are only accessible via the SSPR registration UI (https://aka.ms/ssprsetup):
Security Questions and Answers
What happens when a user registers?
When a user registers, the registration page will always set the following fields:
Security Questions and Answers
If you have provided a value for Mobile Phone or Alternate Email, users can immediately use those to reset
their passwords, even if they haven't registered for the service. In addition, users will see those values when
registering for the first time, and modify them if they wish. However, after they successfully register, these values
will be persisted in the Authentication Phone and Authentication Email fields, respectively.
This can be a useful way to unblock large numbers of users to use SSPR while still allowing users to validate this
information through the registration process.
Setting password reset data with PowerShell
You can set values for the following fields with Azure AD PowerShell.
Alternate Email
Mobile Phone
Office Phone
To get started, you'll first need to download and install the Azure AD PowerShell module. Once you have it
installed, you can follow the steps below to configure each field.
A l t e r n a t e Em a i l
Connect-MsolService
Set-MsolUser -UserPrincipalName user@domain.com -AlternateEmailAddresses @("email@domain.com")
Mobile Phone
Connect-MsolService
Set-MsolUser -UserPrincipalName user@domain.com -MobilePhone "+1 1234567890"
O ffi c e P h o n e
Connect-MsolService
Set-MsolUser -UserPrincipalName user@domain.com -PhoneNumber "+1 1234567890"
Reading password reset data with PowerShell

You can read values for the following fields with Azure AD PowerShell.
Alternate Email
Mobile Phone
Office Phone
To get started, you'll first need to download and install the Azure AD PowerShell module. Once you have it
installed, you can follow the steps below to configure each field.
A l t e r n a t e Em a i l
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select AlternateEmailAddresses
Mobile Phone
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select MobilePhone
O ffi c e P h o n e
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select PhoneNumber
A u t h en t i c at i o n Ph o n e
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
PhoneNumber
A u t h e n t i c a t i o n Em a i l
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
Email

your own password.
Password Management Frequently Asked Questions
IMPORTANT
password.
The following are some frequently asked questions for all things related to password management.
If you find yourself with a question that you don't know the answer to, or are looking for help with a particular
problem you are facing, you can read on below to see if we've covered it already. If we haven't already, don't
worry! Feel free to ask any question you have that's not covered here on the Azure AD Forums and we'll get
back to you as soon as we can.
This FAQ is split into the following sections:
Questions about Password Reset Registration
Questions about Password Reset
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, they can go to the Password Reset
Registration portal at http://aka.ms/ssprsetup to register their authentication information to be used
with password reset. Users can also register by going to the access panel at
http://myapps.microsoft.com, clicking the profile tab, and clicking the Register for Password Reset
option. Learn more about how to get your users configured for password reset by reading How to get
users configured for password reset.
Q: Can I define password reset data on behalf of my users?
A: Yes, you can do so with DirSync or PowerShell, or through the Azure Management Portal or Office
Admin portal. Learn more about this feature on the blog post Improved Privacy for Azure AD MFA
and Password Reset Phone Numbers and by reading Learn how data is used by password reset.
Q: Can I synchronize data for security questions from on premises?
A: No, this is not possible today, but we are considering it.
Q: Can my users register data in such a way that other users cannot see this data?
A: Yes, when users register data using the Password Reset Registration Portal it gets saved into
private authentication fields that are only visible by Global Administrators and the user himself. Learn
more about this feature on the blog post Improved Privacy for Azure AD MFA and Password Reset
Phone Numbers and by reading Learn how data is used by password reset.
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 will not have to register.
Password reset will work just fine as long as you have properly formatted data stored in the
appropriate fields in the directory. Learn more about by reading Learn how data is used by password
reset.
Q: Can I synchronize or set the Authentication Phone, Authentication Email or Alternate

Authentication Phone fields on behalf of my users?
A: Not currently, but we are considering enabling this capability.
Q: How does the registration portal know which options to show my users?
A: The password reset registration portal only shows the options that you have enabled for your
users under the User Password Reset Policy section of your directorys Configure tab. This means that
if you do not enable, say, security questions, then users will not be able to register for that option.
Q: When is a user considered registered?
A: A user is considered registered when he or she has at least N pieces of authentication info defined,
where N is the Number of Authentication Methods Required that you have set in the Azure
Management Portal. To learn more, see Customizing User Password Reset Policy.
Password reset
Q: How long should I wait to receive an email, SMS, or phone call from password reset?
A: Email, SMS messages, and phone calls should arrive in under 1 minute, with the normal case being
5-20 seconds. If you do not receive the notification in this timeframe, check your junk folder, that the
number / email being contacted is the one you expect, and that the authentication data in the
directory is correctly formatted. To learn more about formatting phone numbers and email addresses
for use with password reset see Learn how data is used by password reset.
Q: What languages are supported by password reset?
A: The password reset UI, SMS messages, and voice calls are localized in the same 40 languages that
are supported in Office 365. Those are: Arabic, Bulgarian, Chinese Simplified, Chinese Traditional,
Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hebrew, Hindi,
Hungarian, Indonesian, Italian, Japanese, Kazakh, Korean, Latvian, Lithuanian, Malay (Malaysia),
Norwegian (Bokml), Polish, Portuguese (Brazil), Portuguese (Portugal), Romanian, Russian, Serbian
(Latin), Slovak, Slovenian, Spanish, Swedish, Thai, Turkish, Ukrainian, and Vietnamese.
Q: What parts of the password reset experience get branded when I set organizational branding
in my directorys configure tab?
A: The password reset portal will show your organizational logo and will also allow you to configure
the Contact your administrator link to point to a custom email or URL. Any email that gets sent by
password reset will include your organizations logo, colors (in this case red), name in the body of the
email, and customized from name. See an example with all the branded elements below. To learn
more, read Customizing Password Reset Look and Feel.
Q: How can I educate my users about where to go to reset their passwords?
A: You can send your users to https://passwordreset.microsoftonline.com directly, or you can instruct
them to click on the Cant access your account link found on any School or Work ID sign in screen.
You can feel free to publish these links (or create URL redirects to them) in any place that is easily
accessible to your users.
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 his or her password and Password Writeback has been deployed with all
versions of Azure AD Connect, or versions of Azure AD Sync 1.0.0485.0222 or later, then that users
account will be automatically unlocked when that user resets his or her password.
Q: How can I integrate password reset directly into my users desktop sign-in experience?
A: This is not possible today. However, if you absolutely need this capability and are an Azure AD
Premium customer, you can install Microsoft Identity Manager at no additional cost and deploy the
on-premises password reset solution found therein to solve this requirement.
Q: Can I set different security questions for different locales?
A: No, this is not possible today, but we are considering it.
Q: How many questions can we configure for the Security Questions authentication option?
A: You can configure up to 20 custom security questions in the Azure Management Portal.
Q: How long may security questions be?

A: Security questions may be between 3 and 200 characters long.
Q: How long may answers to security questions be?
A: Answers may be 3 to 40 characters long.
Q: Are duplicate answers to security questions rejected?
A: Yes, we reject duplicate answers to security questions.
Q: May a user register more than one of the same security question?
A: No, once a user registers a particular question, he or she may not 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. 3-5 security questions may be
required for registration and 3-5 may be required for reset.
Q: If a user has registered more than the maximum number of questions required to reset, how
are security questions selected during reset?
A: N security questions are selected at random out of the total number of questions a user has
registered for, where N is the minimum number of questions required for password reset. For
example, if a user has 5 security questions registered, but only 3 are required to reset, 3 of those 5 will
be selected randomly and presented to the user at the time of reset. If the user gets the answers to the
questions wrong, the selection process re-occurs to prevent question hammering.
Q: Do you prevent users from attempting password reset many times in a short time period?
A: Yes, there are several security features built into password reset. Users may only try 5 password
reset attempts within an hour before being locked out for 24 hours. Users may only try to validate a
phone number 5 times within an hour before being locked out for 24 hours. Users may only try a
single authentication method 5 times within an hour before being locked out for 24 hours.
Q: For how long are the email and SMS one-time passcode valid?
A: The session lifetime for password reset is 105 minutes. This means that from the beginning of the
password reset operation, the user has 105 minutes to reset his or her password. The email and SMS
one-time passcode are invalid after this time period expires.
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 within 5-10 minutes. It some instances
it may take up to an hour to appear.
Q: How can I filter the password management reports?
A: You can filter the password management reports by clicking the small magnifying glass to the
extreme right of the column labels, towards the top of the report (see screenshot). 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 are stored in the password management reports?
A: Up to 1,000 password reset or password reset registration events are stored in the password
management reports. 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 occurring within the last 30 days. We are
currently investigating how to make this a longer time period. 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 1,000 rows may appear on either of the Password Management reports,
whether they are being shown in the UI or being downloaded. We are currently investigating how to
increase this limit.
Q: Is there an API to access the password reset or registration reporting data?
A: Yes, please see the following documentation to learn how you can access the password reset
reporting data stream. Learn how to access password reset reporting events programmatically.
Password Writeback
Q: How does Password Writeback work behind the scenes?
A: See How Password Writeback works for a detailed explanation of what happens when you enable
Password Writeback, as well as how data flows through the system back into your on-premises
environment. See Password Writeback security model in How Password Writeback works to learn
how we ensure Password Writeback is a highly secure service.
Q: How long does Password Writeback take to work? Is there a synchronization delay like 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 realtime 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: What types of accounts does Password Writeback work for?
A: Password Writeback works for Federated and Password Hash Syncd users.
Q: Does Password Writeback enforce my domains password policies?
A: Yes, Password Writeback enforces password age, history, complexity, filters and any other
restriction you may put in place on passwords in your local domain.
Q: Is Password Writeback secure? How can I be sure I wont get hacked?
A: Yes, Password Writeback is extremely secure. To read more about the 4 layers of security
implemented by the Password Writeback service, check out the Password Writeback security model in
How Password Writeback works.

your own password.
How to troubleshoot Password Management
IMPORTANT
password.
If you are having issues with Password Management, we're here to help. Most problems you may run into can be
solved with a few simple troubleshooting steps which you can read about below to troubleshoot your
deployment:
Information to include when you need help
Problems with Password Management configuration in the Azure Management Portal
Problems with Password Managment reports in the Azure Management Portal
Problems with the Password Reset Registration Portal
Problems with the Password Reset Portal
Problems with Password Writeback
Password Writeback event log error codes
Problems with Password Writeback connectivity
If you've tried the troubleshooting steps below and are still running into problems, you can post a question on
the Azure AD Forums or contact support and we'll take a look at your problem as soon as we can.

If you cannot solve your issue with the guidance below, you can contact our support engineers. When you
contact them, it is recommended to include the following information:
General description of the error what exact error message did the user see? If there was no error
message, describe the unexpected behavior you noticed, in detail.
Page what page were you on when you saw the error (include the URL)?
Date / Time / Timezone what was the precise date and time you saw the error (include the timezone)?
Support Code what was the support code generated when the user saw the error (to find this,
reproduce the error, then click the Support Code link at the bottom of the screen and send the support
engineer the GUID that results).
If you are on a page without a support code at the bottom, press F12 and search for SID and CID
and send those two results to the support engineer.
User ID what was the ID of the user who saw the error (e.g. user@contoso.com)?
Information about the user was the user federated, password hash synced, cloud only? Did the user have
an AAD Premium or AAD Basic license assigned?
Application Event Log if you are using Password Writeback and the error is in your on-premises
infrastructure, please zip up a copy of your application event log from your Azure AD Connect server and
send along with your request.
Including this information will help us to solve your problem as quickly as possible.
Troubleshoot password reset configuration in the Azure Management

Portal
If you encounter an error when configuring password reset, you might be able to resolve it by following the
troubleshooting steps below:
Error Case What error does a user see? Solution
I dont see the User Password The User Password Reset Policy This can occur if you do not have
Reset Policy section under the section is not visible on the an AAD Premium or AAD Basic
Configure tab in the Azure Configure tab in the Azure license assigned to the admin
management portal Management Portal. performing this operation.
To rectify this, assign an AAD
Premium or AAD Basic license to
the admin account in question by
navigating to the Licenses tab and
try again.
I dont see any of the configuration The User Password Reset Policy The rest of the UI will appear when
options under the User Password section is visible, but the only flag you switch the Users Enabled for
Reset Policy section that are that appears under it is the Users Password Reset flag to Yes.
described in the documentation. Enabled for Password Reset flag.
I dont see a particular For example, I do not see the Many elements of UI are hidden
configuration option. Number of days before a user until they are needed. Try enabling
must confirm their contact data all the options on the page if you
option when I scroll through the want to see.
User Password Reset Policy
section (or other examples of the See Password Management
same issue). behavior for more info about all of
the controls that are available to
you.
I dont see the Write Back The Write Back Passwords to This option is only visible if you
Passwords to On-Premises On-Premises option is not visible have downloaded Azure AD
configuration option under the Configure tab in the Connect and configured Password
Azure Management Portal Writeback. When you have done
this, that option appears and
allows you to enable or disable
writeback from the cloud.
See Enable Password Writeback in
Azure AD Connect for more
information on how to do this.
Troubleshoot password management reports in the Azure

Management Portal
If you encounter an error when using the password management reports, you might be able to resolve it by
following the troubleshooting steps below:
I dont see any password The Password reset activity and This can occur if you do not have
management reports Password reset registration an AAD Premium or AAD Basic
activity reports are not visible license assigned to the admin
under the Activity Log reports in performing this operation.
the Reports tab.
To rectify this, assign an AAD
Premium or AAD Basic license to
the admin account in question by
navigating to the Licenses tab and
try again.
User registrations show multiple When a user registers alternate Currently, when a user registers,
times email, mobile phone, and security we cannot assume that they will
questions, they each show up as register everything present on the
separate lines instead of a single registration page. As a result, we
line. currently log each individual piece
of data that is registered as a
separate event.
If you want to aggregate this data,
you can download the report and
open the data as a pivot table in
excel to have more flexibility.
Troubleshoot the password reset registration portal

If you encounter an error when registering a user for password reset, you might be able to resolve it by
following the troubleshooting steps below:
Directory is not enabled for Your administrator has not Switch the Users Enabled for
password reset enabled you to use this feature. Password Reset flag to Yes and
hit Save in the Azure
Management Portal directory
configuration tab. You must have
an Azure AD Premium or Basic
License assigned to the admin
performing this operation.
User does not have an AAD Your administrator has not Assign an Azure AD Premium or
Premium or AAD Basic license enabled you to use this feature. Azure AD Basic license to the user
assigned under the Licenses tab in the
Azure Management Portal. You
must have an Azure AD Premium
or Basic License assigned to the
admin performing this operation.
Error processing request User sees an error that states: This can be caused by many issues,
but generally this error is caused
Error processing request by either a service outage or
When attempting to reset a configuration issue that cannot be
password. resolved.
If you see this error and it is
impacting your business, please
contact support and we will assist
you ASAP. See Information to
include when you need help to see
what you should provide to the
support engineer to aid in a
speedy resolution.
Troubleshoot the password reset portal

If you encounter an error when resetting a password for a user, you might be able to resolve it by following the
troubleshooting steps below:
Directory is not enabled for Your account is not enabled for Switch the Users Enabled for
password reset password reset Password Reset flag to Yes and
hit Save in the Azure
We're sorry, but your Management Portal directory
administrator has not set up your configuration tab. You must have
account for use with this service. an Azure AD Premium or Basic
If you'd like, we can contact an License assigned to the admin
administrator in your organization performing this operation.
to reset your password for you.
User does not have an AAD While we cannot reset non-admin Assign an Azure AD Premium or
Premium or AAD Basic license account passwords automatically, Azure AD Basic license to the user
assigned we can contact your organization's under the Licenses tab in the
admin to do it for you. Azure Management Portal. You
must have an Azure AD Premium
or Basic License assigned to the
admin performing this operation.
Directory is enabled for password Your account is not enabled for Ensure that user has properly
reset, but user has missing or mal- password reset formed contact data on file in the
formed authentication information directory before proceeding. See
We're sorry, but your What data is used by password
administrator has not set up your reset for information on how to
account for use with this service. configure authentication
If you'd like, we can contact an information in the directory so that
administrator in your organization users do not see this error.
to reset your password for you.
Directory is enabled for password Your account is not enabled for Ensure that user has at least two
reset, but a user only has one password reset properly configured contact
piece of contact data on file when methods (e.g., both Mobile Phone
policy is set to require two We're sorry, but your and Office Phone) before
verification steps administrator has not set up your proceeding. See What data is used
account for use with this service. by password reset for information
If you'd like, we can contact an on how to configure
administrator in your organization authentication information in the
to reset your password for you. directory so that users do not see
this error.
Directory is enabled for password Oops! We encountered an This could be the result of a
reset, and user is properly unexpected error while contacting temporary service error or
configured, but user is unable to you. misconfigured contact data that
be contacted we could not properly detect. If the
user waits 10 seconds, a try again
and contact your administrator
link appears. Clicking try again will
re-dispatch the call, whereas
clicking contact your
administrator will send a form
email to user, password, or global
admins (in that precedence order)
requesting a password reset to be
performed for that user account.
User never receives the password User clicks text me or call me This could be the result of a mal-
reset SMS or phone call and then never receives anything. formed phone number in the
directory. Make sure the phone
number is in the format +ccc
xxxyyyzzzzXeeee. To learn more
about formatting phone numbers
for use with password reset see
What data is used by password
reset.
If you require an extension to be
routed to the user in question,
note that password reset does not
support extensions, even if you
specify one in the directory (they
are stripped before the call is
dispatched). Try using a number
without an extension, or
integrating the extension into the
phone number in your PBX.
User never receives password reset User clicks email me and then The most common cause for this
email never receives anything. issue 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 are checking
the right email for the message
lots of people have very similar
email addresses and end up
checking the wrong inbox for the
message. If neither of these
options work, its also possible that
the email address in the directory
is malformed, check to make sure
the email address is the right one
and try again. To learn more about
formatting email addresses for use
with password reset see What data
is used by password reset.
I have set a password reset policy, Admin accounts resetting their The options configured under the
but when an admin account uses passwords see the same options User Password Reset Policy
password reset, that policy is not enabled for password reset, email section of the Configure tab only
applied and mobile phone, no matter what apply to end users in your
policy is set under the User organization.
Password Reset Policy section of
the Configure tab. Microsoft manages and controls
the Admin password reset policy in
order to ensure the highest level of
security
User prevented from attempting User sees an error stating: We implement an automatic
password reset too many times in throttling mechanism to block
a day Please use another option. users from attempting to reset
You've tried to verify your account their passwords too many times in
too many times in the last 1 a short period of time. This occurs
hour(s). For security reasons, you'll when:
have to wait 24 hour(s) before you 1. User attempts to validate a
can try again. phone number 5 times in one
If you'd like, we can contact an hour.
administrator in your organization 2. User attempts to use the
to reset your password for you. security questions gate 5 times
in one hour.
3. User attempts to reset a
password for the same user
account 5 times in one hour.
To fix this, instruct the user to wait
24 hours after the last attempt,
and the user will then be able to
reset his or her password.
User sees an error when validating When attempting to verify a This error occurs when the phone
his or her phone number phone to use as an authentication number entered does not match
method, the user sees an error the phone number on file.
stating:
Make sure the user is entering the
Incorrect phone number specified. complete phone number, including
area and country code, when
attempting to use a phone-based
method for password reset.
Error processing request User sees an error that states: This can be caused by many issues,
but generally this error is caused
Error processing request by either a service outage or
When attempting to reset a configuration issue that cannot be
password. resolved.
If you see this error and it is
impacting your business, please
contact support and we will assist
you ASAP. See Information to
include when you need help to see
what you should provide to the
support engineer to aid in a
speedy resolution.
Troubleshoot Password Writeback

If you encounter an error when enabling, disabling, or using Password Writeback, you might be able to resolve it
by following the troubleshooting steps below:

General onboarding and startup Password reset service does not When Password Writeback is
failures start on premises with error 6800 enabled, the sync engine will call
in the Azure AD Connect the writeback library to perform
machines application event log. the configuration (onboarding) by
talking to the cloud onboarding
After onboarding, federated or service. Any errors encountered
password hash synced users during onboarding or while
cannot reset their passwords. starting the WCF endpoint for
Password Writeback will result in
errors in the Event log in your
Azure AD Connect machines event
log.
During restart of ADSync service, if
writeback was configured, the WCF
endpoint will be started up.
However, if the startup of the
endpoint fails, we will simply log
event 6800 and let the sync
service startup. Presence of this
event means that the Password
Writeback endpoint was not
started up. Event log details for
this event (6800) along with event
log entries generate by
PasswordResetService component
will indicate why the endpoint
could not be started up. Review
these event log errors and try to
re-start the Azure AD Connect if
Password Writeback still isnt
working. If the problem persists,
try to disable and re-enable
Password Writeback.
When a user attempts to reset a This can occur if you had upgraded Find the Active Directory account
password or unlock an account from older versions of Azure AD for Azure AD Connect and reset
with password writeback enabled, Connect or DirSync. Upgrading to the password to contain no more
the operation fails. In addition, you older versions of Azure AD than 127 characters. Then open
see an event in the Azure AD Connect set a 254 character Synchronization Service from
Connect event log containing: password for the Azure AD the Start menu. Navigate to
Synchronization Engine returned Management Agent account Connectors and find the Active
an error hr=800700CE, (newer versions will set a 127 Directory Connector. Select it
message=The filename or character length password). Such and click Properties. Navigate to
extension is too long after the long passwords work for AD the page Credentials and enter
unlock operation occurs. Connector Import and Export the new password. Select OK to
operations but they are not close the page.
supported by the Unlock
operation.
Error configuring writeback during At the last step of the Azure AD This error occurs in the following
Azure AD Connect installation. Connect installation process, you two cases:
see an error indicating that
Password Writeback could not be You have specified an incorrect
configured. password for the global
administrator account specified
The Azure AD Connect Application at the beginning of the Azure
event log contains error 32009 AD Connect installation
with text Error getting auth process.
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 error, please ensure that
you are not using a federated
account for the global
administrator you specified at the
beginning of the Azure AD
Connect installation process, and
that the password specified is
correct.
Error configuring writeback during The Azure AD Connect machine The root cause of this error is that
Azure AD Connect installation. event log contains error 32002 the password reset service running
thrown by the in your on-premises environment
PasswordResetService. is not able to connect to the
service bus endpoint in the cloud.
The error reads: Error Connecting This error is normally normally
to ServiceBus, The token provider caused by a firewall rule blocking
was unable to provide a security an outbound connection to a
token particular port or web address.
Make sure your firewall allows
outbound connections for the
following:
All traffic over TCP 443 (HTTPS)
Outbound connections to
Once you have updated these
rules, reboot the Azure AD
Connect machine and Password
Writeback should start working
again.
Password Writeback endpoint on- After working for some time, In some rare cases, the Password
prem not reachable federated or password hash Writeback service may fail to re-
synced users cannot reset their start when Azure AD Connect has
passwords. re-started. In these cases, first,
check whether Password Writeback
appears to be enabled on-prem.
This can be done using the Azure
AD Connect wizard or powershell
(See HowTos section above).If the
feature appears to be enabled, try
enabling or disabling the feature
again either through the UI or
PowerShell. See Step 2: Enable
Password Writeback on your
Directory Sync computer &
configure firewall rules in How to
enable/disable Password Writeback
for more information on how to do
this.
If this doesnt work, try completely
uninstalling and re-installing Azure
AD Connect.
Permissions errors Federated or password hash syncd If you see these errors in your
users who attempt to reset their event log, confirm that the AD MA
passwords see an error after account (that was specified in the
submitting the password indicating wizard at the time of configuration)
there was a service problem. has the necessary permissions for
Password Writeback.
In addition to this, during
password reset operations, you NOTE that once this permission is
may see an error regarding given it can take up to 1 hour for
management agent was denied the permissions to trickle down via
access in your on premises event sdprop background task on the
logs. 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 will continue to fail
with access denied.
Error when configuring Password Unable to Locate MA error in There is a known bug in the
Writeback from the Azure AD Wizard while enabling/disabling released version of Azure AD
Connect configuration wizard Password Writeback Connect which manifests in the
following situation:
1. You configure Azure AD
Connect for tenant abc.com
(Verified domain) using creds .
This results in AAD connector
with name abc.com AAD
being created.
2. You then then change the AAD
creds for the connector (using
old sync UI) to (note its the
same tenant but different
domain name).
3. Now you try to enable/disable
Password Writeback. The wizard
will construct the name of the
connector using the creds, as
abc.onmicrosoft.com AAD
and pass to the Password
Writeback cmdlet. This will fail
because there is no connector
created with this name.
This has been fixed in our latest
builds. If you have an older build,
the one workaround is to use the
powershell cmdlet to
enable/disable the feature. See
Step 2: Enable Password
Writeback on your Directory Sync
computer & configure firewall
rules in How to enable/disable
Password Writeback for more
information on how to do this.
Unable to reset password for users Federated or password hash syncd Privileged users in Active Directory
in special groups such as Domain users who are part of protected are protected using
Admins / Enterprise Admins etc. groups and attempt to reset their AdminSDHolder. See
passwords see an error after http://technet.microsoft.com/maga
submitting the password indicating zine/2009.09.sdadminholder.aspx
there was a service problem. for more details.
This means the security descriptors
on these objects are periodically
checked to match the one specified
in AdminSDHolder and are reset if
they are different. The additional
permissions that are needed for
Password Writeback therefore do
not trickle to such users. This can
result in Password Writeback not
working for such users.As a result,
we do not support managing
passwords for users within these
groups because it breaks the AD
security model.
Reset operations fails with Object Federated or password hash syncd This error usually indicates that the
could not be found users who attempt to reset their sync engine is unable to find either
passwords see an error after the user object in the AAD
submitting the password indicating connector space or the linked MV
there was a service problem. or AD connector space object.
In addition to this, during To troubleshoot this, make sure
password reset operations, you that the user is indeed synced
may see an error in your event from on-prem to AAD via the
logs from the Azure AD Connect current instance of Azure AD
service indicating an Object could Connect and inspect the state of
not be found error. the objects in the connector spaces
and MV. Confirm that the AD CS
object is connector to the MV
object via the
Microsoft.InfromADUserAccountE
nabled.xxx rule.
Reset operations fails with Multiple Federated or password hash syncd This indicates that the sync engine
matches found eror users who attempt to reset their detected that the MV object is
passwords see an error after connected to more than one AD
submitting the password indicating CS objects via the
there was a service problem. Microsoft.InfromADUserAccountE
nabled.xxx. This means that the
In addition to this, during user has an enabled account in
password reset operations, you more than one forest.
may see an error in your event
logs from the Azure AD Connect Currently this scenario is not
service indicating a Multiple supported for Password Writeback.
maches found error.
Password operations fail with a Password operations fail with a This occurs if the Azure AD
configuration error. configuration error. The application Connect configuration is changed
event log contains Azure AD to add a new AD forest (or to
Connect error 6329 with text: remove and re-add an existing
0x8023061f (The operation failed forest) after the Password
because password synchronization Writeback feature has already been
is not enabled on this enabled. Password operations for
Management Agent.) users in such newly added forests
will fail. To fix the problem, disable
and re-enable the Password
Writeback feature after the forest
configuration changes have been
completed.
Writing back passwords that have When attempting to reset a This occurs when the version of
been reset by users works password on behalf of a user from the synchronization engine does
properly, but writing back the Azure Management Portal, you not support the particular
passwords changed by a user or see a message stating: The Password Writeback operation that
reset for a user by an password reset service running in was used. Versions of Azure AD
administrator fails. your on-premises environment Connect later than 1.0.0419.0911
does not support administrators support all password management
resetting user passwords. Please operations, including password
upgrade to the latest version of reset writeback, password change
Azure AD Connect to resolve this. writeback, and administrator-
initiated password reset writeback
from the Azure Management
Portal. DirSync versions later than
1.0.6862 support password reset
writeback only. To resolve this
issue, we highly recommend that
you install the latest version of
Azure AD Connect or Azure Active
Directory Connect. For more
information, see Integrating your
on-premises identities to resolve
this issue and to get the most out
of Password Writeback in your
organization.
Password Writeback event log error codes

A best practice when troubleshooting issues with Password Writeback is to inspect that Application Event Log on
your Azure AD Connect machine. This event log will contain events from two sources of interest for Password
Writeback. The PasswordResetService source will describe operations and issues related to the operation of
Password Writeback. The ADSync source will describe operations and issues related to setting passwords in your
AD environment.
Code Name / Message Source Description

6329 BAIL: MMS(4924) ADSync This event occurs when
0x80230619 A the Password Writeback
restriction prevents the service attempts to set
password from being a password on your
changed to the current local directory which
one 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
will not be able to
change the
password again until
it reaches the
specified age in your
domain. For testing
purposes, 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
will see a failure in
this case. For testing
purposes, history
should be set to 0.
If you have
password complexity
requirements, all of
them will be
enforced when the
user attempts to
change or reset a
password.
If you have
password filters
enabled, and a user
selects a password
which does not meet
the filtering criteria,
then the reset or
change operation
will fail.
HR 8023042 Synchronization Engine ADSync This event occurs when
returned an error the same user id is
hr=80230402, enabled in multiple
message=An attempt domains. For example, if
to get an object failed you are syncing
because there are Account/Resource
duplicated entries with forests, and have the
the same anchor same user id present
and enabled in each,
this error may occur.
This error can also occur
if you are using a non-
unique anchor attribute
(like alias or UPN) and
two users share that
same anchor attribute.
To resolve this issue,
ensure that you do not
have any duplicated
users within your
domains and that you
are using a unique
anchor attribute for
each user.
31001 PasswordResetStart PasswordResetService This event indicates that

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

a user selected a new
password during a
password reset
operation, we
determined that this
password meets
corporate password
requirements, and that
password has been
successfully written
back to the local AD
environment.
31003 PasswordResetFail PasswordResetService This event indicates that
a user selected a
password, and that
password arrived
successfully to the on-
premises environment,
but when we attempted
to set the password in
the local AD
environment, a failure
occurred. This can
happen for several
reasons:
The users password
does not meet the
age, history,
complexity, or filter
requirements for the
domain. Try a
completely new
password to resolve
this.
The MA service
account does not
have the appropriate
permissions to set
the new password
on the user account
in question.
The users account is
in a protected
group, such as
domain or enterprise
admins, which
disallows password
set operations.
See Troubleshoot
Password Writeback to
learn more about what
other situtions can
cause this error.
31004 OnboardingEventStart PasswordResetService This event occurs if you

enable Password
Writeback with Azure
AD Connect and
indicates that we
started onboarding
your organization to
the Password Writeback
web service.
31005 OnboardingEventSucces PasswordResetService This event indicates the
s onboarding process was
successful and that
Password Writeback
capability is ready to
use.
31006 ChangePasswordStart PasswordResetService This event indicates that

detected a password
change request for a
hash syncd user
cloud. This event is the
first event in every
password change
31007 ChangePasswordSucces PasswordResetService This event indicates that

s a user selected a new
password during a
password change
operation, we
password meets
corporate password
password has been
environment.
31008 ChangePasswordFail PasswordResetService This event indicates that
a user selected a
password, and that
password arrived
successfully to the on-
premises environment,
but when we attempted
to set the password in
the local AD
environment, a failure
occurred. This can
happen for several
reasons:
The users password
does not meet the
age, history,
domain. Try a
completely new
password to resolve
this.
The MA service
account does not
permissions to set
the new password
on the user account
in question.
in a protected
group, such as
admins, which
disallows password
set operations.
See Troubleshoot
other situations can
cause this error.
31009 ResetUserPasswordByA PasswordResetService The on-premises service

dminStart detected a password
reset request for a
hash syncd user
administrator on behalf
of a user. This event is
the first event in every
admin-initiated
password reset
31010 ResetUserPasswordByA PasswordResetService The admin selected a
dminSuccess new password during
an admin-initiated
password reset
operation, we
password meets
corporate password
password has been
environment.
31011 ResetUserPasswordByA PasswordResetService The admin selected a

dminFail password on behalf of a
user, and that password
arrived successfully to
the on-premises
environment, but when
we attempted to set the
password in the local
AD environment, a
failure occurred. This
can happen for several
reasons:
The users password
does not meet the
age, history,
domain. Try a
completely new
password to resolve
this.
The MA service
account does not
permissions to set
the new password
on the user account
in question.
in a protected
group, such as
admins, which
disallows password
set operations.
See Troubleshoot
other situtions can
cause this error.
31012 OffboardingEventStart PasswordResetService This event occurs if you
disable Password
Writeback with Azure
AD Connect and
indicates that we
started offboarding
your organization to
web service.
31013 OffboardingEventSucces PasswordResetService This event indicates the

s offboarding process was
successful and that
Password Writeback
capability has been
successfully disabled.
31014 OffboardingEventFail PasswordResetService This event indicates the

offboarding process was
not successful. This
could be due to a
permissions error on
the cloud or on-
premises administrator
account specified during
configuration, or
because you are
attempting to use a
federated cloud global
administrator when
disabling Password
Writeback. To fix this,
check your
administrative
permissions and that
you are not using any
federated account while
configuring the
Password Writeback
capability.
31015 WriteBackServiceStarted PasswordResetService This event indicates that

service has started
successfully and is ready
to accept password
management requests
from the cloud.
31016 WriteBackServiceStoppe PasswordResetService This event indicates that

d the Password Writeback
service has stopped and
that any password
management requests
from the cloud will not
be successful.
31017 AuthTokenSuccess PasswordResetService This event indicates that
we successfully
retrieved an
authorization token for
the global admin
specified during Azure
AD Connect setup in
order to start the
offboarding or
onboarding process.
31018 KeyPairCreationSuccess PasswordResetService This event indicates that

we successfully created
the password
encryption key that will
be used to encrypt
passwords from the
cloud to be sent to your
on-premises
environment.
32000 UnknownError PasswordResetService This event indicates an

unknown error during a
password management
operation. Look at the
exception text in the
event for more details.
If you are having
problems, try disabling
and 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 PasswordResetService This event indicates

there was an error
connecting to the cloud
password reset service,
and generally occurs
when the on-premises
service was unable to
connect to the
password reset web
service.
32002 ServiceBusError PasswordResetService This event indicates
there was an error
connecting to your
tenants service bus
instance. This could
happen because you
are blocking outbound
connections in your on-
premises environment.
Check your firewall to
ensure you allow
connections over TCP
443 and to
https://ssprsbprodncu-
sb.accesscontrol.window
s.net/, and try again. If
you are still having
problems, try disabling
and re-enabling
Password Writeback.
32003 InPutValidationError PasswordResetService This event indicates that

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

there was an error
decrypting the
password that arrived
from the cloud. This
could be because of a
decryption key
mismatch between the
cloud service and your
on-premises
environment. In order
to resolve this, disable
and re-enable Password
Writeback in your on-
32005 ConfigurationError PasswordResetService During onboarding, we
save tenant-specific
information in a
configuration file in
your on-premises
environment. This event
indicates there was an
error saving this file or
that when the service
was started there was
an error reading the file.
To fix this issue, try
disabling and re-
enabling Password
Writeback to force a re-
write of this
configuration file.
32006 EndPointConfigurationE PasswordResetService DEPRECATED This

rror event is not present in
Azure AD Connect, only
very early builds of
DirSync which
supported writeback.
32007 OnBoardingConfigUpda PasswordResetService During onboarding, we

teError send data from the
cloud to the on-
premises password
reset service. That data
is then written to an in-
memory file before
being sent to the sync
service to store this
information securely on
disk. This event
indicates a problem
with writing or updating
that data in memory. To
fix this issue, try
disabling and re-
enabling Password
Writeback to force a re-
write of this
configuration.
32008 ValidationError PasswordResetService This event indicates we

received an invalid
response from the
password reset web
service. To fix this issue,
try disabling and re-
enabling Password
Writeback.
32009 AuthTokenError PasswordResetService This event indicates that
we could not get an
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 or
because the global
admin account specified
is federated. To fix this
issue, re-run
configuration with the
correct username and
password and ensure
the administrator is a
managed (cloud-only or
password-syncd)
account.
32010 CryptoError PasswordResetService This event indicates

there was an error
when generating the
password encryption
key or decrypting a
password that arrives
from the cloud service.
This error likely
indicates an issue with
your environment. Look
at the details of your
event log to learn more
and resolve this issue.
You may also try
disabling and re-
enabling the Password
Writeback service to
resolve this.
32011 OnBoardingServiceError PasswordResetService This event indicates that
could not properly
communicate with the
password reset web
service to initiate the
onboarding process.
This may be because of
a firewall rule or
problem getting an
auth token for your
tenant. To fix this,
ensure that you are not
blocking outbound
connections over TCP
443 and TCP 9350-
9354 or to
s.net/, and that the
AAD admin account
you are using to
onboard is not
federated.
32012 OnBoardingServiceDisa PasswordResetService DEPRECATED This

bleError event is not present in
DirSync which
32013 OffBoardingError PasswordResetService This event indicates that

could not properly
communicate with the
password reset web
service to initiate the
offboarding process.
This may be because of
a firewall rule or
problem getting an
your tenant. To fix this,
ensure that you are not
blocking outbound
connections over 443
or to
s.net/, and that the
AAD admin account
you are using to
offboard is not
federated.
32014 ServiceBusWarning PasswordResetService This event indicates that
we had to retry to
connect to your
tenants 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 its a
high latency or low-
bandwidth connection.
32015 ReportServiceHealthErro PasswordResetService In order to monitor the

r health of your Password
Writeback service, we
send heartbeat data to
our password reset web
service every 5 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 OII or PII
data, and is purely a
heartbeat and basic
service statistics so that
we can provide service
status information in
the cloud.
33001 ADUnKnownError PasswordResetService This event indicates that

there was an unknown
error returned by AD,
check the Azure AD
Connect server event
log for events from the
ADSync source for more
information about this
error.
33002 ADUserNotFoundError PasswordResetService This event indicates that
the user who is trying
to reset or change a
password was not
found in the on-
premises directory. This
could occur when the
user has been deleted
on-premises but not in
the cloud, or if there is
an issue with sync.
Check your sync logs,
as well as the last few
sync run details for
more information.
33003 ADMutliMatchError PasswordResetService 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-
This event indicates that
we found two users in
your on-premises
directory with the same
cloud anchor attribute.
Check your sync logs,
as well as the last few
sync run details for
more information.
33004 ADPermissionsError PasswordResetService This event indicates that

the Management Agent
service account does
not have the
appropriate permissions
on the account in
question to set a new
password. Ensure that
the MA account in the
users forest has Reset
and Change password
permissions on all
objects in the forest. For
more information on
how do to this, see Step
4: Set up the
appropriate Active
Directory permissions.
33005 ADUserAccountDisable PasswordResetService This event indicates that
d 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 ADUserAccountLocked PasswordResetService Event indicates that we

Out 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 ADUserIncorrectPasswo PasswordResetService This event indicates that

rd the user specified an
incorrect current
password when
performing a password
change operation.
Specify the correct
current password and
try again.
33008 ADPasswordPolicyError PasswordResetService This event occurs when
service attempts to set
a password on your
local directory which
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
will not be able to
change the
password again until
it reaches the
specified age in your
domain. For testing
purposes, 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
will see a failure in
this case. For testing
purposes, history
should be set to 0.
If you have
password complexity
requirements, all of
them will be
enforced when the
user attempts to
change or reset a
password.
If you have
password filters
enabled, and a user
selects a password
which does not meet
the filtering criteria,
then the reset or
change operation
will fail.
33009 ADConfigurationError PasswordResetService This event indicates
there was an issue
writing a password back
to your on-premises
directory due to a
configuration issue with
Active Directory. Check
the Azure AD Connect
machines Application
event log for messages
from the ADSync
service for more
information on what
error occurred.
34001 ADPasswordPolicyOrPer PasswordResetService DEPRECATED This

missionError event is not present in
DirSync which
34002 ADNotReachableError PasswordResetService DEPRECATED This

event is not present in
DirSync which
34003 ADInvalidAnchorError PasswordResetService DEPRECATED This

event is not present in
DirSync which
Troubleshoot Password Writeback connectivity

If you are experiencing service interruptions with the Password Writeback component of Azure AD Connect, here
are some quick steps you can take to resolve this:
Restart the Azure AD Connect Sync Service
Disable and re-enable the Password Writeback feature
Install the latest Azure AD Connect release
In general, we recommend that you execute these steps in the order above in order to recover your service in the
most rapid manner.
Restart the Azure AD Connect Sync Service
Restarting the Azure AD Connect Sync Service can help to resolve connectivity issues or other transient issues
with the service.
1. As an administrator, click Start on the server running Azure AD Connect.
2. Type services.msc in the search box and press Enter.
3. Look for the Microsoft Azure AD Connect entry.
4. Right-click on the service entry, click Restart, and wait for the operation to complete.
These steps will re-establish your connection with the cloud service and resolve any interruptions you may be
experiencing. If restarting the Sync Service does not resolve your issue, we recommend that you try to disable
and re-enable the Password Writeback feature as a next step.
Disable and re -enable the Password Writeback feature
Disabling and re-enabling the Password Writeback feature can help to resolve connectivity issues.
1. As an administrator, open the Azure AD Connect configuration wizard.
2. On the Connect to Azure AD dialog, enter your Azure AD global admin credentials
3. On the Connect to AD DS dialog, enter your AD Domain Services admin credentials.
4. On the Uniquely identifying your users dialog, click the Next button.
5. On the Optional features dialog, uncheck the Password write-back checkbox.
6. Click Next through the remaining dialog pages without changing anything until you get to the Ready to
configure page.
7. Ensure that the configure page shows the Password write-back option as disabled and then click the
green Configure button to commit your changes.
8. On the Finished dialog, deselect the Synchronize now option, and then click Finish to close the wizard.
9. Re-open the Azure AD Connect configuration wizard.
10. Repeat steps 2-8, except ensure you check the Password write-back option on the Optional
features screen to re-enable the service.
These steps will re-establish your connection with our cloud service and resolve any interruptions you may be
experiencing.
If disabling and re-enabling the Password Writeback feature does not resolve your issue, we recommend that
you try to re-install Azure AD Connect as a next step.
Install the latest Azure AD Connect release
Re-installing the Azure AD Connect package will resolve any configuration issues which may be affecting your
ability to either connect to our cloud services or to manage passwords in your local AD environment. We
recommend, you perform this step only after attempting the first two steps described above.
1. Download the latest version of Azure AD Connect here.
2. Since you have already installed Azure AD Connect, you will only 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. No additional manual steps are required unless you have customized the out of box sync rules, in
which case you should back these up before proceeding with upgrade and manually re-deploy them
after you are finished.
These steps will re-establish your connection with our cloud service and resolve any interruptions you may be
experiencing.
If installing the latest version of the Azure AD Connect server does not resolve your issue, we recommend that
you try disabling and re-enabling Password Writeback as a final step after installing the latest sync QFE.
If that does not resolve your issue, then we recommend that you take a look at Troubleshoot Password
Writeback and the Azure AD password Management FAQ to see if your issue may be discussed there.
your own password.
Join a personal device to your organization
To join a Windows 10 device to your organization

1. From the Start menu, select Settings.
2. Select Accounts, and then click Your account.
3. Click Add Work or School account, and then type in your organizational account.
4. On the sign-in page for your organization, enter your user name and password, and then click OK.
5. You will be prompted for a multi-factor authentication challenge. (This challenge is configurable by an IT
administrator.)
6. Azure Active Directory (Azure AD) checks whether the device requires mobile device management enrollment.
7. Windows registers the device in the organizations directory in Azure AD and enrolls it in mobile device
management, if appropriate.
8. If you are a managed user, Windows takes you to the desktop through the automatic sign-in.
9. If you are a federated user, you will be taken to a Windows sign-in screen to enter your credentials.
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
Set up a Windows 10 device with Azure AD from
Settings
If you are already using Windows 7 or Windows 8, and your computer or device has been upgraded to Windows
10, you can join to Azure Active Directory (Azure AD) through the Settings menu.
To join to Azure AD from the Settings menu

1. From the Start menu, click the Settings charm.
2. From Settings, select System->About->Join Azure AD.
3. Click Continue in the Azure AD Join message window.
4. Provide your sign-in credentials. This sign-in experience will include all the steps that are required to complete
authentication. If you are part of a federated tenant, your administrator will provide you with the federation
experience that's hosted by your organization.
5. If your organization has configured Azure Multi-Factor Authentication for joining to Azure AD, provide the
second factor before proceeding.
6. Click Accept on the Allow this device to be managed screen.
7. You should see the message "Your device is now joined to your organization in Azure AD".
Conditional access in Azure Active Directory
The control capabilities in Azure Active Directory (Azure AD) conditional access offer simple ways to help secure
resources in the cloud and on-premises. Conditional access policies like multi-factor authentication can help
protect against the risk of stolen and phished credentials. Other conditional access policies can help keep your
organization's data safe. For example, in addition to requiring credentials, you might have a policy that only
devices that are enrolled in a mobile device management system like Microsoft Intune can access your
organization's sensitive services.
Prerequisites
Azure AD conditional access is a feature of Azure Active Directory Premium. Each user who accesses an
application that has conditional access policies applied must have an Azure AD Premium license. You can learn
more about license requirements in Unlicensed user report.
How is conditional access control enforced?

With conditional access control in place, Azure AD checks for the specific conditions you set for a user to access
an application. After access requirements are met, the user is authenticated and can access the application.
Conditions
These are conditions that you can include in a conditional access policy:
Group membership. Control a user's access based on membership in a group.
Location. Use the location of the user to trigger multi-factor authentication, and use block controls when a
user is not on a trusted network.
Device platform. Use the device platform, such as iOS, Android, Windows Mobile, or Windows, as a
condition for applying policy.
Device-enabled. Device state, whether enabled or disabled, is validated during device policy evaluation. If
you disable a lost or stolen device in the directory, it can no longer satisfy policy requirements.
Sign-in and user risk. You can use Azure AD Identity Protection for conditional access risk policies.
Conditional access risk policies help give your organization advance protection based on risk events and
unusual sign-in activities.
Controls
These are controls that you can use to enforce a conditional access policy:
Multi-factor authentication. You can require strong authentication through multi-factor authentication.
You can use multi-factor authentication with Azure Multi-Factor Authentication or by using 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 credentials of a valid user.
Block. You can apply conditions like user location to block user access. For example, you can block access
when a user is not on a trusted network.
Compliant devices. You can set conditional access policies at the device level. You might set up a policy so
that only computers that are domain-joined, or mobile devices that are enrolled in a mobile device
management application, can access your organization's resources. For example, you can use Intune to check
device compliance, and then report it to Azure AD for enforcement when the user attempts to access an
application. For detailed guidance about how to use Intune to protect apps and data, see Protect apps and
data with Microsoft Intune. You also can use Intune to enforce data protection for lost or stolen devices. For
more information, see Help protect your data with full or selective wipe using Microsoft Intune.
Applications
You can enforce a conditional access policy at the application level. Set access levels for applications and services
in the cloud or on-premises. The policy is applied directly to the website or service. The policy is enforced for
access to the browser, and to applications that access the service.
Device-based conditional access

You can restrict access to applications from devices that are registered with Azure AD, and which meet specific
conditions. Device-based conditional access protects an organization's resources from users who attempt to
access the resources from:
Unknown or unmanaged devices.
Devices that dont meet the security policies your organization set up.
You can set policies based on these requirements:
Domain-joined devices. Set a policy to restrict access to devices that are joined to an on-premises Active
Directory domain, and that also are registered with Azure AD. This policy applies to Windows desktops,
laptops, and enterprise tablets. For more information about how to set up automatic registration of domain-
joined devices with Azure AD, see Set up automatic registration of Windows domain-joined devices with
Azure Active Directory.
Compliant devices. Set a policy to restrict access to devices that are marked compliant in the
management system directory. This policy ensures that only devices that meet security policies such as
enforcing file encryption on a device are allowed access. You can use this policy to restrict access from the
following devices:
Windows domain-joined devices. Managed by System Center Configuration Manager (in the
current branch) deployed in a hybrid configuration.
Windows 10 Mobile work or personal devices. Managed by Intune or by a supported third-party
mobile device management system.
iOS and Android devices. Managed by Intune.
Users who access applications that are protected by a device-based, certification authority policy must access the
application from a device that meets this policy's requirements. Access is denied if attempted on a device that
doesnt meet policy requirements.
For information about how to configure a device-based, certification authority policy in Azure AD, see Set device-
based conditional access policy for Azure Active Directory-connected applications.
Resources
See the following resource categories and articles to learn more about setting conditional access for your
organization.
Multi-factor authentication and location policies
Getting started with conditional access to Azure AD-connected apps based on group, location, and multi-
factor authentication policies
Applications that are supported
Device -based conditional access
Set device-based conditional access policy for access control to Azure Active Directory-connected applications
Set up automatic registration of Windows domain-joined devices with Azure Active Directory
Troubleshooting for Azure Active Directory access issues
Help protect data on lost or stolen devices by using Microsoft Intune
Protect resources based on sign-in risk
Azure AD identity protection
Next steps
Conditional access FAQs
Technical reference
Getting started with Azure Active Directory
Conditional Access
Azure Active Directory Conditional Access for SaaS apps and Azure AD connected apps lets you configure
conditional access based on group, location, and application sensitivity.
With conditional access based on application sensitivity, you can set multi-factor authentication (MFA) access rules
per application. MFA per application provides the ability to block access for users who are not on a trusted
network. You can apply MFA rules to all users that are assigned to the application, or only for users within
specified security groups. Users may be excluded from the MFA requirement if they are accessing the application
from an IP address that is inside the organizations network.
These capabilities will be available to customers that have purchased an Azure Active Directory Premium license.
Scenario prerequisites
License for Azure Active Directory Premium
Federated or managed Azure Active Directory tenant
Federated tenants require that multi-factor authentication be enabled.
Configure per-application access rules

This section describes how to configure per-application access rules.
1. Sign in to the Azure classic portal Using an account that is a global administrator for Azure AD.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.
4. Select the Applications tab.
5. Select the application that the rule will be set for.
6. Select the Configure tab.
7. Scroll down to the access rules section. Select the desired access rule.
8. Specify the users the rule will apply to.
9. Enable the policy by selecting Enabled to be On.
Understanding access rules

This section gives a detailed description of the access rules supported in the Azure Conditional Application Access.
Specifying the users the access rules apply to
By default the policy will apply to all users that have access to the application. However, you can also restrict the
policy to users that are members of the specified security groups. The Add Group button is used to select one or
more groups from the group selection dialog that the access rule will apply to. This dialog can also be used to
remove selected groups. When the rules are selected to apply to Groups, the access rules will only be enforced for
users that belong to one of the specified security groups.
Security groups can also be explicitly excluded from the policy by selecting the Except option and specifying one
or more groups. Users that are a member of a group in the Except list will not be subject to the multi-factor
authentication requirement, even if they are a member of a group that the access rule applies to. The access rule
shown below will require all users in the Managers group to use multi-factor authentication when accessing the
application.
Conditional Access Rules with MFA

If a user has been configured using the per-user multi-factor authentication feature, this setting on the user will
combine with the multi-factor authentication rules of the app. This means a user that has been configured for per-
user multi-factor authentication will be required to perform multi-factor authentication even if they have been
exempted from the application multi-factor authentication rules. Learn more about multi-factor authentication and
per-user settings.
Access rule options
The following options are supported:
Require multi-factor authentication: The users to whom the access rules apply to, will be required to
complete multi-factor authentication before accessing the application that the policy applies to.
Require multi-factor authentication when not at work: A user that is coming from a trusted IP address will
not be required to perform multi-factor authentication. The trusted IP address ranges can be configured on the
multi-factor authentication settings page.
Block access when not at work: A user that is not coming from a trusted IP address will be blocked. The
trusted IP address ranges can be configured on the multi-factor authentication settings page.
Setting rule status
Access rule status allows turning the rules on or off. When the access rules are off, the multi-factor authentication
requirement is not enforced.
Access rule evaluation
Access rules are evaluated when a user accesses a federated application that uses OAuth 2.0, OpenID Connect,
SAML or WS-Federation. In addition, access rules are evaluated when the OAuth 2.0 and OpenID Connect use a
refresh token to acquire an access token. If policy evaluation fails when a refresh token is used, the error
invalid_grant will be returned, this indicates the user needs to re-authenticate to the client.
Configure federation services to provide multi-factor authentication
For federated tenants, MFA may be performed by Azure Active Directory or by the on-premises AD FS server.
By default, MFA will occur at a page hosted by Azure Active Directory. To configure MFA on-premises, the
SupportsMFA property must be set to true in Azure Active Directory, by using the Azure AD module for Windows
PowerShell.
The following example shows how to enable on-premises MFA by using the Set-MsolDomainFederationSettings
cmdlet on the contoso.com tenant:
Set-MsolDomainFederationSettings -DomainName contoso.com -SupportsMFA $true
In addition to setting this flag, the federated tenant AD FS instance must be configured to perform multi-factor
authentication. Follow the instructions for deploying Azure Multi-Factor Authentication on-premises.
Related Articles
Securing access to Office 365 and other apps connected to Azure Active Directory
Applications that use conditional access rules in Azure
Active Directory
Conditional access rules are supported in Azure Active Directory (Azure AD)-connected applications, pre-integrated
federated software as a service (SaaS) applications, applications that use password single sign-on (SSO), line-of-
business applications, and applications that use Azure AD Application Proxy. For a detailed list of applications for
which you can use conditional access, see Services enabled with conditional access. Conditional access works both
with mobile and desktop applications that use modern authentication. In this article, we cover how conditional
access works in mobile and desktop apps.
You can use Azure AD sign-in pages in applications that use modern authentication. With a sign-in page, a user is
prompted for multi-factor authentication. A message is shown if the user's access is blocked. Modern
authentication is required for the device to authenticate with Azure AD, so that device-based conditional access
policies are evaluated.
It's important to know which applications can use conditional access rules, and the steps that you might need to
take to secure other application entry points.
Applications that use modern authentication

NOTE
If you have a conditional access policy in Azure AD that has an equivalent in Office 365, configure both conditional access
policies. This would apply, for example, to conditional access policies for Exchange Online or SharePoint Online.
The following applications support conditional access for Office 365 and other Azure AD-connected service
applications:
TARGET SERVICE PLATFORM APPLICATION
Office 365 Exchange Online Windows 10 Mail/Calendar/People app, Outlook

2016, Outlook 2013 (with modern
authentication), Skype for Business (with
modern authentication)
Office 365 Exchange Online Windows 8.1, Windows 7 Outlook 2016, Outlook 2013 (with
modern authentication), Skype for
Business (with modern authentication)
Office 365 Exchange Online iOS, Android Outlook mobile app
Office 365 Exchange Online Mac OS X Outlook 2016 for multi-factor

authentication and location only;
device-based policy support planned for
the future, Skype for Business support
planned for the future
TARGET SERVICE PLATFORM APPLICATION
Office 365 SharePoint Online Windows 10 Office 2016 apps, Universal Office apps,
Office 2013 (with modern
authentication), OneDrive sync client
(see notes), Office Groups support
planned for the future, SharePoint app
support planned for the future
Office 365 SharePoint Online Windows 8.1, Windows 7 Office 2016 apps, Office 2013 (with
modern authentication), OneDrive sync
client (see notes)
Office 365 SharePoint Online iOS, Android Office mobile apps
Office 365 SharePoint Online Mac OS X Office 2016 apps for multi-factor
authentication and location only;
device-based policy support planned for
the future
Office 365 Yammer Windows 10, iOS, and Android Office Yammer app
Dynamics CRM Windows 10, Windows 8.1, Windows 7, Dynamics CRM app
iOS, and Android
PowerBI service Windows 10, Windows 8.1, Windows 7, PowerBI app

iOS, and Android
Azure Remote App service Windows 10, Windows 8.1, Windows 7, Azure Remote app
iOS, Android, and Mac OS X
Any My Apps app service Android and iOS Any My Apps app service
Applications that do not use modern authentication

Currently, you must use other methods to block access to apps that do not use modern authentication. Access rules
for apps that don't use modern authentication are not enforced by conditional access. This primarily is a
consideration for Exchange and SharePoint access. Most earlier versions of apps use older access control protocols.
Control access in Office 365 SharePoint Online
You can disable legacy protocols for SharePoint access by using the Set-SPOTenant cmdlet. Use this cmdlet to
prevent Office clients that use non-modern authentication protocols from accessing SharePoint Online resources.
Example command: Set-SPOTenant -LegacyAuthProtocolsEnabled $false
Control access in Office 365 Exchange Online

Exchange offers two main categories of protocols. Review the following options, and then select the policy that is
right for your organization.
Exchange ActiveSync. By default, conditional access policies for multi-factor authentication and location are
not enforced for Exchange ActiveSync. You need to protect access to these services either by configuring
Exchange ActiveSync policy directly, or by blocking Exchange ActiveSync by using Active Directory Federation
Services (AD FS) rules.
Legacy protocols. You can block legacy protocols with AD FS. This blocks access to older Office clients, such as
Office 2013 without modern authentication enabled, and earlier versions of Office.
Use AD FS to block legacy protocol
You can use the following example rules to block legacy protocol access at the AD FS level. Choose from two
common configurations.
Option 1: Allow Exchange ActiveSync, and allow legacy apps, but only on the intranet
By applying the following three rules to the AD FS relying party trust for Microsoft Office 365 Identity Platform,
Exchange ActiveSync traffic, and browser and modern authentication traffic, have access. Legacy apps are blocked
from the extranet.
Ru l e 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");
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"] &&
c2:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~
"(/adfs/ls)|(/adfs/oauth2)"]
Option 2: Allow Exchange ActiveSync, and block legacy apps

By applying the following three rules to the AD FS relying party trust for Microsoft Office 365 Identity Platform,
Exchange ActiveSync traffic, and browser and modern authentication traffic, have access. Legacy apps are blocked
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"] &&
Get started with Azure Active Directory Device
Registration
Azure Active Directory Device Registration is the foundation for device-based conditional access scenarios. When a
device is registered, Azure Active Directory Device Registration provides the device with an identity which is used
to authenticate the device when the user signs in. The authenticated device, and the attributes of the device, can
then be used to enforce conditional access policies for applications that are hosted in the cloud and on-premises.
When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device attributes
in Azure Active Directory 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.
Scenarios enabled by Azure Active Directory Device Registration

Azure Active Directory Device Registration includes support for iOS, Android, and Windows devices. The individual
scenarios that utilize Azure AD Device Registration may have more specific requirements and platform support.
These scenarios are as follows:
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.
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.
Setting up Azure Active Directory Device Registration

You need to enable Azure AD Device Registration in the Azure Portal so that mobile devices can discover the
service by looking for well-known DNS records. You must configure your company DNS so that Windows 10,
Windows 8.1, Windows 7, Android and iOS devices can discover and use the service. You can view and
enable/disable registered devices using the Administrator Portal in Azure Active Directory.
NOTE
For latest instructions on how to set up automatic device registration see, How to setup automatic registration of Windows
domain joined devices with Azure Active Directory.
Enable Azure Active Directory Device Registration Service

1. Sign in to the Microsoft Azure portal as Administrator.
5. Scroll to the section called Devices.
6. Select ALL for USERS MAY WORKPLACE JOIN DEVICES.
7. Select the maximum number of devices you want to authorize per user.
NOTE
Enrollment with Microsoft Intune or Mobile Device Management for Office 365 requires Workplace Join. If you have
configured either of these services, ALL is selected and the NONE button is disabled.
By default, two-factor authentication is not enabled for the service. However, two-factor authentication is
recommended when registering a device.
Before requiring two-factor authentication for this service, you must configure a two-factor authentication
provider in Azure Active Directory and configure your user accounts for Multi-Factor Authentication, see
Adding Multi-Factor Authentication to Azure Active Directory
If you are using AD FS with Windows Server 2012 R2, you must configure a two-factor authentication module
in AD FS, see Using Multi-Factor Authentication with Active Directory Federation Services.
Configure Azure Active Directory Device Registration discovery

Windows 7 and Windows 8.1 devices will discover the Device Registration service by combining the user account
name with a well-known Device Registration server name.
You must create a DNS CNAME record that points to the A record associated with your Azure Active Directory
Device Registration service. The CNAME record must use the well-known prefix enterpriseregistration followed by
the UPN suffix used by the user accounts at your organization. If your organization uses multiple UPN suffixes,
multiple CNAME records must be created in DNS.
For example, if you use two UPN suffixes at your organization named @contoso.com and @region.contoso.com,
you will create the following DNS records.
ENTRY TYPE ADDRESS
enterpriseregistration.contoso.com CNAME enterpriseregistration.windows.net
enterpriseregistration.region.contoso.co CNAME enterpriseregistration.windows.net

m
View and manage device objects in Azure Active Directory

1. From the Azure Administrator portal, you can view, block, and unblock devices. A device that is blocked will no
longer have access to applications that are configured to allow only registered devices.
2. Log on to the Microsoft Azure Portal as Administrator.
4. Select your directory.
5. Select the Users tab. Then select a user to view their devices
6. Select the Devices tab.
7. Select Registered Devices from the drop down menu.
8. Here you can view, block, or unblock the users registered devices.
Additional topics
You can register your Windows 7 and Windows 8.1 Domain Joined devices with Azure AD Device Registration. The
following topics provides more information about the prerequisites and the steps required to configure device
registration on Windows 7 and Windows 8.1 devices.
Automatic Device Registration with Azure Active Directory for Windows Domain-Joined Devices
Configure automatic device registration for Windows 7 domain joined devices
Configure automatic device registration for Windows 8.1 domain joined devices
Automatic device registration with Azure Active Directory for Windows 10 domain-joined devices
Automatic device registration with Azure Active
Directory for Windows domain-joined devices
As an IT Administrator, you can choose to automatically and silently register your domain-joined Windows devices
with Azure Active Directory (Azure AD). This can be useful if you have configured device based conditional access
polices to Office365 applications or applications managed on-premises by AD FS. You can learn more about the
device registration scenarios by reading the Azure Active Directory Device Registration Overview.
NOTE
Automatic Device Registration with Azure Active Directory is available for Windows 7 and Windows 8.1 machines
that have been joined to an Active Directory domain. These are typically corporate owned machines that have been
provided to information workers.
To begin registering your domain joined Windows devices with Azure AD, follow the prerequisites below. Once
you complete the prerequisites, configure automatic device registration for your domain joined Windows devices.
Deploy AD FS and connect to Azure Active Directory using Azure

Active Directory Connect
1. Use Azure Active Directory Connect to deploy Active Directory Federation Services (AD FS) with Windows
Server 2012 R2 and set up a federation relationship with Azure Active Directory.
2. Configure an additional Azure Active Directory relying party trust claim rule.
3. Open the AD FS management console and navigate to AD FS>Trust Relationships>Relying Party Trusts.
Right-click on the Microsoft Office 365 Identity Platform relying party trust object and select Edit Claim
Rules
4. On the Issuance Transform Rules tab, select Add Rule.
5. Select Send Claims Using a Custom Rule from the Claim rule template drop down box. Select Next.
6. Type Auth Method Claim Rule in the Claim rule name: text box.
7. Type the following claim rule in the Claim rule: text box:
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"]
=> issue(claim = c);
8. Click OK twice to complete the dialog box.
Configure an additional Azure Active Directory relying party trust

Authentication Class Reference
On your federation server, open a Windows PowerShell command window and type:
Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences wiaormultiauthn
Where is the relying party object name for your Azure Active Directory relying party trust object. This object is
typically named Microsoft Office 365 Identity Platform.
AD FS Global Authentication Policy

Configure the AD FS Global Primary Authentication Policy to allow Windows Integrated Authentication for the
Intranet (this is the default).
Internet Explorer Configuration

Configure the following settings on Internet Explorer on your Windows devices for the Local intranet security zone:
Dont prompt for client certificate selection when only one certificate exists: Enable
Allow scripting: Enable
Automatic logon only in Intranet zone: Checked
These are the default settings for the Internet Explorer Local intranet security zone. You can view or manage these
settings in Internet Explorer by navigating to Internet Options > Security > Local intranet > Custom level. You
can also configure these settings using Active Directory Group Policy.
Network Connectivity
Domain joined Windows devices must have connectivity to AD FS and an Active Directory Domain Controller to
automatically register with Azure AD. This typically means the machine must be connected to the corporate
network. This can include a wired connection, a Wi-Fi connection, DirectAccess, or VPN.
Configure Azure Active Directory Device Registration discovery

Windows 7 and Windows 8.1 devices will discover the Device Registration Server by combining the user account
name with a well-known Device Registration server name. You must create a DNS CNAME record that points to the
A record associated with your Azure Active Directory Device Registration Service. The CNAME record must use the
well-known prefix enterpriseregistration followed by the UPN suffix used by the user accounts at your
organization. If your organization uses multiple UPN suffixes, multiple CNAME records must be created in DNS.
For example, if you use two UPN suffixes at your organization named @contoso.com and @region.contoso.com,
you will create the following DNS records.
ENTRY TYPE ADDRESS
enterpriseregistration.contoso.com CNAME enterpriseregistration.windows.net
enterpriseregistration.region.contoso.co CNAME enterpriseregistration.windows.net

m
Configure Automatic Device Registration for Windows 7 and Windows

8.1 domain joined devices
Configure Automatic Device Registration for your Windows 7 and Windows 8.1 domain joined devices using the
links below. Be sure that you have completed the prerequisites above before you continue.
Configure Automatic Device Registration for Windows 8.1 domain joined devices
Configure Automatic Device Registration for Windows 7 domain joined devices
Automatic device registration with Azure Active Directory for Windows 10 Domain-Joined Devices
Additional Notes
Device registration with Azure AD provides the broadest set of device capabilities. With Azure AD Device
Registration, you can register both personal (BYOD) mobile devices and company owned, domain joined devices.
The devices can be used with both hosted services such as Office365 and services managed on-premises with AD
FS.
Companies that use both mobile and traditional devices or that use Office365, Azure AD, or other Microsoft
services should register devices in Azure AD using the Azure AD Device Registration service.If your company does
not use mobile devices and does not use any Microsoft services such as Office365, Azure AD, or Microsoft Intune
and instead hosts only on-premises applications, you can choose to register devices in Active Directory using AD
FS.
You can learn more about deploying device registration with AD FS here.
Additional topics
How to configure automatic registration of Windows
domain-joined devices with Azure Active Directory
To use Azure Active Directory device-based conditional access, your computers must be registered with Azure
Active Directory (Azure AD). This article provides you with the steps for configuring the automatic registration of
Windows domain-joined devices with Azure AD in your organization.
NOTE
The Windows 10 November Update offers some of the enhanced user experiences in Azure AD, but the Windows 10
Anniversary Update fully supports device-based conditional access. For more information about conditional access, see
Azure Active Directory device-based conditional access. For more information about Windows 10 devices in the workplace
and how a user registers a Windows 10 device with Azure AD, see Windows 10 for the enterprise: Use devices for work.
For devices running Windows, you can register some earlier versions of Windows, including:
Windows 8.1
Windows 7
For devices running Windows Server, you can register the following platforms:
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Prerequisites
The main requirement for automatic registration of domain-joined devices by using Azure AD is to have an up-to-
date version of Azure Active Directory Connect (Azure AD Connect).
Depending on how you deployed Azure AD Connect, and whether you used an express or custom installation or
an in-place upgrade, the following prerequisites might have been configured automatically:
Service connection point in on-premises Active Directory - For discovery of Azure AD tenant
information by computers that register for Azure AD.
Active Directory Federation Services (AD FS) issuance transform rules - For computer authentication
on registration (applicable to federated configurations).
If some devices in your organizations are not Windows 10 domain-joined devices, perform the following steps:
Set a policy in Azure AD to enable users to register devices
Set Integrated Windows Authentication (IWA) as a valid alternative to multi-factor authentication in AD FS
Step 1: Configure service connection point

A service connection point (SCP) object must exist in the configuration naming context partition of the computer's
domain. The service connection point holds discovery information about the Azure AD tenant where computers
register. In a multi-forest Active Directory configuration, the service connection point must exist in all forests that
have domain-joined computers.
The SCP is located at:
CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your
Configuration Naming Context]
For a forest with the Active Directory domain name example.com, the configuration naming context is:
CN=Configuration,DC=example,DC=com
With the following Windows PowerShell script, you can verify the existence of the object and retrieve the
discovery values:
$scp = New-Object System.DirectoryServices.DirectoryEntry;
$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration

Configuration,CN=Services,CN=Configuration,DC=example,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 doesnt exist, create it by running the following PowerShell script on your Azure AD
Connect server:
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;
Remarks:
When you run $aadAdminCred = Get-Credential, you are required to type a user name. For the user
name, use the following format: user@example.com
When you run the Initialize-ADSyncDomainJoinedComputerSync cmdlet, replace [connector account
name] with the domain account that's used in the Active Directory connector account.
The cmdlet uses the Active Directory PowerShell module, which relies on Active Directory Web Services in a
domain controller. Active Directory Web Services is supported on domain controllers in Windows Server
2008 R2 and later. For domain controllers in Windows Server 2008 or earlier versions, use the
System.DirectoryServices API via PowerShell to create the service connection point, and then assign the
Keywords values.
Step 2: Register your devices

The right steps for registering your device depend on whether your organization is federated or not.
Device registration in non-federated organizations
Device registration in a non-federated organization is only supported if the following is true:
You are either running Windows 10 and Windows Server 2016 on your device
Your devices are domain-joined
Password sync using Azure AD Connect is enabled
If all of these requirements are satisfied, you don't have to do anything to get your devices registered.
Device registration in federated organizations
In a federated Azure AD configuration, devices rely on AD FS (or on the on-premises federation server) to
authenticate to Azure AD. They register against Azure Active Directory Device Registration Service.
For Windows 10 and Windows Server 2016 computers, Azure AD Connect associates the device object in Azure
AD with the on-premises computer account object. The following claims must exist during authentication for
Azure AD Device Registration Service to complete registration and create the device object:
http://schemas.microsoft.com/ws/2012/01/accounttype - Contains the DJ value, which identifies the
principal authenticator as a domain-joined computer.
http://schemas.microsoft.com/identity/claims/onpremobjectguid - Contains the value of the
objectGUID attribute of the on-premises computer account.
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid - Contains the computer's
primary security identifier (SID), which corresponds to the objectSid attribute value of the on-premises
computer account.
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid - Contains the value that Azure
AD uses to trust the token issued from AD FS or from the on-premises Security Token Service (STS). This is
important if you have several verified domains in Azure AD. For the AD FS case, use http://<domain-
name>/adfs/services/trust/, where <domain-name> is the verified domain name in Azure AD.
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.
Windows 10 and Windows Server 2016 domain joined computers authenticate using Windows Integrated
authentication to an active WS-Trust endpoint hosted by AD FS. Ensure that this endpoint is enabled. If you are
using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. The end-point
is adfs/services/trust/13/windowstransport.
It should be enabled in the AD FS management console under Service > Endpoints. If you dont have AD FS as
your on-premises federation server, follow the instructions of your vendor to make sure the corresponding end-
point is enabled.
NOTE
If you dont use AD FS for your on-premises federation server, follow your vendor's instructions to create the rules that
issue these claims.
To create the rules manually, in AD FS:

Select the one of the following Windows PowerShell scripts
Run the Windows PowerShell script in a session that is connected to your server.
Replace the first line with your organization's validated domain name in Azure AD.
Setting AD FS rules in a single domain environment
Use the following script to add the AD FS rules if you only have one verified domain:
<#----------------------------------------------------------------------
| Modify the Azure AD Relying Party to include the claims needed
| for DomainJoin++. The rules include:
| -ObjectGuid
| -AccountType
| -ObjectSid
+---------------------------------------------------------------------#>
$rule1 = '@RuleName = "Issue object GUID"
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "-515$", Issuer =~

"^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD

AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
=> issue(store = "Active Directory", types =

("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), query = ";objectguid;{0}", param =
c2.Value);'
$rule2 = '@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");'
$rule3 = '@RuleName = "Pass through primary SID"
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "-515$", Issuer =~

"^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD

=> issue(claim = c2);'
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules

$crSet.ClaimRulesString
Setting AD FS rules in a multi domain environment

If you have more than one verified domain, perform the following steps:
1. Remove the existing IssuerID rule created by Azure AD Connect.
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,
".+@(?.+)", "http://${domain}/adfs/services/trust/"));
2. Run this script:
<#----------------------------------------------------------------------
| Modify the Azure AD Relying Party to include the claims needed
| for DomainJoin++. The rules include:
| -ObjectGuid
| -AccountType
| -ObjectSid
+---------------------------------------------------------------------#>
$VerifiedDomain = 'example.com' # Replace example.com with one of your verified domains

$VerifiedDomain = 'example.com' # Replace example.com with one of your verified domains
$rule1 = '@RuleName = "Issue object GUID"
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "-515$",

Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~

"^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
=> issue(store = "Active Directory", types =

("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), query = ";objectguid;{0}", param =
c2.Value);'
$rule2 = '@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");'
$rule3 = '@RuleName = "Pass through primary SID"
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "-515$",

Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&
c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD

=> issue(claim = c2);'
$rule4 = '@RuleName = "Issue AccountType with the value User when its not a computer account"
NOT EXISTS([Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "DJ"])
=> add(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Value = "User");'
$rule5 = '@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[Type == "http://schemas.xmlsoap.org/claims/UPN"] &&
c2:[Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "User"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =

regexreplace(c1.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));'
$rule6 = '@RuleName = "Update issuer for DJ computer auth"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "DJ"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =

"http://'+$VerifiedDomain+'/adfs/services/trust/");'
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier

urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4+ $rule5+ $rule6
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules

$crSet.ClaimRulesString
Step 3: Setup AD FS for authentication of device registration

Make sure that WIA is set as a valid alternative to multi-factor authentication for device registration in AD FS. To
do this, you need to have an issuance transform rule that passes through the authentication method.
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 this rule:
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);
8. On your federation server, type this PowerShell command:
Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences
wiaormultiauthn
<RPObjectName> is the relying party object name for your Azure AD relying party trust object. This object
usually is named Microsoft Office 365 Identity Platform.
Step 4: Deployment and rollout

When domain-joined computers meet the prerequisites, they are ready to register with Azure AD.
The Windows 10 Anniversary Update and Windows Server 2016 domain-joined computers automatically register
with Azure AD the next time the device restarts or when a user signs in to Windows. New computers that are
joined to the domain register with Azure AD when the device restarts after the domain join operation.
NOTE
Windows 10 domain-joined computers running Windows 10 November Update will automatically register with Azure AD,
only if the rollout Group Policy object is set.
You can use a Group Policy object to control the rollout of automatic registration of Windows 10 and Windows
Server 2016 domain-joined computers.
To roll out automatic registration of non-Windows 10 domain-joined computers, you can deploy a Windows
Installer package to computers that you select.
NOTE
For all non-Windows 10/Windows Server 2016 computers it is recommended to use the Windows Installer package as
described below in this document.
Create a Group Policy object to control the rollout of automatic registration

To control the rollout of automatic registration of domain-joined computers with Azure AD, you can deploy the
Register domain-joined computers as devices Group Policy to the computers 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 10 or Windows Server 2016 computers.
3. Right-click Group Policy Objects, and then select New.
4. Type a name for your Group Policy object. For example, Automatic Registration to Azure AD. Select OK.
5. Right-click your new Group Policy object, and then select Edit.
6. Go to Computer Configuration > Policies > Administrative Templates > Windows Components >
Device Registration. 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.
7. Select Enabled, and then select Apply.

8. Select OK.
9. 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 register
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 register domain-joined computers running Windows 8.1, Windows 7, Windows Server 2012 R2, Windows
Server 2012, or Windows Server 2008 R2 in a federated environment, you can download and install these
Windows Installer package (.msi) files:
x64
x86
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 2016 offers additional benefits from earlier versions, like the ability to track completed registrations. For
more information, see System Center 2016.
The installer creates a scheduled task on the system that runs in the users context. The task is triggered when the
user signs in to Windows. The task silently registers the device with Azure AD with the user credentials after
authenticating through IWA. To see the scheduled task, go to Microsoft > Workplace Join, and then go to the
Task Scheduler library.
Next steps
Azure Active Directory conditional access
Configure automatic device registration for Windows
7 domain joined devices
As an IT admin, you can configure your Windows 7 domain joined devices to automatically register with Azure AD.
To do so, you must deploy the device registration software package to your Windows 7 domain joined devices
using a software distribution system such as System Center Configuration Manager. Be sure to read through and
complete the prerequisites listed in Automatic Device Registration with Azure Active Directory for Windows
Domain-Joined devices.
NOTE
Installing the device registration software package on Windows 7

domain joined devices
Device registration for Windows 7 is available as a downloadable MSI package. The package must be installed on
Windows 7 machines that are joined to an Active Directory Domain. You should deploy the package using a
software distribution system such as System Center Configuration Manager. The MSI package supports the
standard silent install options using the /quiet parameter. The software package is available for download at the
Microsoft Connect website. Here you can select and then download Workplace Join for Windows 7.
Workplace Join with Azure Active Directory

Device registration for Windows 7 domain joined devices does not require or include a user interface. Once
installed on the machine, any domain user that logs into the machine will be automatically and silently registered
with a device object in Azure AD. There will be one device object in Azure AD for every registered user of the
physical device.
The installer creates a Scheduled Task on the system that runs in the users context and is triggered on user sign-
in. The task silently registers the user and device with Azure AD after the user signs-in is complete. The Scheduled
Task can be found in the Task Scheduler Library under Microsoft > Workplace Join. The task will run and
register any and all Active Directory users that sign-in to the machine. The following illustration lists the step-by-
step process for automatic device registration.
1. A user (information worker) logs on to a Windows 7 client computer using Active Directory domain credentials.
2. The Workplace Join scheduled task is executed.
3. The user is silently authenticated with AD FS using Windows Integrated Authentication.
4. The Windows 7 PC is registered to the user in Azure AD.
5. A device object and certificate is created in Azure AD. The object represents the user@device.
6. The Workplace Join certificate is stored on the machine.
Unregistering your Windows 7 domain joined devices

You may choose unregister your domain joined Windows 7 devices by doing the following: Uninstall the
Workplace Join software package from your Windows 7 domain joined devices using a software distribution
system such as System Center Configuration Manager.
Then, open a command prompt on the Windows 7 machine and execute the following command to unregister the
device:
%ProgramFiles%\Microsoft Workplace Join\AutoWorkplace.exe /leave
NOTE
This command must be run in the context of each domain user that has signed into the machine. Event Viewer and Errors
for Windows 7 domain joined devices.
The Windows Event Log on the Windows 7 machine will display messages related to Workplace Join. You can find
messages for both successful and unsuccessful Workplace Join events. The Event Log can be found in the Event
Viewer under Applications and Services Logs> Microsoft-Workplace Join.
Additional topics
Automatic device registration with Azure Active Directory for Windows Domain-Joined Devices
Configure automatic device registration for Windows
8.1 domain joined devices
You can use an Active Directory Group Policy to configure your Windows 8.1 domain joined devices to
automatically register with Azure AD. To configure the Group Policy, you must have at least one domain joined
Windows Server 2012 R2 or Windows 8.1 machine with the Group Policy Management feature installed. Once this
Group Policy is enabled for your domain, any domain user that logs into the machine will be automatically and
silently registered with a device object in Azure AD. There will be one device object in Azure AD for every
registered user of the physical device.Be sure to read through and complete the prerequisites from the Automatic
Device Registration with Azure Active Directory for Windows Domain-Joined Devices.
NOTE
Configure the Group Policy for your Windows 8.1 domain joined
devices
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
would like to enable Automatic Workplace Join.
3. Right-click Group Policy Objects and select New. Give your Group Policy object a name, for example,
Automatic Workplace Join. Click OK.
4. Right-click on your new Group Policy object and then select Edit.
5. Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components
> Workplace Join.
6. Right-click Automatically workplace join client computers and then select Edit.
7. Select the Enabled radio button and then click Apply. Click OK.
8. You may now link the Group Policy object to a location of your choice. To enable this policy for all of the
domain joined Windows 8.1 devices at your organization, link the Group Policy to the domain.
Unregistering your Windows 8.1 domain joined devices

You may choose unregister your domain joined Windows 8.1 devices by doing the following: Modify the
Workplace Join Group Policy settings created in the previous section. Set the Automatically workplace join client
computers policy to disabled. This will prevent new devices from automatically joining the workplace.
Unregister the existing domain joined Windows 8.1 machines by following one of the two options below:
Option 1: Unregister a Windows 8.1 domain joined device using PC Settings
1. On the Windows 8.1 device, navigate to PC Settings > Network > Workplace
2. Select Leave. This process must be repeated for each domain user that has signed into the machine and
has been automatically workplace joined.
Option 2: Unregister a Windows 8.1 domain joined device using a script
1. Open a command prompt on the Windows 8.1 machine and execute the following command:
%SystemRoot%\System32\AutoWorkplace.exe leave
This command must be run in the context of each domain user that has signed into the machine.
Event Viewer & Errors for Windows 8.1 domain joined devices
The Windows Event Log on a Windows 8.1 machine displays messages related to device registration. You will find
messages for both successful and unsuccessful events.
The Event Log can be found in the Event Viewer under Applications and Services Logs > Microsoft > Windows >
Workplace Join.
Additional details
The Group Policy enables a Scheduled Task on the system that runs in the users context and is triggered on user
sign-in. The task will silently register the user and device with Azure AD after the sign-in is complete. The
Scheduled Task can be found on Windows 8.1 devices in the Task Scheduler Library under Microsoft > Windows
> Workplace Join. The task will run and register any and all Active Directory users that sign-into.
Additional topics
Azure Authenticator for Android
Your IT administrator may have recommended you to use the Microsoft Azure Authenticator to sign-in to access
your work resources. This application provides these two sign-in options:
Multi-Factor Authentication allows you to secure your work or school accounts with two-step verification. You
sign-in using something you know (for example, your password) and protect the account even further with
something you have (a security key from this app). The Azure Authenticator app notifies you of a pending two-
factor verification request by displaying an alert to your mobile device. You need to simply view the request in
the app and tap verify or cancel. Alternately, you may be prompted to enter the passcode displayed in the app.
Work Account allows you to turn your Android phone or tablet into a trusted device and provide Single Sign-On
(SSO) to company applications. Your IT administrator may require you to add a work account in order to access
company resources. SSO lets you sign in once and automatically avail of signing in across all applications your
company has made available to you.
Installing the Azure Authenticator app

You can install the Azure Authenticator app from Google Play Store. The instructions to add work account from
Samsung Android device vs a non-Samsung Android device are slightly different. The instructions for both are
listed below.
Adding the work account from Samsung Android device

Adding the work account through the app home screen
The following instructions are applicable to Samsung GS3 and above phones or Note2 and above tablets.
1. On the home screen of the app, accept the end user license agreement (EULA).
2. On the Activate Account screen, click the context menu on the right and select Work account.
3. On the Add Account screen, select** Work Account**.
4. On Activate device administrator screen, click Activate.
5. On the Privacy Policy screen, select the checkbox and click Confirm.
6. On the Workplace Join screen, enter the userID provided by your organization and click Join.
7. To sign in to the Azure Authenticator app, enter your organizational a*ccount and password and click *Sign in.
8. The next screen that displays information about multi-factor authentication (MFA) is for added security and is
optional. You will see this screen if your work or school requires second-factor authentication for creating work
account. It provides instructions to further verify your account.
9. The Workplace Join screen displays the message, Joining your workplace. The Azure authenticator app is
attempting to join your device to your workplace.
10. You should see the Workplace Joined message on the next screen.
NOTE
You are allowed a single work account on your device.
Adding the work account from the settings menu

After you have installed the Azure Authenticator app, you can also create a work account from the Android Account
Manager.
1. From the Settings menu, navigate to Accounts and click Add Account.
2. Follow steps 3-10 in the procedure, Adding the work account through the app home screen, to add a work
account.
Adding the work account from a non-Samsung Android device

Adding the work account through the app home screen
1. On the home screen of the app, accept the end user license agreement (EULA).
2. On the Activate Account screen, click the context menu on the right and select Work account.
3. On the Accounts screen, click Add Account.
4. If you see the Accounts screen, click Add account. If a work account is already created previously, you will see a
Sync screen showing the existing work account. You can retain the work account by simply tapping the back
arrow to the home screen. Alternately, you can select the account to remove and recreate a new work account
On the Workplace Join screen, enter the userID provided by your organization and click Join.
5. To sign in to the Azure Authenticator app, enter your organizational account and password and click Sign in.
6. The next screen that displays information about multi-factor authentication (MFA) is for added security and is
optional. You will see this screen if your work or school requires second-factor authentication for creating work
account. It provides instructions to further verify your account.
7. Click OK on the next screen. Do not change the certificate name. the message, Joining your workplace. The
Azure authenticator app is attempting to join your device to your workplace. You should see the Workplace
Joined message on the next screen.
NOTE
You are allowed a single work account on your device.
After you have installed the Azure Authenticator app, you can also create a work account from the Android Account
Manager.
1. From the Settings menu, navigate to Accounts and click Add Account.
2. Follow steps 2-7 in the procedure, Adding the work account through the app home screen**, to add a work
account.
How to find out which version is installed
1. You can find out which version of the Azure Authenticator app and associated service versions are installed on
your device.
2. From the pop up menu, click About.
3. The About screen displays the services of the app and the versions installed on your device.
Sending log files to report issues
1. Follow the guidance on Microsoft Support to report an incident with the Azure Authenticator app, obtain an
incident number, and send log files against the assigned incident number as follows:
2. From the pop up menu, click Logging.
3. If you have an open incident with Microsoft Support, make note of the incident number (you'll need it for a later
step). If you have not already created a support incident and would like assistance, follow the guidance at
Microsoft Support to open a new incident.
4. On the logging screen, click Send Now.
5. Select the email provider you want to use.
6. If you already have an open incident Microsoft Support, contact the Support Engineer assigned to your issue to
find out how to send the log data and have it associated with your incident. The Support Engineer will provide
you with information for the email address and subject line. If you do not already have a support incident, please
follow the guidance at Microsoft Support to open a new incident.
7. Edit the To line and Subject line with the information you have received from Microsoft Support.
8. The Azure Authenticator app attaches the log file to the email you are sending. Describe the problem you are
experiencing, update recipient list (optional), and send the email.
Deleting the work account and leaving your workplace
You can remove the work account you created at any time as follows:
To delete the work account from the Settings menu
1. From the accounts manager, select Work account.
2. On the Work Account screen, in General Settings, select Account Settings Leave your workplace
network.
3. Select Leave on the Workplace Join screen.
4. Click OK when the message Are you sure you want to leave workplace is displayed.
5. This ensures that you have deleted your work account from your workplace.
NOTE
It is recommended that you do not use the Remove Account option to delete a work account as this option might not work
in some earlier versions of Android.
Uninstalling the app

On a Samsung Android device, device administrator privileges must be removed as follows prior to uninstalling the
1. From Settings, under System, select Security.
2. Within Device Administration, click Device administrators. Ensure that the check box next to Azure
Authenticator is cleared.
Troubleshooting
If you see the Keystore Error, this could be because you dont have the lock screen set up with a PIN. To work
around this issue, uninstall the Azure Authenticator app, configure a PIN for your lock screen, and reinstall the app.
Conditional access device policies for Office 365
services
The term, Conditional access has many conditions associated with it such as multi-factor authenticated user,
authenticated device, compliant device etc. This topic primarily focusses on device-based conditions to control
access to Office 365 services. While Information Workers (IWs) want to access Office 365 services like Exchange
and SharePoint Online at work or school from their personal devices, their IT admin wants the access to be secure.
IT admins can provision conditional access device policies to secure corporate resources, while at the same time
allowing IWs on compliant devices to access the services. Conditional access policies to Office 365 may be
configured from Microsoft Intune conditional access portal.
Azure Active Directory enforces conditional access policies to secure access to Office 365 services. A tenant admin
can create a conditional access policy that blocks a user on a non-compliant device from accessing an O365
service. The user must conform to companys device policies before access can be granted to the service.
Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an
O365 service. Policies may be applied to all users of an organization, or limited to a few target groups and
enhanced over time to include additional target groups.
A prerequisite for enforcing device policies is for users to register their devices with Azure Active Directory Device
Registration service. You can opt to enable Multi-factor authentication (MFA) for registering devices with Azure
Active Directory Device Registration service. MFA is recommended for Azure Active Directory Device Registration
service. When MFA is enabled, users registering their devices with Azure Active Directory Device Registration
service are challenged for second factor authentication.
How does conditional access policy work?

When a user requests access to O365 service from a supported device platform, Azure Active Directory
authenticates the user and device from which the user launches the request; and grants access to the service only
when the user conforms to the policy set for the service. Users that do not have their device enrolled are given
remedial instructions on how to enroll and become compliant to access corporate O365 services. Users on iOS and
Android devices will be required to enroll their devices using Company Portal application. When a user enrolls
his/her device, the device is registered with Azure Active Directory, and enrolled for device management and
compliance. Customers must use the Azure Active Directory Device Registration service in conjunction with
Microsoft Intune to enable mobile device management for Office 365 service. Device enrollment is a pre-requisite
for users to access Office 365 services when device policies are enforced.
When a user enrolls his/her device successfully, the device becomes trusted. Azure Active Directory provides
Single-Sign-On to access company applications and enforces conditional access policy to grant access to a service
not only the first time the user requests access, but every time the user requests to renew access. The user will be
denied access to services when sign-in credentials are changed, device is lost/stolen, or the policy is not met at the
time of request for renewal.
Deployment Considerations:
Must use Azure Active Directory Device Registration service for device registration.
When users are to be authenticated on premises, Active Directory Federation Services (AD FS) (1.0 and above) is
required. Multi-Factor Authentication for Workplace Join will fail when the identity provider is not capable of multi-
factor authentication. For example, AD FS 2.0 is not multi-factor authentication-capable. Tenant admin must ensure
that the on-premises AD FS is MFA capable and a valid MFA method is enabled, before enabling MFA on Azure
Active Directory Device Registration service. For example, AD FS on Windows Server 2012 R2 has MFA capabilities.
You must also enable an additional valid authentication (MFA) method on the AD FS server before enabling MFA
on Azure Active Directory Device Registration service. For more information on supported MFA methods in AD FS,
see Configure Additional Authentication Methods for AD FS.
Frequently Asked Questions (FAQ)

Q: What is the default exclusion policy for unsupported device platforms?
A: At the present time, conditional access policies are selectively enforced on users on iOS and Android devices.
Applications on other device platforms are, by default, unaffected by the conditional access policy for iOS and
Android devices. Tenant admin may, however, choose to override the global policy to disallow access to users on
unsupported platforms. It is on the roadmap to extend conditional access policy to users on other platforms,
including Windows.
Q: When will conditional access policy to Office 365 services be extended to Browser based apps (for example,
OWA, browser-based SharePoint).
A: At the present time, conditional access to Office365 services is limited to rich applications on device. It is on the
roadmap to extend conditional access policy to users accessing the services from browsers.
Set device-based conditional access policy for Azure
Active Directory-connected applications
Azure Active Directory (Azure AD) device-based conditional access can help you protect organization resources
from:
Access attempts from unknown or unmanaged devices.
Devices that dont meet the security policies of your organization.
For an overview of conditional access, see Azure Active Directory conditional access.
You can set device-based conditional access policies to protect these applications:
Office 365 SharePoint Online, to protect your organization's sites and documents
Office 365 Exchange Online, to protect your organization's email
Software as a service (SaaS) applications that are connected to Azure AD for authentication
On-premises applications that are published by using Azure AD Application Proxy services
To set a device-based conditional access policy, in the Azure portal, go to the specific application in the directory.
Select the application, and then click the Configure tab to set the conditional access policy.
To set a device-based conditional access policy, in the Device based access rules section, in Enable Access
Rules, select On.
A device-based conditional access policy has three components:
Apply To. The scope of users the policy applies to.
Device Rules. The conditions a device must meet before it can access the application.
Application Enforcement. The client applications (native versus browser) the policy applies to.
Select the users the policy applies to

In the Apply To section, you can select the scope of users this policy applies to.
You have two options when you create an access policy scope for users:
All Users. Apply the policy to all users who access the application.
Groups. Limit the policy to users who are a member of a specific group.
To exclude a user from a policy, select the Except check box. This is helpful when you need to give permissions to a
specific user to temporarily access the application. Select this option, for example, if some of your users have
devices that are not ready for conditional access. The devices might not be registered yet, or they are about to be
out of compliance.
Select the conditions that devices must meet

Use Device Rules to set the conditions a device must meet to access the application.
You can set device-based conditional access for these device types:
Windows 10 Anniversary Update, Windows 8.1, and Windows 7
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2
iOS devices (iPad, iPhone)
Android devices
Support for Mac is coming soon.
NOTE
For information about the differences between domain-joined and Azure AD-joined devices, see Using Windows 10 devices
in your workplace.
You have two options for device rules:

All devices must be compliant. All device platforms that access the application must be compliant. Devices
that run on platforms that don't support device-based conditional access are denied access.
Only selected devices must be compliant. Only specific device platforms must be compliant. Other
platforms, or other platforms that can access the application, have access.
Azure AD-joined devices are compliant if they are marked as compliant in the directory by Intune or by a third-
party mobile device management system that integrates with Azure AD.
A domain-joined device is compliant if:
It is registered with Azure AD. Many organizations treat domain-joined devices as trusted devices.
It is marked as compliant in Azure AD by System Center Configuration Manager.
Windows personal devices are compliant if they are marked as compliant in the directory by Intune or by a third-
party mobile device management system that integrates with Azure AD.
Non-Windows devices are compliant if they are marked as compliant in the directory by Intune.
NOTE
For more information about how to set up Azure AD for device compliance in different management systems, see Azure
Active Directory conditional access.
You can select one or multiple device platforms for a device-based access policy. This includes Android, iOS,
Windows Mobile (Windows 8.1 phones and tablets), and Windows (all other Windows devices, including all
Windows 10 devices). Policy evaluation occurs only on the selected platforms. If a device that attempts access is not
running one of the selected platforms, the device can access the application if the user has access. No device policy
is evaluated.
Set policy evaluation for a type of application

In the Application Enforcement section, set the type of applications the policy will evaluate for user or device
access.
You have two options for the type of application to include:
Browser and native applications
Native applications only
To enforce access policy for applications, select For browser and native applications. Then, you can include:
Browsers (for example, Microsoft Edge in Windows 10 or Safari in iOS).
Applications that use the Active Directory Authentication Library (ADAL) on any platform, or that use the
WebAccountManager (WAM) API in Windows 10.
NOTE
For more information about browser support and other considerations for a user who is accessing a device-based, certificate
authority-protected application, see Azure Active Directory conditional access.
Help protect email access from Exchange ActiveSync-based

applications
In Office 365 Exchange Online applications, you can use Exchange ActiveSync to block email access to Exchange
ActiveSync-based mail applications.
Next steps
Setting up on-premises conditional access using
Azure Active Directory Device Registration
Personally owned devices of your users can be marked known to your organization by requiring the users to work
place join their devices to the Azure Active Directory Device Registration service. Below is a step-by-step guide to
enable conditional access to on-premises applications using Active Directory Federation Service (AD FS) in
Windows Server 2012 R2.
NOTE
Office 365 license or Azure AD Premium license is required when using devices registered in Azure Active Directory Device
Registration service conditional access policies. This includes policies enforced by Active Directory Federation Services (AD FS)
to on-premises resources.
For more information on the conditional access scenarios for on-premises, see Join to Workplace from Any Device
for SSO and Seamless Second Factor Authentication Across Company Applications.
These capabilities are available to customers that 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 Safari browser
Android 4.0 or later, Samsung GS3 or above phones, Samsung Note2 or above 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 above)
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 here.
Verified domain.
Known issues in this release

Device based conditional access policies require device object write-back to Active Directory from Azure Active
Directory. It can take up to 3 hours for device objects to be written-back to Active Directory
iOS 7 devices will always prompt the user to select a certificate during client certificate authentication.
Some versions of iOS8, 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 a on-premises
Active Directory. These tenants should be connected using Azure AD Connect and with a verified domain and AD
FS for SSO. The checklist below will help you configure your environment to the stage described above.
Checklist: Prerequisites for Conditional Access scenario

Connect your Azure AD tenant with your on-premises Active Directory.
Configure Azure Active Directory Device Registration Service

Use this guide to deploy and configure Azure Active Directory Device Registration Service for your organization.
This guide assumes that you have configured Windows Server Active Directory and have subscribed to Microsoft
Azure Active Directory. See prerequisites above.
To deploy 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 after you review the conceptual topic so that you can proceed with the remaining tasks in this checklist.
Some tasks will include a scenario validation step that can help you confirm the step was completed successfully.
Part 1: Enable Azure Active Directory Device Registration

Follow the checklist below 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,
multi-factor authentication is not enabled for the service.
However, multi-factor authentication is recommended when
registering a device. Before enabling multi-factor
authentication in ADRS, ensure that AD FS is configured for a
multi-factor authentication provider.
Devices will discover your Azure Active Directory Device Configure Azure Active Directory Device Registration
Registration Service by looking for well-known DNS records. discovery.
You must 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 domain with the Upgrade your Active Directory Domain Services Schema
Windows 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 will discover your Azure Active Directory Device Prepare your Active Directory support devices
Registration Service by looking for well-known DNS records.
You must 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 2 of Enabling device writeback in Azure AD Enabling device writeback in Azure AD Connect
Connect. Upon completion, return this this guide.
[Optional] Part 4: Enable multi-factor authentication

It is strongly recommended that you configure one of the several options for multi-factor authentication. If you
want to require MFA, see Choose the multi-factor 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. You can now try out some scenarios. Follow the links below to experiment with
the service and become familiar with the features
TASK REFERENCE
Join some devices to your workplace using Azure Active Join devices to your workplace using Azure Active Directory
Directory Device Registration. You can join iOS, Windows, and Device Registration
Android devices
You can view and enable/disable registered devices using the Azure Active Directory Device Registration Overview
Administrator Portal. In this task you will view some registered
devices 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 will create an application access rule
and a custom access denied message
Integrate Azure Active Directory with on-premises Active Directory

This will help you integrate your Azure AD tenant with your on-premises active directory, using Azure AD Connect.
Although the steps are available in the Azure classic portal, make note of any special instructions listed in this
section.
1. Log on to the Azure classic portal using an account that is a Global Administrator in Azure AD.
4. Select the Directory Integration tab.
5. Under deploy and manage section, follow the steps 1 through 3 to integrate Azure Active Directory with
your on-premises directory.
a. Add domains.
b. Install and run Azure AD Connect: Install Azure AD Connect using the following instructions, Custom
installation of Azure AD Connect.
c. Verify and manage directory sync. Single sign-on instructions are available within this step.
NOTE
Configure Federation with AD FS as outlined in the document linked above. You do not need to configure any of the
preview features.
Upgrade your Active Directory Domain Services schema

NOTE
Upgrading your Active Directory schema cannot be reversed. It is recommended that you first perform this in a test
environment.
1. Log in to your domain controller with an account that has both Enterprise Admin and Schema Admin rights.
2. Copy the [media]\support\adprep directory and sub-directories to one of your Active Directory domain
controllers.
3. Where [media] is the path to the Windows Server 2012 R2 installation media.
4. From a command prompt, navigate to the adprep directory and execute: 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. You must be
logged on with enterprise administrator permissions and your Active Directory forest must have the Windows Server 2012
R2 schema to complete this procedure.
Prepare your Active Directory forest to support devices

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

1. On your federation server, open a Windows PowerShell command window and 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 is 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 navigate to AD FS > Authentication
Policies.
2. Select Edit Global Primary Authentication from the Actions pane.
3. Check Enable device authentication and then selectOK.
4. By default, AD FS will periodically remove unused devices from Active Directory. You must disable this task
when using Azure Active Directory Device Registration so that devices can be managed in Azure.
Disable unused device cleanup
1. On your federation server, open a Windows PowerShell command window and type: Set-
AdfsDeviceRegistration -MaximumInactiveDays 0
Prepare Azure AD Connect for device writeback
1. Complete Part 1: Prepare Azure AD Connect.
Join devices to your workplace using Azure Active Directory Device

Registration
Join an iOS device 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 with the user connecting to the profile enrollment URL using the Safari web browser. The URL
format is as follows:
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/"yourdomainname"
Where yourdomainname is the domain name that you have configured with Azure Active Directory. For example, if
your domain name is contoso.com, the URL would be:
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/contoso.com
There are many different ways to communicate this URL to your users. One recommended way is to publish this
URL in a custom application access denied message in AD FS. This is covered in the upcoming section: Create an
application access policy and custom access denied message.
Join a Windows 8.1 device using Azure Active Directory Device Registration
1. On your Windows 8.1 device, navigate to 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 using Azure Active Directory Device Registration
To register Windows 7 domain joined devices you need to deploy the device registration software package. The
software package is called Workplace Join for Windows 7 and is available for download at the Microsoft Connect
website. Instructions how to use the package are available at Configure automatic device registration for Windows
7 domain joined devices.
Join an Android device using Azure Active Directory Device Registration
The Azure Authenticator for Android topic has instructions on how to install Azure authenticator app on your
Android device and add a work account. When a work account is created successfully on an Android device, that
device is workplace joined to the organization.
Verify 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 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 will be 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 on how to join their device. Now your users have a seamless way to
register their devices in order to access an application.
The following steps will 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 navigate to AD FS > Trust Relationships > Relying Party Trusts.
2. Locate the application for which this new access rule will apply. Right-click the application and 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.
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 just created. For example, remove the default
Permit Access to all Users rule.
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 Multi-Factor Access Control.
Next, you will configure a custom error message for your application. The error message will let users know that
they must join their device to the workplace before they are allowed access to the application. You can create a
custom application access denied message using custom HTML and Windows PowerShell.
On your federation server, open a Windows PowerShell command window and 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 going to PC Settings **> **Network >
Workplace.
Where "relying party trust name" is the name of your applications Relying Party Trust object in AD FS. Where
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 is not registered with the Azure Active Directory Device
Registration Service, they will receive a page that looks similar to the screen shot below.
Related Articles
Azure Active Directory Conditional Access FAQ
Which applications work with conditional access policies?

A: Please see the topic, Conditional access- What applications are supported.
Are conditional access policies enforced for B2B collaboration and

guest users?
A: Policies are enforced for B2B collaboration users. However, in some cases, a user might not be able to satisfy the
policy requirement if, for example, an organization does not support multi-factor authentication.
The policy is currently not enforced for SharePoint guest users. The guest relationship is maintained within
SharePoint. Guest users accounts are not subject to access polices at the authentication server. Guest access can be
managed at SharePoint.
Does a SharePoint Online policy also apply to OneDrive for Business?

A: Yes.
Why cant I set a policy on client apps, like Word or Outlook?

A: A conditional access policy sets requirements for accessing a service and is enforced when authentication
happens to that service. The policy is not set directly on a client application; instead, it is applied when it calls into a
service. For example, a policy set on SharePoint applies to clients calling SharePoint and a policy set on Exchange
applies to Outlook.
Does a conditional access policy apply to service accounts?

A: Conditional access policies apply to all user accounts. This includes user accounts used as service accounts. In
many cases, a service account that runs unattended is not able to satisfy a policy. This is, for example the case, when
MFA is required. In these cases, services accounts can be excluded from a policy, using conditional access policy
management settings. Learn more about applying a policy to users here.
Troubleshooting for Azure Active Directory access
issues
You try to access your organization's SharePoint Online intranet, and you get an "access denied" error message.
What do you do?
This article covers remediation steps that can help you resolve access issues with your organization's online
resources.
For help resolving Azure Active Directory (Azure AD) access issues, go to the section in the article that covers your
device platform:
Windows device
iOS device (Check back soon for assistance with iPhones and iPads.)
Android device (Check back soon for assistance with Android phones and tablets.)
Access from a Windows device

If your device runs one of the following platforms, look in the next sections for the error message that is shown
when you try to access an application or service:
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows Server 2016
Windows Server 2012
Device is not registered
If your device is not registered with Azure AD and the application is protected with a device-based policy, you might
see a page that shows one of these error messages:
If your device is domain-joined to Active Directory in your organization, try this:
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. Enter your work account credentials to unlock your Windows session.
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.
If your device is not domain-joined 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.
To run Azure AD Join, do the following steps for the platform your device runs on. (Azure AD Join is not available
on Windows phones.)
Windows 10 Anniversary Update
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
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).
To add your work or school account, do the following steps:
Windows 10 Anniversary Update
2. Click Accounts > Access work or school.
3. Click Connect.
that are shown.
Windows 10 November 2015 Update
2. Click Accounts > Your accounts.
3. Click Add work or school account.
that are shown.
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.
Browser is not supported
You might be denied access if you are trying to access an application or service by using one of the following
browsers:
Chrome, Firefox, or any other browser other than Microsoft Edge or Microsoft Internet Explorer in Windows 10
or Windows Server 2016
Firefox in Windows 8.1, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008
R2
You'll see an error page that looks like this:
The only remediation is to use a browser that the application supports for your device platform.
Next steps
Azure Active Directory Conditional Access technical
reference
Services enabled with conditional access

Conditional Access rules are supported across various Azure AD application types. This list includes:
Federated applications from the Azure AD application gallery
Password SSO applications from the Azure AD application gallery
Applications registered with the Azure Application Proxy
Developed line of business and multi-tenant applications registered with Azure AD
Visual Studio Online
Azure Remote App
Dynamics CRM
Microsoft Office 365 Yammer
Microsoft Office 365 Exchange Online
Microsoft Office 365 SharePoint Online (includes OneDrive for Business)
Enable access rules

Each rule can be enabled or disabled on a per application bases. When rules are ON they will be enabled and
enforced for users accessing the application. When they are OFF they will not be used and will not impact the users
sign in experience.
Applying rules to specific users

Rules can be applied to specific sets of users based on security group by setting Apply To. Apply To can be set to
All Users or Groups. When set to All Users the rules will apply to any user with access to the application. The
Groups option allows specific security and distribution groups to be selected, rules will only be enforced for these
groups.
When deploying a rule, it is common to first apply it a limited set of users, that are members of a piloting groups.
Once complete the rule can be applied to All Users. This will cause the rule to be enforced for all users in the
organization.
Select groups may also be exempted from policy using the Except option. Any members of these groups will be
exempted even if they appear in an included group.
At work networks
Conditional access rules that use an At work network, rely on trusted IP address ranges that have been
configured in Azure AD, or use of the "inside corpnet" claim from AD FS. These rules include:
Require multi-factor authentication when not at work
Block access when not at work
Options for specifiying at work networks
1. Configure trusted IP address ranges in the multi-factor authentication configuration page. Conditional Access
policy will use the configured ranges on each authentication request and token issuance to evaluate rules.
2. Configure use of the inside corpnet claim, this option can be used with federated directories, using AD FS. Learn
more about the inside coronet claims.
3. Configure public IP address ranges. On the configure tab, for your directory, you can set public IP addresses.
Conditional Access will use these as at work IP addresses, this allows additional ranges to be configure, above
the 50 IP address limit that is enforced by the MFA setting page.
Rules based on application sensitivity

Rules are configured per application allowing the high value services to be secured without impacting access to
other services. Conditional access rules can be configured on the Configure tab of the application.
Rules currently offered:
Require multi-factor authentication
All users that this policy is applied to will be required to authenticate via multi-factor authentication at
least once.
Require multi-factor authentication when not at work
If this policy is applied, all users will be required to have performed multi-factor authentication at least
once if they access the service from a non-work remote location. If they move from a work to remote
location, they will be required to perform multifactor authentication when accessing the service.
Block access when not at work
When users move from work to a remote location, they will be blocked if the "Block access when not at
work" policy is applied to them. They will be re-allowed access when at a work location.
Related topics
Securing access to Office 365 and other apps connected to Azure Active Directory
Extending cloud capabilities to Windows 10 devices
through Azure Active Directory Join
What is Azure Active Directory Join?

Azure Active Directory Join (Azure AD Join) is the functionality that registers a company-owned device in Azure
Active Directory to enable centralized management of the device. It makes it possible for users such as employees
and students to connect to the enterprise cloud through Azure Active Directory. This enables simplified Windows
deployments and access to organizational apps and resources from any Windows device, both corporate-owned
and personally-owned (BYOD).
Azure AD Join is intended for enterprises that are cloud-first/cloud-only--typically small- and medium-sized
businesses that do not have an on-premises Windows Server Active Directory infrastructure. That said, Azure AD
Join can and will also be used by large organizations on devices that are incapable of doing a traditional domain
join (mobile devices, for example), or for users who primarily need to access Office 365 or other Azure AD SaaS
apps.
Although the traditional domain join still offers the best on-premises experience on devices that are capable of
domain joining, Azure AD Join is suitable for devices that cannot domain join. Azure AD Join is also suitable for
managing users in the cloud. It does so by using mobile device management capabilities instead of by using
traditional domain management tools like Group Policy and System Center Configuration Manager (SCCM).
Why should enterprises adopt Azure AD Join?

Businesses that are largely in the cloud: If you have moved or are moving to a model in which you are
reducing your on-premises footprint and want to operate more in the cloud, Azure AD Join could benefit you.
Maybe you have created Azure AD accounts manually or through synchronizing your on-premises Active
Directory. Either way, you have an account in Azure AD, and you can use it to sign in to Windows 10. Your users
can join their computers to Azure AD through either the out-of-box experience (OOBE) or through the Settings
menu. After joining, users will enjoy single sign-on (SSO) access to cloud resources like Office 365, either in
their browsers or in Office applications.
Educational institutions: One of the scenarios we hear about often is that educational institutions have two
user types: faculty and students. Faculty members are considered longer-term members of the organization, so
creating on-premises accounts for them is desirable. But students are shorter-term members of the
organization and thus can be managed in Azure AD. This means that directory scale can be pushed to the cloud
instead of stored on-premises. It also means that students can sign in to Windows with their Azure AD accounts
and get access to Office 365 resources, either in their browsers or in Office applications.
Retail businesses: Another scenario weve heard about from customers is their desire to manage seasonal
workers more easily. Again, accounts for longer-term, full-time employees are usually created as on-premises
accounts on domain-joined machines. But seasonal workers are shorter-term members of the org, so it's
desirable to manage them where user licenses can be more easily moved around. Creating these user accounts
in the cloud with Office 365 licenses allows the users to get the benefits of signing in to Windows and Office
applications with an Azure AD account. Meanwhile, you maintain more flexibility with their licenses after they
leave.
Other businesses: Even though you maintain users in your on-premises Active Directory, you could still benefit
from having users be Azure-AD-joined. That's because Azure AD offers a simplified joining experience, efficient
device management, automatic mobile device management enrollment, and single sign-on capability for Azure
AD and on-premises resources.
What capabilities does Azure AD Join offer?

With Azure AD Join, you get the following:
Self-provisioning of corporate-owned devices: With Windows 10, users can configure a brand new, shrink-
wrapped device in the out-of-box experience, without IT involvement.
Support for modern form factors: Azure AD Join works on devices that dont have the traditional domain join
capabilities.
Support for existing organizational accounts: Users no longer need to create and maintain a a personal
Microsoft account to get the best experience on company-issued devices, as they did with Windows 8. They can
use their existing work accounts in Azure AD instead. For many organizations, this basically means that users
can set up and sign in to Windows with the same credentials that they use to access Office 365.
Automatic mobile device management enrollment: Devices can be automatically enrolled in mobile device
management when connected to Azure AD. This process works with Microsoft Intune and partner mobile device
management solutions. When device management is done with Intune, IT administrators can monitor/manage
Azure AD-joined devices alongside domain-joined devices in the SCCM management console.
Single sign-on to company resources: Users enjoy single sign-on from the Windows desktop to apps and
resources in the cloud, such as Office 365 and thousands of business applications that rely on Azure AD for
authentication through Azure AD Connect. Corporate-owned devices that are joined to Azure AD also enjoy
SSO to on-premises resources when the device is on a corporate network, and from anywhere when these
resources are exposed via the Azure AD Application Proxy.
OS State Roaming: Accessibility settings, websites, Wi-Fi passwords, and other settings are synchronized
across corporate-owned devices without requiring a personal Microsoft account.
Enterprise-ready Windows Store: The Windows Store supports app acquisition and licensing with Azure AD
accounts. Organizations can volume-license apps and make them available to the users in their organization.
How do different devices work with Azure AD Join?

CORPORATE DEVICE (JOINED TO ON- CORPORATE DEVICE (JOINED TO THE
PREMISES DOMAIN) CLOUD) PERSONAL DEVICE
Users can sign into Windows with work Users can sign in to Windows with work Users sign in to Windows with their
credentials (as they do today). credentials that are managed in Azure personal Microsoft account credentials
AD. This is relevant for corporate (no change).
devices in three cases: 1)The
organization doesnt have Active
Directory on premises (for example, a
small business). 2)The organization
doesnt create all user accounts in
Active Directory (for example, accounts
for students, consultants, or seasonal
workers are not created in Active
Directory). 3)The organization has
corporate devices that cant be joined
to an (on-premises) domain, like
phones or tablets running a Mobile SKU
(for example, a secondary device taken
to a factory/retail floor). Azure AD Join
supports joining of corporate devices
for both managed and federated
organizations.
Users have access to roaming settings Users can do self-service setup. They Users can easily add a work account
and the enterprise Windows Store. can go through the first-run experience thats managed in Active Directory or
These services work with work accounts (FRX) via their work account as an Azure AD.
and don't require a personal Microsoft alternative to having IT provision the
account. This requires organizations to devices, although both methods are
connect their on-premises Active supported.
Directory to Azure AD.
Users have SSO ability from the Devices are automatically registered in Users have SSO ability across apps and
desktop to work apps, websites, and the enterprise directory (Azure AD) and to websites/resources with this work
resources--including both on-premises automatically enrolled in mobile device account.
resources and cloud apps that use management. (Azure AD Premium
Azure AD for authentication. feature).
Users can add their personal Microsoft Users can do a self-service password Users have access to the enterprise
accounts to access their personal reset (SSPR) on winlogon, meaning they Windows Store so that they can acquire
pictures and files without impacting can reset a forgotten password. (Azure and use line-of-business apps on their
enterprise data. (Roaming settings AD Premium feature). personal devices.
continue to work with their work
accounts.) The Microsoft account
enables SSO and no longer drives the
roaming of settings.
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
User tasks
Join a personal Windows 10 device to your organization
Setting up Azure AD Join in your organization
Before you set up Azure Active Directory Join (Azure AD Join), you need to either sync up your on-premises
directory of users to the cloud or manually create managed accounts in Azure AD.
Detailed instructions for syncing your on-premises users to Azure AD is covered in Integrating your on-premises
identities with Azure Active Directory.
To manually create and manage users in Azure AD, refer to User management in Azure AD.

1. Log on to the Azure portal as an administrator.
5. Go to the Devices section.
6. On the devices tab, set the following:
MAXIMUM NUMBER OF DEVICES PER USER: Select the maximum number of devices that a user can
have in Azure AD. If a user reaches this quota, they will not be able to add additional devices until one
or more of their existing devices are removed.
REQUIRE MULTI-FACTOR AUTH TO JOIN DEVICES: Set whether users are required to provide a
second authentication factor to join their device to Azure AD. For more information on Azure Multi-
Factor Authentication, see Getting started with Azure Multi-Factor Authentication in the cloud.
USERS MAY AZURE AD JOIN DEVICES: Select the users and groups that are allowed to join devices
to Azure AD.
ADDITIONAL ADMINISTRATORS ON AZURE AD JOINED DEVICES: With Azure AD Premium or the
Enterprise Mobility Suite (EMS), you can choose which users are granted local administrator rights to
the device. Global administrators and device owners are granted local administrator rights by default.
After you set up Azure AD Join for your users, they can connect to Azure AD through their corporate or personal
devices.
Following are the three scenarios you can use to enable your users to set up Azure AD Join:
Users join a company-owned device directly to Azure AD.
Users domain-join a company-owned device to the on-premises Active Directory and then extend the device
to Azure AD.
Users add work or school accounts to Windows on a personal device
Set up a new device with Azure AD during Setup
In Windows 10, users can join their devices to Azure Active Directory (Azure AD) in the first-run experience (FRX).
This allows organizations to distribute shrink-wrapped devices to their employees or students, or let them choose
their own devices (CYOD). If either Windows 10 Professional or Windows 10 Enterprise editions is installed on a
device, the experience defaults to the setup process for company-owned devices.
To join a device to Azure AD

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. Select whether you're using a personal device or a company-owned device. If it's company-owned, click This
device belongs to my organization. This starts the Azure AD Join experience. Following is a screen that you'll
see if you're using Windows 10 Professional.
5. Enter the credentials that were provided to you by your organization.

6. After you have entered your user name, a matching tenant is located in Azure AD. If you are in a federated
domain, you will be 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. If
company branding was configured, you will also see your organizations logo and support text.
8. You're prompted for a multi-factor authentication challenge. This challenge is configurable by an IT
administrator.
9. Azure AD checks whether this user/device requires enrollment in mobile device management.
10. Windows registers the device in the organizations directory in Azure AD and enrolls it in mobile device
management, if appropriate.
11. If you are a managed user, Windows takes you to the desktop through the automatic sign-in process.
12. If you are a federated user, you are directed to the Windows sign-in screen to enter your credentials.
NOTE
Joining an on-premises Windows Server Active Directory domain in the Windows out-of-box experience is not supported.
Therefore, if you plan to join a computer to a domain, you should select the link Set up Windows with a local account
instead. You can then join the domain from the settings on your computer as youve done before.
Connect domain-joined devices to Azure AD for
Windows 10 experiences
Domain join is the traditional way organizations have connected devices for work for the last 15 years and
more. It has enabled users to sign in to their devices by using their Windows Server Active Directory (Active
Directory) work or school accounts and allowed IT to fully manage these devices. Organizations typically rely on
imaging methods to provision devices to users and generally use System Center Configuration Manager
(SCCM) or Group Policy to manage them.
Domain join in Windows 10 will provide the following benefits after you connect devices to Azure Active
Directory (Azure AD):
Single sign-on (SSO) to Azure AD resources from anywhere
Access to the enterprise Windows Store by using work or school accounts (no Microsoft account required)
Enterprise-compliant roaming of user settings across devices by using work or school accounts (no
Microsoft account required)
Strong authentication and convenient sign-in for work or school accounts with Microsoft Passport and
Windows Hello
Ability to restrict access only to devices that comply with organizational device Group Policy settings
Prerequisites
Domain join continues to be useful. However, to get the Azure AD benefits of SSO, roaming of settings with
work or school accounts, and access to Windows Store with work or school accounts, you will need the
following:
Azure AD subscription
Azure AD Connect to extend the on-premises directory to Azure AD
Policy that's set to connect domain-joined devices to Azure AD
Windows 10 build (build 10551 or newer) for devices
To enable Microsoft Passport for Work and Windows Hello, you will also need the following:
Public key infrastructure (PKI) for user certificates issuance.
System Center Configuration Manager version 1509 for Technical Preview. For more information, see
Microsoft System Center Configuration Manager Technical Preview and System Center Configuration
Manager Team Blog. This is required to deploy user certificates based on Microsoft Passport keys.
As an alternative to the PKI deployment requirement, you can do the following:
Have a few domain controllers with Windows Server 2016 Active Directory Domain Services.
To enable conditional access, you can create Group Policy settings that allow access to domain-joined devices
with no additional deployments. To manage access control based on compliance of the device, you will need the
following:
System Center Configuration Manager version 1509 for Technical Preview for Passport scenarios
Deployment instructions
To deploy, follow the steps listed in How to configure automatic registration of Windows domain-joined devices
with Azure Active Directory
Authenticating identities without passwords through
Microsoft Passport
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 Microsoft Passport

Microsoft Passport 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.
Microsoft Passport 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 Microsoft Passport enrollment, Microsoft
Passport 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 Microsoft Passport 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 Microsoft Passport

By enabling Microsoft Passport, enterprises can make their resources even more secure by:
Setting up Microsoft Passport 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 Microsoft Passport to support smart card-like scenarios by using certificate-based trust.
How Microsoft Passport 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 Microsoft Passport 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 Microsoft Passport credentials for their users.
The deployment requirements for Microsoft Passport

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 Microsoft Passport for work 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 dont have one, or you dont 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
Windows 10 for the enterprise: Ways to use devices
for work
Windows 10 gives you the ability to leverage Azure Active Directory (Azure AD). You can connect Windows 10
devices to Azure AD so that users can sign in to Windows by using Azure AD accounts or by adding their Azure
IDs to gain access to business apps and resources.
Integrating Windows 10 devices with Azure Active Directory--a

content map
The following topics provide insights into different capabilities of Windows 10 devices in your organization.
TOPICS
Getting started Using Windows 10 devices in your workplace
Extending cloud capabilities to Windows 10 devices through

Azure Active Directory Join
Authenticating identities without passwords through

Microsoft Passport
Deployment Usage scenarios and deployment considerations for Azure

AD Join
Connecting domain-joined devices to Azure AD, for Windows

10 experiences
Enabling Microsoft Passport for work in the organization
Enabling Enterprise State Roaming for Windows 10

TOPICS
User tasks Setting up a new Windows 10 device with Azure AD during

setup
Setting up a Windows 10 device with Azure AD from the

settings menu
Joining a personal Windows 10 device to your organization

Using Windows 10 devices in your workplace
Applies to: Windows 10 PCs

Windows 10 offers three models for organizations that enable users to access work resources in a secure and
convenient way.
Azure Active Directory Join (Azure AD Join), for workers who access resources such as Office 365 primarily
in the cloud. Azure AD Join is self-service work provisioning experience that's new in Windows 10.
Domain join, for organizations that have investments in on-premises apps and resources. Domain join offers
an improved experience in Windows 10 when connected to Azure AD.
A new simplified BYOD experience, for users who want to add a work account or school to Windows and
easily access resources on personal devices.
The following table presents a snapshot of capabilities for users and IT administrators, contrasting the different
ways a device can be provisioned and used in an enterprise with Windows 10:
DOMAIN JOIN AZURE AD JOIN PERSONAL DEVICE
Windows device sign-in for Yes Yes No

work or school accounts.
User single-sign-on (SSO) to Yes Yes Yes

Office 365 and Azure AD
apps. SSO is the ability to
sign in just once to access
organizational resources.
User SSO to Kerberos/NTLM Yes Limited Yes, via VPN

apps.
Strong authorization and Yes Yes Yes

convenient sign-in for work
or school accounts with
Microsoft Passport and
Windows Hello.
Access to enterprise Yes Yes Yes

Windows Store with a work
or school account (not a
Microsoft account).
Enterprise-compliant Yes Yes Yes

roaming of user settings
across devices with work or
school accounts.
The ability to restrict access Yes Yes Yes

to organizational apps to
devices that are compliant
with organizational device
policies.
DOMAIN JOIN AZURE AD JOIN PERSONAL DEVICE
User self-service No Yes Yes

provisioning of devices for
"work from anywhere."
Ability to manage devices. Yes, via GP/SCCM Yes Yes
Use work-owned devices with Azure AD Join and domain join in

Windows 10
Windows 10 offers two ways for work-owned devices to access work resources:
Azure AD Join
Domain join
Both can be valid options depending on an organization's needs and requirements. In some cases,
organizations might benefit from enabling both methods of deployment.
When to use Azure Active Directory Join

Azure AD Join is a new self-service work provisioning experience in Windows 10. It is targeted at workers who
access work resources such as Office 365 primarily in the cloud. It is a lightweight way to configure computers,
tablets, and phones for the enterprise. Devices are managed via mobile device management, by using consistent
controls across Windows platforms.
Use Azure AD Join for any of these reasons:
You want to enable the self-service provisioning of devices for workers on the go.
You provide users with work-owned mobile devices like tablets and phones.
You want to manage a set of users in Azure AD instead of in Active Directory, such as seasonal workers,
contractors, or students.
You want to provide joining capabilities to workers in remote branch offices with limited on-premises
infrastructure.
You do not have an on-premises Active Directory.
Some organizations will use Azure AD Join as the primary way to deploy work-owned devices, especially as they
migrate most or all of their resources to the cloud. Hybrid organizations with both Active Directory and Azure AD
can also choose to deploy one method or another depending on the user or department.
School districts and universities, for example, might manage staff in Active Directory and students in Azure AD.
Some companies might want to manage remote offices or sales departments in Azure AD. Both Azure AD Join and
domain join methods can be used within a hybrid organization. Azure AD Join can be a great complement to
domain join for deploying devices in a work environment.
If the most usual access to enterprise resources is via the cloud, your organization might enjoy
additional benefits if:
You can remove dependencies on on-premises identity infrastructure.
You can simplify your devices deployment model, getting away from imaging solutions by allowing self-service
configuration.
You can use mobile device management to manage all your devices across different platforms.
For more information about Azure AD Join, see Extending cloud capabilities to Windows 10 devices through Azure
Active Directory Join.
When to use domain join (or keep using it)
For the last 15 years, many organizations have used domain join to connect work devices. It enables users to sign
in to their devices with their Active Directory work or school accounts. Domain join also allows IT to centrally and
fully manage these devices. Organizations typically rely on imaging methods to provision devices, and often use
System Center Configuration Manager (SCCM) or Group Policy (GP) to manage them.
Your enterprise should use domain join (or keep using it) for any of these reasons:
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.
Domain join in Windows 10 also gives you the following benefits when connected to Azure AD:
Strong device-bound authentication and convenient sign-in for work or school accounts with Microsoft
Passport and Windows Hello.
Access to the enterprise Windows Store for devices that use work or school accounts (no Microsoft account
required).
Enterprise-compliant roaming of user settings across devices that use work or school accounts (no Microsoft
account required).
The ability to restrict access to organizational apps to devices that are compliant with organizational device
policies.
For more information about Azure AD Join, see Extending cloud capabilities to Windows 10 devices through Azure
Active Directory Join.
Enable joining of personally-owned devices for work or school

To support BYOD in the enterprise, Windows 10 gives the user the ability to add a work or school account to their
computer, tablet, or phone. After the user adds a work or school account, the device is registered with Azure AD
and optionally enrolled in the mobile device management system that the organization has configured. The
directory will show these devices as Registered vs. Azure AD joined. IT administraors can apply different policies
based on this information, providing a lighter touch on personally-owned devices than on work-owned devices if
desired.
Users can add a work or school account to their personal device very conveniently. They can do this when
accessing a work application for the first time, or they can do it manually via the Settings menu. This account will
provide SSO to organizational resources.
For more information about Azure AD Join, see Connect domain-joined devices to Azure AD for Windows 10
experiences.
Enable domain join or Azure AD Join

All methods described earlier (domain join, Azure AD Join, and Add work or school account) have entry points in
the Windows 10 user experience. However, all require an IT administrator to enable the functionality in the
infrastructure before the experience will work.
Requirements for deploying Azure AD Join

To deploy Azure AD Join for any set of users you need the following:
An Azure AD subscription.
An Azure AD Premium subscription, such as mobile device management auto-enrollment, if you require more
capabilities.
Mobile device management--for example, a Microsoft Intune subscription, mobile device management for
Office 365, or any of the partner mobile device management vendors that integrate with Azure AD. (See the
FAQ section near the end of this article for more information).
If your facilities are hybrid, we highly recommended that you deploy Azure AD Connect to extend the on-premises
directory to Azure AD.
Requirements for using domain join with Azure AD

Domain join continues to work as it always has. However, to get the Azure AD benefits you will need the following:
A deployment of Azure AD Connect to extend the on-premises directory to Azure AD.
A policy that allows domain-joined devices to have conditional access to Azure AD.
A policy that allows access to "domain-joined" devices if you want to be able to restrict access for some devices.
System Center Configuration Manager version 1509 for Technical Preview, to enable rules for requiring
compliant devices. (See the TechNet documentation and blog post).
For more information about domain join in Windows 10, see Connect domain-joined devices to Azure AD for
Windows 10 experiences
Requirements for using BYOD and "Add a work or school account"

To enable "bring your own device" (BYOD) with work or school accounts, you need the following:
An Azure AD Premium subscription, such as mobile device management auto-enrollment, if you require more
capabilities.
Requirements for using Microsoft Passport

To enable Microsoft Passport, you will need the following:
A public key infrastructure (PKI) for certificate-based authentication support that uses Microsoft Passport.
An Intune subscription for certificate-based authentication support that uses Microsoft Passport for Azure AD
Join and work or school accounts.
System Center Configuration Manager version 1509 for Technical Preview (see the TechNet documentation and
blog post) for certificate-based authentication support that uses Microsoft Passport for domain join.
A policy for enabling Microsoft Passport in the organization.
As an alternative to using a PKI, you can enable key-based Microsoft Passport by doing the following:
Deploy Windows Server 2016 "Production Preview 1" DCs (no need for domain or forest functional levels;
several DCs for redundancy serving each Active Directory site will suffice).
Set policy to enable Microsoft Passport in the organization.
For more information about Microsoft Passport and Windows Hello in Windows 10, see .
Frequently asked questions

Which partner mobile device management products integrate with Azure AD?
The following vendor products integrate with Azure AD for unified enrollment and conditional access in Windows
10:
AirWatch by VMware
Citrix Xenmobile
Lightspeed Mobile Manager
SOTI on-premises mobile device management
MobileIron
What about Workplace Join in Windows 10?
Workplace Join was used in Windows 8.1 to enable BYOD. In Windows 10, BYOD is enabled via "Add a work or
school account" as explained earlier in this document. For organizations that dont integrate their mobile device
management with Azure AD, users can enroll the device into management manually via Settings > Accounts >
Work access.
Can users connect their Microsoft account to their domain account in Windows 10?
Not in Windows 10. In Windows 8.1, users of domain-joined devices could connect their Microsoft account (for
example, Hotmail, Live, Outlook, Xbox, etc.) to their domain account to enable certain experiences like SSO to Live
services, use of the Windows Store, and roaming of user settings across devices. In Windows 10, the Microsoft
account "connect" functionality has been retired. The user can add one or more Microsoft accounts as additional
accounts to enable SSO to consumer services such as the Windows Store. This is done in Settings > Accounts >
Your account.
Users who are upgrading from Windows 8.1 domain-joined devices, and who had their Microsoft account
connected, will automatically have their connected Microsoft account added to the list of additional accounts they
use.
Get started with certificate based authentication on
Android
This topic shows you how to configure and utilize certificate based authentication (CBA) on an Android device for
users of tenants in Office 365 Enterprise, Business, and Education plans.
CBA enables you to be authenticated by Azure Active Directory with a client certificate on an 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.
Supported scenarios and requirements

General requirements
For all scenarios in this topic, the following tasks are required:
Access to certificate authority(s) to issue client certificates.
The certificates authority(s) must be configured in Azure Active Directory. You can find detailed steps on how to
complete the configuration in the Getting Started section.
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.
The client certificate must be issued for client authentication.
For Exchange ActiveSync clients only, the client certificate must have the users 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.
Office mobile applications support
APPS SUPPORT
Word / Excel / PowerPoint
OneNote
OneDrive
Outlook
Yammer
Skype for Business

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.
Getting started
To get started, you need to configure the 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
Below is the schema for a certificate authority:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
To upload the information, you can use the Azure AD module through Windows PowerShell.
Below are examples for adding, removing or modifying a certificate authority.
Configuring your Azure AD tenant for certificate based authentication
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
3. Connect to your target tenant:
Connect-AzureAD
Adding a new certificate authority

1. Set various properties of the certificate authority and add it to Azure Active Directory:
$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-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
2. Get the Certificate Authorities:
Get-AzureADTrustedCertificateAuthority
Retrieving the list certificate authorities

Retrieve the certificate authorities currently stored in Azure Active Directory for your tenant:
Removing a certificate authority

1. Retrieve the certificate authorities:
$c=Get-AzureADTrustedCertificateAuthority
2. Remove the certificate for the certificate authority:
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]
Modfiying a certificate authority

2. Modify properties on the certificate authority:
$c[0].AuthorityType=1
3. Set the Certificate Authority:
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
Testing Office mobile applications

To test certificate authentication on your mobile Office application:
1. On your test device, install an Office mobile application (e.g. OneDrive) from the Google Play Store.
2. Verify that the user certificate has been provisioned to your test device.
3. Launch the application.
4. Enter your user name, and then pick the user certificate you want to use.
You should be successfully signed in.
Testing Exchange ActiveSync client applications

To access Exchange ActiveSync via certificate based authentication, an EAS profile containing the client certificate
must be available to application. The EAS profile must contain the following information:
The user certificate to be used for authentication
The EAS endpoint must be outlook.office365.com (as this feature is currently supported only in the Exchange
online multi-tenant environment)
An EAS profile can be configured and placed on the device through the utilization of an 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 with an application on Android 5.0 (Lollipop) or later, perform the steps below:
1. Configure an EAS profile in the application that satisfies the requirements above.
2. Once the profile is properly configured, open the application, and verify that mail is synchronizing.
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.
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).
Get started with certificate based authentication on
iOS
This topic shows you how to configure and utilize certificate based authentication (CBA) on an iOS device for users
of tenants in Office 365 Enterprise, Business, and Education plans.
CBA enables you to be authenticated by Azure Active Directory with a client certificate on an 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.
Supported scenarios and requirements

General requirements
For all scenarios in this topic, the following tasks are required:
Access to certificate authority(s) to issue client certificates.
The certificates authority(s) must be configured in Azure Active Directory. You can find detailed steps on how to
complete the configuration in the Getting Started section.
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.
The client certificate must be issued for client authentication.
For Exchange ActiveSync clients only, the client certificate must have the users 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.
Office mobile applications support
APPS SUPPORT
Word / Excel / PowerPoint
OneNote
OneDrive
Outlook
Yammer
Skype for Business Coming soon

Requirements
The device OS version must be iOS 9 and above
A federation server must be configured.
Azure 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 Azure 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.
Getting started
To get started, you need to configure the 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
Below is the schema for a certificate authority:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
To upload the information, you can use the Azure AD module through Windows PowerShell.
Below are examples for adding, removing or modifying a certificate authority.
Configuring your Azure AD tenant for certificate based authentication
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
3. Connect to your target tenant:
Connect-AzureAD
Adding a new certificate authority

1. Set various properties of the certificate authority and add it to Azure Active Directory:
$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-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
2. Get the Certificate Authorities:
Retrieving the list certificate authorities

Retrieve the certificate authorities currently stored in Azure Active Directory for your tenant:
Removing a certificate authority

2. Remove the certificate for the certificate authority:
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]
Modfiying a certificate authority

2. Modify properties on the certificate authority:
$c[0].AuthorityType=1
3. Set the Certificate Authority:
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
Testing Office mobile applications

To test certificate authentication on your mobile Office application:
1. On your test device, install an Office mobile application (e.g. OneDrive) from the App Store.
2. Verify that the user certificate has been provisioned to your test device.
3. Launch the application.
4. Enter your user name, and then pick the user certificate you want to use.
You should be successfully signed in.
Testing Exchange ActiveSync client applications

To access Exchange ActiveSync via certificate based authentication, an EAS profile containing the client certificate
must be available to application. The EAS profile must contain the following information:
The user certificate to be used for authentication
The EAS endpoint must be outlook.office365.com (as this feature is currently supported only in the Exchange
online multi-tenant environment)
An EAS profile can be configured and placed on the device through the utilization of an MDM such as Intune or by
manually placing the certificate in the EAS profile on the device.
Testing EAS client applications on iOS
To test certificate authentication with the native mail application on iOS 9 or above:
1. Configure an EAS profile that satisfies the requirements above.
2. Install the profile on the iOS device (either using an MDM, such as Intune, or the Apple Configurator application)
3. Once the profile is properly installed, open the native Mail application, and verify that mail is synchronizing
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.
1. Connect with admin credentials to the MSOL service:
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).
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 whats 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 businesss 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 Microsofts 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. Lets 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 users 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 users 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 premise 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
Finding unmanaged cloud applications with Cloud
App Discovery
Overview
In modern enterprises, IT departments are often not aware of all the cloud applications that members of their
organization use 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. This lack of awareness can make creating
a plan for dealing with these security risks seem daunting.
Cloud App Discovery is a feature of Azure Active Directory (AD) Premium that enables you to discover cloud
applications being used by the people in your organization.
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.
To get started with Cloud App Discovery, see Getting Started With Cloud App Discovery
Related articles
Cloud App Discovery Security and Privacy Considerations
Cloud App Discovery Group Policy Deployment Guide
Cloud App Discovery System Center Deployment Guide
Cloud App Discovery Registry Settings for Proxy Servers with Custom Ports
Cloud App Discovery Agent Changelog
Cloud App Discovery Frequently Asked Questions
Cloud App Discovery Registry Settings for Proxy
Services
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.
The objective of this topic is to provide you with the steps you need to perform to set the required port on the
computers running the Cloud App Discovery agent.
To modify the port used by the computer running the Cloud App Discovery agent, perform the following
steps:
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 textbox, type 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.

Cloud App Discovery Security and Privacy
Considerations
Microsoft is committed to protecting your privacy and securing your data, while delivering software and services
that help you manage the security of your organization.
We recognize that when you entrust your data to others, that trust requires rigorous security engineering
investments and expertise to back it. Microsoft adheres to strict compliance and security guidelines from secure
software development lifecycle practices to operating a service.
Securing and protecting data is a top priority at Microsoft.
This topic explains how data is collected, processed, and secured within Azure Active Directory Cloud App Discovery
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 flow of information and describe how it is secured as it moves 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 Directorys 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 list below 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 blade in the Microsoft
Azure portal, under Settings->Data Collection->App Collection list. For more details, see Getting Started With
Cloud App Discovery
Information Category: User information
Description:
The Windows user name of the process that made a request to the target Web application (e.g.:
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 (e.g.: 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 information
about the software and hardware configuration, error reports, and information about 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 ACLd to administrators. It
is intended to never leave the machine on which it was created. When the end-users 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-users 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 users 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 services 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.
How to provide secure remote access to on-premises
applications
NOTE
Application Proxy is a feature that is available only if you upgraded to the Premium or Basic edition of Azure Active
Directory. For more information, see Azure Active Directory editions.
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), demilitarized zones (DMZs), or on-
premises reverse proxies. 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 the Azure Active Directory Premium offering, and offers remote access as a
service. That means it's easy to deploy, use, and manage.
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. This can 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 then 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 this 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:
Works in the cloud, so you can save time and money. On-premises solutions require you to set up and
maintain DMZs, edge servers, or other complex infrastructures.
Is easier to set up and secure than on-premises solutions because you don't have to open any inbound
connections through your firewall.
Offers great security. When you publish your apps using Azure AD Application Proxy, you can take advantage
of the rich authorization controls and security analytics in Azure. This means that you get advanced security
capabilities for all your existing apps without having to change any app.
Gives your users a consistent authentication experience. Single sign-on gives your end users the ease and
simplicity of access to all the apps they need to be productive with one password.
What kind of applications work with Azure AD 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 access
Web APIs that you want to expose to rich applications on different devices
Applications hosted behind a Remote Desktop Gateway
How does it work?

Application Proxy works by installing a slim Windows Server service called a connector inside your network. With
the connector, you don't have to open any inbound ports or put anything in the DMZ. If you have high traffic in
your apps you can add more connectors, and the service takes care of the load balancing. The connectors are
stateless and pull everything from the cloud as necessary.
When users access applications remotely, they connect to the published endpoint. Users 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 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 user.
3. The user sends the token to Application Proxy, which retrieves the user principal name (UPN) and security
principal name (SPN) from the token, then directs the request to the connector.
4. On behalf of the user, the connector requests a Kerberos ticket that can be used for internal (Windows)
authentication. This is known as Kerberos Constrained Delegation.
5. Active Directory retrieves the Kerberos ticket.
6. The ticket is sent to the application server and verified.
7. The response is sent through Application Proxy 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 is achieved because the user was already authenticated by Azure AD.
How to get started

Make sure you have an Azure AD basic or premium subscription and an Azure AD directory for which you are a
global administrator. You also need Azure AD basic or premium licenses for the directory administrator and users
accessing the apps. See Azure Active Directory editions for more information.
Setting up Application Proxy is accomplished 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?
There's a lot more you can do with Application Proxy:
Publish applications using your own domain name
Enable single-sign on
Working with claims aware applications
Enable conditional access
For the latest news and updates, check out the Application Proxy blog
Enable Application Proxy in the Azure portal
This article walks you through the steps to enable Microsoft Azure AD Application Proxy for your cloud directory
in Azure AD.
If you're unfamiliar with what Application Proxy can help you do, 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 Windows 8.1 or higher, on which you can install the
Application Proxy Connector. The server sends requests to the Application Proxy services in the cloud, and
it needs an HTTP or HTTPS connection to the applications that you are publishing.
For single sign-on to your published applications, this machine should be domain-joined in the same
AD domain as the applications that you are publishing.
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. The Connector uses these ports together with subdomains that are part
of the high-level domains msappproxy.net and servicebus.windows.net. Make sure to open the following
ports to outbound traffic:
PORT NUMBER DESCRIPTION
80 Enable outbound HTTP traffic for security validation.
443 Enable user authentication against Azure AD (required

only for the Connector registration process)
1010010120 Enable LOB HTTP responses sent back to the proxy
9352, 5671 Enable communication between the Connector toward

the Azure service for incoming requests.
9350 Optional, to enable better performance for incoming

requests
8080 Enable the Connector bootstrap sequence and Connector

automatic update
9090 Enable Connector registration (required only for the

Connector registration process)
9091 Enable Connector trust certificate automatic renewal
If your firewall enforces traffic according to originating users, open these ports for traffic coming from
Windows services running as a Network Service. Also, make sure to enable port 8080 for NT
Authority\System.
If your organization uses proxy servers to connect to the internet, please take a look at the blog post Working
with existing on-premises proxy servers for details on how to configure them.
Step 1: Enable Application Proxy in Azure AD

1. Sign in as an administrator in the Azure classic portal.
2. Go to Active Directory and select the directory in which you want to enable Application Proxy.
3. Select Configure from the directory page, and scroll down to Application Proxy.
4. Toggle Enable Application Proxy Services for this Directory to Enabled.
5. Select Download now. This takes you to the Azure AD Application Proxy Connector Download. Read and
accept the license terms and click Download to save the Windows Installer file (.exe) for the connector.
Step 2: Install and register the Connector

1. Run AADApplicationProxyConnectorInstaller.exe on the server you prepared according to the
prerequisites.
2. Follow the instructions in the wizard to install.
3. During installation, you will 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, the registration screen might be blocked. Follow the instructions in the error message to
allow access. Make sure that Internet Explorer Enhanced Security is off.
If connector registration does not succeed, see Troubleshoot Application Proxy.
4. When the installation completes, two new services are added to your server:
Microsoft AAD Application Proxy Connector enables connectivity
Microsoft AAD Application Proxy Connector Updater is an automated update service, which
periodically checks for new versions of the connector and updates the connector as needed.
5. Click Finish in the installation window.
For high availability purposes, you should deploy at least two connectors. To deploy more connectors, repeat
steps 2 and 3, above. Each connector must be registered separately.
If you want to uninstall the Connector, uninstall both the Connector service and the Updater service. Restart your
computer to fully remove the service.
Next steps
You are now ready to Publish applications with Application Proxy.
If you have applications that are on separate networks or different locations, you can 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 - Public Preview
Azure Active Directory (AD) Application Proxy helps you support remote workers by publishing on-premises
applications to be accessed over the internet. Through the Azure portal, you can publish applications that are
running on your local network and 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, you'll be ready to configure the application with single sign-on, personalized information, or security
requirements.
If you're new to Application Proxy, learn more about this feature with the article How to provide secure remote
Publish an on-premises app for remote access

TIP
If this is your first time using Application Proxy, choose an application that's already 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 > Add.
3. On the Categories page, select Or add your own.

4. Choose Deploying an existing application from the dropdown menu.
5. Provide a name for your app, then select Add. A loading window pops up, and once your app is added the Quick
start blade opens.
6. On the Quick start blade, select Enable remote access for your on-premises application.
7. Provide the following information about your application:

Internal URL: The address that the Application Proxy Connector uses 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.
External URL: The address your users will go to in order to access the app from outside your
network.
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.
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.
Translate URL in Headers?: Choose whether to translate the URL in the headers, or keep the original.
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 and you'll see a warning message asking you to
create a connector group.
8. Select Save.
Add a test user

To test that your app was published correctly, add a user account that you have access to.
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
Publish applications using Azure AD Application
Proxy
Azure AD Application Proxy helps you support remote workers by publishing on-premises applications to be
accessed over the internet. By this point, you should already have enabled Application Proxy in the Azure classic
portal. This article walks you through the steps to publish applications that are running on your local network and
provide secure remote access from outside your network. After you complete this article, you'll be ready to
configure the application with personalized information or security requirements.
NOTE
Application Proxy is a feature that is available only if you upgraded to the Premium or Basic edition of Azure Active
Directory. For more information, see Azure Active Directory editions.
Publish an app using the wizard

2. Go to Active Directory and select the directory where you enabled Application Proxy.
3. Click the Applications tab, and then click the Add button at the bottom of the screen
4. Select Publish an application that will be accessible from outside your network.
5. Provide the following information about your application:
Name: The user-friendly name for your application. It must be unique within your directory.
Internal URL: The address that the Application Proxy Connector uses 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,
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.
Preauthentication Method: How Application Proxy verifies users before giving them access to
your application. Choose one of the options from the drop-down menu.
Azure Active Directory: Application Proxy redirects users to sign in with Azure AD, which
authenticates their permissions for the directory and application.
Passthrough: Users don't have to authenticate to access the application.
6. To finish the wizard, click the check mark at the bottom of the screen. The application is now defined in Azure
AD.
Assign users and groups to the application

In order for your users to access your published application, you need to assign them either individually or in
groups. (Remember to assign yourself access, too.) This requires that each user have a license for Azure Basic or
higher. You can assign licenses individually or to groups. See Assigning users to an application for more details.
For apps that require preauthentication, this grants permissions to use the app. For apps that don't require
preauthentication, users can still be assigned to the app so that it appears in their application list, such as
MyApps.
1. After finishing the Add App wizard, you see the Quick Start page for your application. To manage who has
access to the app, select Users and groups.
2. Search for specific groups in your directory, or show all your users. To display the search results, click the
check mark.
3. Select each user or group you want to assign to this app and click Assign. You are asked to confirm this
action.
NOTE
For Integrated Windows Authentication apps, you can assign only users and groups that are synced from your on-
premises Active Directory. Users who sign in with a Microsoft account and guests cannot be assigned for apps published
with Azure Active Directory Application Proxy. Make sure your users sign in with credentials that are part of the same
domain as the app you are publishing.
Test your published application

Once you have published your application, you can test it out by navigating to the URL that you published. Make
sure that you can access it, that it renders correctly, and that everything works as expected. If you have trouble or
get an error message, try the troubleshooting guide.
Configure your application

You can modify published apps or set up advanced options on the Configure page. On this page, you can
customize your app by changing the name or uploading a logo. You can also manage access rules like the
preauthentication method or multi-factor authentication.
After you publish applications using Azure Active Directory Application Proxy, they appear in the Applications list
in Azure AD, and you can manage them there.
If you disable Application Proxy services after you have published applications, they are no longer accessible from
outside your private network. This does not delete the applications.
To view an application and make sure that it is accessible, double-click the name of the application. If the
Application Proxy service is disabled and the application is not available, a warning message appears at the top of
the screen.
To delete an application, select an application in the list and then click Delete.
Next steps
Publish applications on separate networks and
locations using connectors - Public Preview
Connectors and connector groups are useful for various scenarios, including:
Sites with multiple 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.
Managing applications installed on isolated 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.
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 this network. You can install several connectors to achieve high availability.
Support for multi-forest environments in which specific connectors can be deployed per forest and set to serve
specific applications.
Connector groups can be used in Disaster Recovery sites to either detect failover or as backup for the main site.
Connector groups can also be used to serve multiple companies from a single tenant.
Prerequisite: Create your connectors

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.
Step 1: Create connector groups

You can create as many connector groups as you want. Connector group creation is accomplished in the Azure
portal.
1. Select Azure Active Directory to go to the management dashboard for your directory. From there, select
Enterprise applications > Application proxy.
2. Select the Connector Groups button. The New Connector Group blade appears.
3. Give your new connector group a name, then use the dropdown menu to select which connectors belong in this
group.
4. Select Save when your connector Group is complete.
Step 2: Assign applications to your connector groups

The last step is to set each application to the connector group that will serve it.
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. Under Connector group, use the dropdown menu to select the group you want the application to use.
3. Select Save to apply the change.
See also
Enable Application Proxy
Troubleshoot issues you're having with Application Proxy
Publish applications on separate networks and
locations using connector groups
Connector groups are useful for various scenarios, including:

Sites with multiple interconnected datacenters. In this case, you want to keep as much traffic within the
datacenter as possible because cross-datacenter links are usually 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.
Managing applications installed on isolated 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.
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 this network. You can install several connectors to achieve high availability.
Support for multi-forest environments in which specific connectors can be deployed per forest and set to serve
specific applications.
Connector groups can be used in Disaster Recovery sites to either detect failover or as backup for the main site.
Connector groups can also be used to serve multiple companies from a single tenant.
Prerequisite: Create your connectors

In order to group your connectors, you have to make sure you installed multiple connectors, and that you name
them and then group them. Finally you have to assign them to specific apps.
Step 1: Create connector groups

You can create as many connector groups as you want. Connector group creation is accomplished in the Azure
classic portal.
1. Select your directory and click Configure.
2. Under Application Proxy, click Manage Connector Groups and create a new connector group by giving the
group a name.
Step 2: Assign connectors to your groups
Once the connector groups are created, move the connectors to the appropriate group.
1. Under Application Proxy, click Manage Connectors.
2. Under Group, select the group you want for each connector. It might take the connectors up to 10 minutes to
become active in the new group.
Step 3: Assign applications to your connector groups

The last step is to set each application to the connector group that will serve it.
1. In the Azure classic portal, in your directory, select the Application you want to assign to the group and click
Configure.
2. Under Connector group, select the group you want the application to use. This change is immediately applied.
See also
Enable Application Proxy
Working with custom domains in Azure AD
Application Proxy
Using a default domain enables you to set the same URL as the internal and external URL for accessing the
application so that your users only have one URL to remember to access the app, no matter where they are
accessing from. This also lets you create a single shortcut in the Access Panel for the application. If you use the
default domain provided by Azure AD Application Proxy, theres no additional configuration you need to enable
your domain. In the event that you use a custom domain, there are a few things you need to do to make sure that
Application Proxy recognizes your domain and validates its certificates.
Selecting your custom domain

1. Publish your application according to the instructions in Publish applications with Application Proxy.
2. After the application appears in the list of applications, select it and click Configure.
3. Under External URL, enter your custom domain.
4. If your external URL is https, you will be prompted to upload a certificate so that Azure can validate the URL of
the application. You can also upload a wildcard certificate that matches the External URL of the application. This
domain must be within the list of your Azure verified domains. Azure must have a certificate for the domain
URL of the application or a wildcard certificate that matches the External URL for the application.
5. Make sure to add a DNS record that routes the internal URL to the application that enables you to have the
same URL for internal and external access and a single shortcut to the application in the users applications list.
Frequently asked questions about working with custom domains

Q: Can I select an already-uploaded certificate without uploading it again?
A: Previously uploaded certificates are automatically bound to an application, and there is exactly one certificate
matching the applications host name.
Q: How do I add a certificate and what format should the exported certificate be uploaded in?
A: The certificate should be uploaded from the application configuration page. The certificate should be a PFX file.
Q: Can ECC certs be used?
A: There is no explicit limitation on signature methods.
Q: Can SAN certs be used?
A: Yes.
Q: Can wildcard certs be used?
A: Yes.
Q: Can a different certificate be used on each application?
A: Yes, unless the two applications share the same external host.
Q: If I register a new domain, can I use that domain?
A: Yes, the list of domains is fed from the tenants verified domain list.
Q: What happens when a cert expires?
A: You will get a warning in the certificate section in the application configuration page. When a user tries to access
the application, a security warning will pop up.
Q: What should I do if I want to replace a cert for a given app?
A: Upload a new certificate from the application configuration page.
Q: Can I delete a cert and replace it?
A: When you upload a new certificate, if the old certificate is not in use by another application, it will be
automatically deleted.
Q: What happens when a cert is revoked?
A: Revocation checks are not performed for certificates. When a user tries to access the application, depending on
the browser, a security warning might appear.
Q: Can I use a self-signed certificate?
A: Yes, self-signed certificates are allowed. Note that if youre using a private certificate authority, the CDP
(certificate revocation point distribution point) for the certificate should be public.
Q: Is there a place to see all the certificates for my tenant?
A: This is not supported in the current version.
See also
Publish applications with Application Proxy
Enable single sign-on
Add your custom domain name to Azure AD
Single sign-on with Application Proxy
Single sign-on is a key element of Azure AD Application Proxy. It provides the best user experience with the
following steps:
1. A user signs in to the cloud
2. All security validations happen in the cloud (preauthentication)
3. When the request is sent to the on-prem application, the Application Proxy Connector impersonates the user.
The backend application thinks this is a regular user coming from a domain-joined device.
Azure AD Application Proxy helps you provide a single sign-on (SSO) experience for your users. Use the following
instructions to publish your apps using SSO:
SSO for on-prem IWA apps using KCD with Application Proxy
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, and send and receive tokens
on their behalf.
Network diagram
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 SSO for Application Proxy, 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 for users. This is a
default setting that might have been impacted by security hardening the environment. Get more help with this
setting in KB2009157.
Active Directory configuration
The Active Directory configuration varies, depending on whether your Application Proxy Connector and the
published server are in the same domain or not.
Connector and published 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. Under Services to which this
account can present delegated credentials add the value for the SPN identity of the application server.
5. This enables the Application Proxy Connector to impersonate users in AD against the applications defined in
the list.
Connector and published server in different domains
1. For a list of prerequisites for working with KCD across domains, see Kerberos Constrained Delegation across
domains.
2. In Windows 2012 R2, use the principalsallowedtodelegateto property on the Connector server to enable
the Application Proxy to delegate for the Connector server, where the published server is
sharepointserviceaccount and the delegating server is connectormachineaccount .
$connector= Get-ADComputer -Identity connectormachineaccount -server dc.connectordomain.com
Set-ADComputer -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
Get-ADComputer sharepointserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
NOTE
sharepointserviceaccount can be the SPS machine account or a service account under which the SPS app pool is
running.
Azure classic portal configuration

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 applications, select it and click Configure.
3. Under Properties, set Internal Authentication Method 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/lob.contoso.com.
IMPORTANT
If your on-premises UPN and the UPN in Azure Active Directory are not identical, you need to configure the delegated
login identity in order for preauthentication to work.
Internal Authentication Method If you use Azure AD for preauthentication, you can set an
internal authentication method to enable your users to
benefit from single sign-on (SSO) to this application.
Select Integrated Windows Authentication (IWA) if your

application uses IWA and you can configure Kerberos
Constrained Delegation (KCD) to enable SSO for this
application. Applications that use IWA must be configured
using KCD, otherwise Application Proxy can't publish these
applications.
Select None if your application does not use IWA.
Internal Application SPN This is the Service-Principal-Name (SPN) of the internal

application as configured in the on-prem Azure AD. The SPN
is used by the Application Proxy Connector to fetch Kerberos
tokens for the application using KCD.
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.
Delegated login identity
Delegated login identity helps you handle two different login scenarios:
Non-Windows applications that typically get user identity in the form of a username or SAM account name,
not an email address (username@domain).
Alternative login configurations where the UPN in Azure AD and the UPN in your on-premises Active
Directory are different.
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 for 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.
Working with SSO when on-premises and cloud identities are not
identical
Unless otherwise configured, Application Proxy assumes that users have exactly the same identity in the cloud
and on-premises. You can configure, for each application, which identity should be used when performing single
sign-on.
This capability allows many organizations that have different on-prem and cloud identities to have SSO from the
cloud to on-prem 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. E.g. joe-johns@contoso.com vs. joej@contoso.com
It also helps with applications that do not accept addresses in the form of email address, which is a very common
scenario for non-Windows backend servers.
Setting SSO for different cloud and on-prem 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: joe@contoso.com
Alternate User Principal Name: joed@contoso.local
Username part of User Principal Name: joe
Username part of Alternate User Principal Name: joed
On-premises SAM account name: depending on-prem 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.
See also
Provide single sign-on with Azure AD Application
Proxy - Public Preview
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. Now, your users only need to authenticate with Azure AD, and they can access your enterprise
application without having to sign in again.
In this article, we'll use the example of a password-based app to show how password vaulting provides a simple
SSO experience.
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 - Public Preview then come back here.
Or, if you're new to Application Proxy, learn more about this feature with the article How to provide secure remote
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. If you have a lot of apps, you can use the search
box to filter for the right one.
4. Under the Manage section, 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. This should be the External URL that you created when you published the app through
Application Proxy.
7. Select Save.
Test your app

Go to the MyApps site and select the app you just configured. Sign in with your credentials for that app (or the
credentials for the test account 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
Working with claims aware apps in Application Proxy
Claims aware apps perform a redirection to the Security Token Service (STS), which in turn requests credentials
from the user in exchange for a token before redirecting the user to the application. To enable Application Proxy to
work with these redirects, the following steps need to be taken.
Prerequisites
Before performing this procedure, make sure that the STS the claims aware app redirects to is available outside of
your on-premises network.
Azure classic portal configuration

1. Publish your application according to the instructions described in Publish applications with Application Proxy.
2. In the list of applications, select the claims aware app and click Configure.
3. If you chose Passthrough as your Preauthentication Method, make sure to select HTTPS as your External
URL scheme.
4. If you chose Azure Active Directory as your Preauthentication Method, select None as your Internal
Authentication Method.
ADFS configuration
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.
See also
Enable native client apps to interact with proxy applications
How to enable native client apps to interact with
proxy Applications
Azure Active Directory Application Proxy is widely used to publish browser applications such as SharePoint,
Outlook Web Access and custom line of business applications. It can also be used to publish native client apps,
which differ from web apps because they get installed on a device. This is done by supporting Azure AD issued
tokens that are sent in standard Authorize HTTP headers.
The recommended method to publish such applications is to use the Azure AD Authentication Library, which takes
care of all the authentication hassle and supports many different client environments. Application Proxy fits into the
Native Application to Web API scenario. The process for accomplishing this is as follows:
Step 1: Publish your application

Publish your proxy application as you would any other application, assign users and give them premium or basic
licenses. For more information see Publish applications with Application Proxy.
Step 2: Configure your application

Configure your native application as follows:
1. Sign in to the Azure classic portal.
2. Select the Active Directory icon on the left menu, and then select your directory.
3. On the top menu, click Applications. If no apps have been added to your directory, this page will only show the
Add an App link. Click on the link, or alternatively you can click on the Add button on the command bar.
4. On the What do you want to do page, click on the link to Add an application my organization is
developing.
5. On the Tell us about your application page, specify a name for your application and choose Native client
application. Click the arrow icon to continue.
6. On the Application information page, provide the Redirect URI for the native client application, then click the
checkmark to finish.
Your application has been added, and you will be taken to the Quick Start page for your application.
Step 3: Grant access to other applications

Enable the native application to be exposed to other applications in your directory:
1. On the top menu, click Applications, select the new native application, and then click Configure.
2. Scroll down to the permissions to other applications section. Click on the Add application button and select
the proxy application that you want to grant the native application access to, and click the check mark in the
bottom right corner. From the Delegated Permissions drop-down menu, select the new permission.
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:
// Acquire Access Token from AAD for Proxy Application

AuthenticationContext authContext = new
AuthenticationContext("https://login.microsoftonline.com/<TenantId>");
AuthenticationResult result = authContext.AcquireToken("< Frontend Url of Proxy App >",
"< Client 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 should be replaced as follows:

TenantId can be found in the GUID in the URL of the application's Configuration page, right after
/Directory/.
Frontend URL is the front end URL you entered in the Proxy Application and can be found on the
Configuration page of the proxy app.
Client Id of the native app can be found on the Configure page of the native application.
Redirect URI of the native app can be found on the Configure page of the native application.
For more information about the native application flow, see Native application to web API.
See also
Working with conditional access in Azure AD
Application Proxy
You can configure access rules to grant conditional access to applications published using Application Proxy. This
enables you to:
Require multi-factor authentication per application
Require multi-factor authentication only when users are not at work
Block users from accessing the application when they are not at work
These rules can be applied to all users and groups or only to specific users and groups. By default the rule will
apply to all users who have access to the application. However the rule can also be restricted to users that are
members of specified security groups.
Access rules are evaluated when a user accesses a federated application that uses OAuth 2.0, OpenID Connect,
SAML or WS-Federation. In addition, access rules are evaluated with OAuth 2.0 and OpenID Connect when a
refresh token is used to acquire an access token.
Conditional access prerequisites

Subscription to Azure Active Directory Premium
A federated or managed Azure Active Directory tenant
Federated tenants require that multi-factor authentication (MFA) be enabled
Configure per-application multi-factor authentication

2. Go to Active Directory and select the directory in which you want to enable Application Proxy.
3. Click Applications and scroll down to the Access Rules section. The access rules section only appears for
applications published using Application Proxy that use federated authentication.
4. Enable the rule by selecting Enable Access Rules to On.
5. Specify the users and groups to whom the rules will apply. Use the Add Group button to select one or
more groups to which the access rule will apply. This dialog can also be used to remove selected groups.
When the rules are selected to apply to groups, the access rules will only be enforced for users that belong
to one of the specified security groups.
To explicitly exclude security groups from the rule, check Except and specify one or more groups.
Users who are members of a group in the Except list will not be required to perform multi-factor
authentication.
If a user was configured using the per-user multi-factor authentication feature, this setting will take
precedence over the application multi-factor authentication rules. This means that a user who has been
configured for per-user multi-factor authentication will be required to perform multi-factor
authentication even if they have been exempted from the application's multi-factor authentication
rules. Learn more about multi-factor authentication and per-user settings.
6. Select the access rule you want to set:
Require Multi-factor authentication: Users to whom access rules apply will be required to complete
multi-factor authentication before accessing the application to which the rule applies.
Require Multi-factor authentication when not at work: Users trying to access the application from
a trusted IP address will not be required to perform multi-factor authentication. The trusted IP address
ranges can be configured on the multi-factor authentication settings page.
Block access when not at work: Users trying to access the application from outside your corporate
network will not be able to access the application.
Configuring MFA for federation services

For federated tenants, multi-factor authentication (MFA) may be performed by Azure Active Directory or by the
on-premises AD FS server. By default, MFA will occur on any page hosted by Azure Active Directory. In order to
configure MFA on-premises, run Windows PowerShell and use the SupportsMFA property to set the Azure AD
module.
The following example shows how to enable on-premises MFA by using the Set-MsolDomainFederationSettings
cmdlet on the contoso.com tenant: Set-MsolDomainFederationSettings -DomainName contoso.com -SupportsMFA $true
In addition to setting this flag, the federated tenant AD FS instance must be configured to perform multi-factor
authentication. Follow the instructions for deploying Microsoft Azure multi-factor authentication on-premises.
See also
How to silently install the Azure AD Application Proxy
Connector
You want to be able to send an installation script to multiple Windows servers or to Windows Servers that don't
have user interface enabled. This topic explains how to create a Windows PowerShell script that enables unattended
installation to install and register your Azure AD Application Proxy Connector.
Enabling Access
Application Proxy works by installing a slim Windows Server service called the Connector inside your network. 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 is entered during Connector installation in a pop up dialog box.
Alternatively, you can use Windows PowerShell to create a credential object to enter your registration information,
or you can create your own token and use it to enter your registration information.
Step 1: Install the Connector without registration

Install the Connector MSIs without registering the Connector as follows:
1. Open a command prompt.
2. Run the following command in which the /q means quiet installation - the installation will not prompt you to
accept the End User License Agreement.
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
Step 2: Register the Connector with Azure Active Directory

This can be accomplished using either of the following methods:
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 the Windows PowerShell Credentials object by running the following, where "" and "" should be
replaced with the username and password for your directory:
$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 script using the PowerShell
credentials object you created, where $cred is the name of the PowerShell credentials object 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 the 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.windows.net/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, where SecureToken is the name of the token you created
above and tenantID is your tenant's GUID:
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -moduleName
"AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId <tenant GUID>
See also
Enable Application Proxy for Azure Active Directory
Troubleshoot Application Proxy
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 analytics and debugging logs, and turning on the
Application Proxy connector session log.
The page is not rendered correctly

If you're not getting a specific error message, you may still have issues with your application rendering or
functioning incorrectly. 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.
General errors
ERROR DESCRIPTION RESOLUTION
This corporate app cant be accessed. You may not have assigned the user Go to the Application tab, and under
You are not authorized to access this for this application. Users and Groups, assign this user or
application. Authorization failed. Make user group to this application.
sure to assign the user with access to
this application.
This corporate app cant be accessed. Your users may get this error when Go to the subscribers Active Directory
You are not authorized to access this trying to access the app you published Licenses tab and make sure that this
application. Authorization failed. Make if they weren't explicitly assigned with a user or user group is assigned a
sure that the user has a license for Premium/Basic license by the Premium or Basic license.
Azure Active Directory Premium or subscribers administrator.
Basic.
Connector troubleshooting
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
Connector registration failed: Make You closed the registration window Run the Connector wizard again and
sure you enabled Application Proxy in without performing login to Azure AD. register the Connector.
the Azure Management Portal and that
you entered your Active Directory user
name and password correctly. Error:
'One or more errors occurred.'
Connector registration failed: Make Application Proxy is disabled. Make sure you enable Application
sure you enabled Application Proxy in Proxy in the Azure classic portal before
the Azure Management Portal and that trying to register the Connector. For
you entered your Active Directory user more information on enabling
name and password correctly. Error: Application Proxy, see Enable
'AADSTS50001: Resource Application Proxy services.
https://proxy.cloudwebappproxy.net
/registerapp
is disabled.'
Connector registration failed: Make If the registration window opens and Make sure that it is possible to connect
sure you enabled Application Proxy in then immediately closes without from a browser to a public website and
the Azure Management Portal and that allowing you to log in, you will that the ports are open as specified in
you entered your Active Directory user probably get this error. This error Application Proxy prerequisites.
name and password correctly. Error: occurs when there is a networking
'One or more errors occurred.' error on your system.
Connector registration failed: Make If you sign in using your Azure AD Make sure that the necessary ports are
sure your computer is connected to username and password but then open. For more information, see
the Internet. Error: 'There was no receive this error, it may be that all Application Proxy prerequisites.
endpoint listening at ports above 8081 are blocked.
https://connector.msappproxy.net
:9090/register/RegisterConnector
that could accept the message. This is
often caused by an incorrect address or
SOAP action. See InnerException, if
present, for more details.'
Clear error is presented in the You entered the wrong username or Try again.
registration window. Cannot proceed password.
only to close the window.
Connector registration failed: Make You are trying to log in using a Make sure that the admin is part of the
sure you enabled Application Proxy in Microsoft Account and not a domain same domain name as the tenant
the Azure Management Portal and that that is part of the organization ID of domain, for example, if the Azure AD
you entered your Active Directory user the directory you are trying to access. domain is contoso.com, the admin
name and password correctly. Error: should be admin@contoso.com.
'AADSTS50059: No tenant-identifying
information found in either the request
or implied by any provided credentials
and search by service principal URI has
failed.
Failed to retrieve the current execution If the Connector installation fails, check Open the Group Policy Editor. Go to
policy for running PowerShell scripts. to make sure that PowerShell execution Computer Configuration >
policy is not disabled. Administrative Templates >
Windows Components > Windows
PowerShell and double-click Turn on
Script Execution. This 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 The Connectors client certificate, which Renew trust manually using the
configuration. is used for authentication, expired. This Register-AppProxyConnector cmdlet
may also occur if you have the in Windows PowerShell. If your
Connector installed behind a proxy. In Connector is behind a proxy, it is
this case, the Connector cannot access necessary to grant Internet access to
the Internet and will not be able to the Connector accounts network
provide applications to remote users. 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 The alias you're trying to log in with Make sure that the admin you are
sure you are a Global Administrator of isn't an admin on this domain. Your trying to log in as has global
your Active Directory to register the Connector is always installed for the permissions to the Azure AD tenant.
Connector. Error: 'The registration directory that owns the users domain.
request was denied.'
Kerberos errors
Failed to retrieve the current execution If the Connector installation fails, check Open the Group Policy Editor. Go to
policy for running PowerShell scripts. to make sure that PowerShell execution Computer Configuration >
policy is not disabled. Administrative Templates >
Windows Components > Windows
PowerShell and double-click Turn on
Script Execution. This 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 This event may indicate incorrect The backend server declined the
maximum number of permitted configuration between Azure AD and Kerberos ticket created by Azure AD.
Kerberos authentication attempts to the backend application server, or a Verify that Azure AD and the backend
the backend server. problem in time and date configuration application server are configured
on both machines. 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 There is a problem with the STS Fix the UPN claim configuration in the
Kerberos ticket on behalf of the user configuration. STS.
because there is no UPN in the edge
token or in the access cookie.
13019 - Azure AD cannot retrieve a This event may indicate incorrect The domain controller declined the
Kerberos ticket on behalf of the user configuration between Azure AD and Kerberos ticket created by Azure AD.
because of the following general API the domain controller server, or a Verify that Azure AD and the backend
error. problem in time and date configuration application server are configured
on both machines. 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 This event may indicate incorrect The domain controller declined the
Kerberos ticket on behalf of the user configuration between Azure AD and Kerberos ticket created by Azure AD.
because the backend server SPN is not the domain controller server, or a Verify that Azure AD and the backend
defined. problem in time and date configuration application server are configured
on both machines. 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 This event may indicate incorrect The backend server declined the
the user because the backend server configuration between Azure AD and Kerberos ticket created by Azure AD.
responds to Kerberos authentication the backend application server, or a Verify that Azure AD and the backend
attempts with an HTTP 401 error. problem in time and date configuration application server are configured
on both machines. correctly. Make sure that the time and
date configuration on the Azure AD
and the backend application server are
synchronized.
The website cannot display the page. Your user may get this error when For IWA apps: Make sure that the SPN
trying to access the app you published configured for this application is
if the application is an IWA application. correct.
The defined SPN for this application
may be incorrect.
The website cannot display the page. Your user may get this error when The steps to mitigate accordingly:
trying to access the app you published - Make sure that the SPN configured
if the application is an OWA for this application is correct.
application. This could be caused by - Make sure the user signs in using
one of the following: their corporate account that matches
- The defined SPN for this application is the domain of the published
incorrect. application. Microsoft Account users
- The user who tried to access the and guest cannot access IWA
application is using a Microsoft account applications.
rather than the proper corporate - Make sure that this user has the
account to sign in, or the user is a proper permissions as defined for this
guest user. backend application on the on-prem
- The user who tried to access the machine.
application is not properly defined for
this application on the on-prem side.
This corporate app cant be accessed. Your users may get this error when Microsoft Account users and guests
You are not authorized to access this trying to access the app you published cannot access IWA applications. Make
application. Authorization failed. Make if they use Microsoft accounts instead sure the user signs in using their
sure to assign the user with access to of their corporate account to sign in. corporate account that matches the
this application. Guest users may also get this error. domain of the published application.
This corporate app cant be accessed Your users may get this error when Make sure that your users have the
right now. Please try again laterThe trying to access the app you published proper permissions as defined for this
connector timed out. if they are not properly defined for this backend application on the on-prem
application on the on-prem side. machine.
See also
Enable Application Proxy for Azure Active Directory
Enable single sign-on
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 (e.g. 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 employees. 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 todays 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 Management 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 have 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 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 re-authenticated.
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 users sign in process via securely retrieving
application credentials such as the username and the password from the directory, and enters these credentials
into the applications 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 very 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 users browsers can be:
Internet Explorer 8, 9, 10, 11 -- on Windows 7 or later (See also IE Extension Deployment Guide)
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
Note: The password-based SSO extension will become available for Edge in Windows 10 when browser
extensions become supported for Edge.
Existing Single Sign-On
When configuring single sign-on for an application, the Azure management 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 youve 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 management portal
You can use the Active Directory extension in the Azure Management 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
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 Management 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.
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 apps 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
Preview: Managing single sign-on for enterprise apps
in the new Azure portal
This article describes how to use the Azure portal to manage single sign-on settings for applications, particularly
ones that have been added from the Azure Active Directory (Azure AD) application gallery. The Azure AD
management experience for single sign-on is currently in public preview, and this article describes the new features
as well as a few temporary limitations that will be in place only during the preview period. What's in the preview?
Finding your apps in the new portal

As of September 2016, all applications that have been configured for single sign-on in a directory, by a directory
administrator using the Azure Active Directory application gallery inside the Azure classic portal, can now be
viewed and managed in the Azure portal.
These applications can be found in the Enterprise Applications section of the Azure portal, a link to which can be
found in the More Services list in the portal. Enterprise apps are apps that have been deployed and are being used
by users within your organization.
Select All applications to view 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.
To manage single sign-on settings, select Single sign-on.
Single sign-on modes
The Single sign-on blade 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.
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 displays a blade that 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 this application. If the application is configured to perform
service provider-initiated single sign on, then when a user navigates to this URL, the service provider does the
necessary redirection to Azure AD to authenticate and sign the user in. If this field is populated, then Azure AD
will use this URL to launch 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.
For the first preview release, 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.
Editing of additional attributes will be supported in a subsequent preview.
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.
The ability to rollover the certificate and manage additional certificate options will be supported in a subsequent
preview release. Note that full management of certificates can still be performed in the Azure classic portal.
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 during the preview.
Password-based sign on
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.
Integrate Azure Active Directory single sign-on with
SaaS apps
Organizations are using more Software as a Service (SaaS) applications for productivity because cloud technology
and tools are becoming more readily available. As the number of SaaS apps grows, it becomes challenging for the
administrators to manage accounts and access rights, and for the users to remember their different passwords.
Managing these applications individually creates extra work and is less secure.
Employees who have to keep track of many passwords tend to use less-secure methods to remember them,
either writing down passwords or using the same passwords across many accounts.
When a new employee arrives or one leaves, all their accounts must be individually provisioned or de-
provisioned.
Additionally, employees may start using SaaS apps for their work without going through IT, which means they
are creating their own accounts on systems that the IT administrators haven't approved and aren't monitoring.
A solution for all of these challenges is single sign-on (SSO). It's the simplest way to manage multiple apps and
provide users with a consistent sign-on experience. Azure Active Directory (Azure AD) provides a robust SSO
solution and has many available pre-integrated applications, with tutorials for admins to quickly set up a new app
and start provisioning users.
How does Azure Active Directory integrate apps?

Azure AD allows you to integrate your apps and provisioned accounts. This can be done through either of two
approaches.
If the app is pre-integrated in the app Gallery, you can go through that portal to set up apps and configure the
settings to allow SSO. For any Gallery app, you can get started by follow the simple step-by-step instructions
presented in the app gallery and in the Azure portal to enable single sign-on.
If the app is not in the Gallery, you can still set up most apps in Azure AD as a custom app. This requires a bit
more technical expertise to configure. 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.
In the case where users have created their own accounts for SaaS apps that aren't managed by IT, the Cloud App
Discovery tool provides a solution. This tool monitors the web traffic to identify which apps are being used
throughout the organization, and the number of people using each of them. IT can use this information to learn
what apps the users prefer and decide which to integrate into Azure AD for SSO.
When you integrate an app into Azure AD, you can map the users' established application identities to their
respective Azure AD identities.
To get started setting up single sign-on for an app that youre bringing into your organization, you will be using an
existing directory in Azure Active Directory (Azure AD). You can use an Azure AD directory that you obtain through
Microsoft Azure, Office 365, or Windows Intune. If you have two or more of these, see Administer your Azure AD
directory to determine which one to use.
Authentication
For applications that support the SAML 2.0, WS-Federation, or OpenID Connect protocols, Azure Active Directory
uses signing certificates to establish trust relationships. For more information about this, see Managing certificates
for federated single sign-on.
For applications that support only HTML forms-based sign-in, Azure Active Directory uses password vaulting to
establish trust relationships. This enables the users in your organization to be automatically signed in to a SaaS
application by Azure AD using the user account information from the SaaS application. Azure AD collects and
securely stores the user account information and the related password. For more information, see Password-based
single sign-on.
Authorization
A provisioned account enables a user to be authorized to use an application after they have authenticated through
single sign-on. User provisioning can be done manually, or in some cases you can add and remove user
information from the SaaS app based on changes made in Azure Active Directory. For more information on using
existing Azure AD connectors for automated provisioning, see Automated user provisioning and de-provisioning
for SaaS applications.
Otherwise, you can manually add user information to an app, or use other provisioning solutions that are available
in the marketplace.
Access
Azure AD provides several customizable ways to deploy applications to end users in your organization. You are not
locked into any particular deployment or access solution. You can use the solution that best suits your needs.
Additional considerations for applications already in use

Setting up single sign on for an application that your organization already uses is a different process from the
process of creating new accounts for a new application. There are a couple of preliminary steps including: mapping
user identities in the application to Azure AD identities, and understanding how users will experience logging in to
an application after it is integrated.
NOTE
To set up SSO for an existing application, you need to have global administrator rights in both Azure AD and the SaaS
application.
Mapping user accounts

A user's identity typically has a unique identifier that could be an email address, or user principal name (UPN). You
will need to link (map) each user's application identity to their respective Azure AD identity. There are a couple of
ways to accomplish this depending on how the requirement of your application authentication.
For more information about mapping application identities with Azure AD identities, see Customizing claims
issued in the SAML token and Customizing attribute mappings for provisioning.
Understanding the user's log in experience
When you integrate SSO for an application thats already in use, its important to realize that the user experience
will be affected. For all applications, users will start using their Azure AD credentials to sign in. It could also be that
they must use a different portal to access the applications.
SSO for some applications can be done on the application's sign in interface, but for other applications, the user
will have to go through a central portal such as (My Apps or Office365) to sign in. Learn more about the different
types of SSO and their user experiences in What is application access and single sign-on with Azure Active
Directory.
Another valuable resource is Suppressing user consent in the Guiding developers article.
Next steps
For SaaS apps that you find in the App Gallery, Azure AD provides a number of tutorials on how to integrate SaaS
apps.
If app is not in App Gallery, you can add it to the Azure AD App Gallery as a custom application.
There is much more detail on all of these issues in the Azure.com library, beginning with What is application access
and single sign-on with Azure Active Directory..
See also
Assign a user or group to an enterprise app in Azure
It's easy to assign a user or a group to your enterprise applications in Azure Active Directory (Azure AD) preview.
What's in the preview? You must have the appropriate permissions to manage the enterprise app. In the current
preview, you must be global admin for the directory.
How do I assign user access to an enterprise app?

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. You'll see a list of 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 will have the permissions defined by the selected role for this enterprise app.
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)
preview. What's in the preview? You must have the appropriate permissions to make these changes. In the current
preview, you must be the creator of the custom app.
How do I change an enterprise app's name or logo?

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
It's easy to disable an enterprise application so that no users may sign in to it in Azure Active Directory (Azure AD)
preview. What's in the preview? You must have the appropriate permissions to manage the enterprise app. In the
current preview, 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?.
8. Select the Save command.
Next steps
See all my groups
Remove a user or group assignment from an
enterprise app in Azure Active Directory preview
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) preview. What's in the preview? You must have the appropriate permissions to
manage the enterprise app. In the current preview, you must be global admin for the directory.
How do I remove a user or group assignment?

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) preview. What's in the
preview? 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
Preview: Managing user account provisioning for
enterprise apps in the new 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. This management experience in the new Azure portal is currently in
public preview, and this article describes the new features as well as a few temporary limitations that are in place
during the preview period. What's in the preview?
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 new portal

As of September 2016, all applications that have been configured for single sign-on in a directory, by a directory
administrator using the Azure Active Directory application gallery inside the Azure classic portal, can now be viewed
and managed in the new Azure portal.
These applications can be found in the Enterprise Applications section of the new Azure portal, which can be
accessed through the More Services menu in the left navigation area. Enterprise apps are apps that have been
deployed and are being used by users 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 apps 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 during the first preview 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 what provisioning actions Azure AD should perform on the target application, which is a new feature in the
Azure portal. 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. The
full ability to create multiple mappings per app is planned for later in the preview period.
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.
Azure AD and Applications: Assigning Users to an
Application
Before you can assign users and groups to an application, you must require user assignment. To learn how to
require user assignment please see the Requiring User Assignment article.
Assigning Users to an Application

1. Log in to the Azure portal with an administrator account.
2. Click on the All Items item in the main menu.
3. Choose the directory you are using for the application.
4. Click on the APPLICATIONS tab.
5. Select the application from the list of applications associated with this directory.
6. Click the USERS AND GROUPS tab.
7. Select the users you want to assign to the application.
8. Click ASSIGN.
9. Click yes when prompted.
Next Steps
Configuring access rules
Requiring user assignment
Integrating applications with Azure Active Directory
Azure AD and Applications: Assigning Groups to an
Application
Before you can assign users and groups to an application, you must require user assignment. To learn how to
require user assignment, see the Requiring User Assignment article.
This article assumes that you have already created groups in the active directory you are using for this application.
Assigning Groups to an Application

6. Click the USERS AND GROUPS tab.
7. Filter the list of groups in your active directory by using the Groups dropdown list.
8. Select the group.
9. Click ASSIGN.
10. Click yes when prompted.
Next Steps
Azure AD and Applications: Requiring User
Assignment
Requiring User Assignment

6. Click the CONFIGURE tab.
7. Change the User Assignment Required to Access App toggle to Yes.
8. Click the Save button at the bottom of the screen.
You will now have to assign users and/or groups to the application. See Assigning users to an application and
Assigning groups to an application.
Next Steps
Azure AD and applications: Develop line-of-business
apps
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.
Heres 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 users access panel, you should require user assignment.
If youre 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.
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
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
Self-service application access and delegated
management with Azure Active Directory
Enabling self-service capabilities for end users is a common scenario for enterprise IT. Lots of users, lots of
applications, and the person who is best-informed to make access grant decisions may not be the directory
administrator. Often the best person to decide who can access an application is a team lead or other delegated
administrator. But at the end of the day, its the user who uses the app, and the user knows what they need to be
able to do their job.
Self-service application access is a feature of Azure Active Directory Premium that allow directory administrators to:
Enable users to request access to applications using a Get more applications tile in the Azure AD access panel
Set which applications users can request access to
Set whether or not an approval is required for users to be able to self-assign access to an application
Set who should approve the requests and manage access for each application
Today this capability is supported for all pre-integrated and custom apps that support federated or password-based
single sign-on in the Azure Active Directory application gallery, including apps like Salesforce, Dropbox, Google
Apps, and more. This article describes how to:
Configure self-service application access for end users, including configuring an optional approval workflow
Delegate access management for specific applications to the most appropriate people in your organization, and
enable them to use the Azure AD access panel to approve access requests, directly assign access to selected
users, or (optionally) set credentials for application access when password-based single sign-on is configured
Configuring self-service application access

To enable self-service application access and configured which applications can be added or requested by your end
users, follow the instructions below.
1: Sign into the Azure classic portal.
2: Under the Active Directory section, select your directory, then select the Applications tab.
3: Select the Add button, and use the gallery option to select and add an application.
4: After your app has been added, youll get the app Quick Start page. Click Configure Single Sign-On, select the
desired single sign-on mode, and save the configuration.
5: Next, select the Configure tab. To enable users to request access to this app from the Azure AD access panel, set
Allow self-service application access to Yes.
6: To optionally configure an approval workflow for access requests, set Require approval before granting
access to Yes. Then one or more approvers can be selected using the Approvers button.
An approver can be any user in the organization with an Azure AD account, and could be responsible for account
provisioning, licensing, or any other business process your organization requires before granting access to an app.
The approver could even be the group owner of one or more shared account groups, and can assign the users to
one of these groups to give them access via a shared account.
If no approval is required, then users will instantly get the application added to their Azure AD access panel. This
appropriate if the application has been set up for automatic user provisioning, or has been set up user-managed
password SSO mode where the user already has a user account and knows the password.
7: If the application has been configured to use password-based single sign-on, then an option for allowing the
approver to set the SSO credentials on behalf of each user is also available. See the following section on delegate
access management for more information.
8: Finally, the Group for Self-Assigned Users shows the name of the group that will be used to store the users
who have been granted or assigned access to the application. The access approver become the owner of this group.
If the group name shown does not exist, it will be created automatically. Optionally the group name can be set to
the name of an existing group.
9: Click Save at the bottom of the screen to save the configuration. Now users will be able to request access to this
app from the access panel.
10: To try the end user experience, sign into you organizations Azure AD access panel at
https://myapps.microsoft.com, preferably using a different account that isnt an app approver.
11: Under the Applications tab, click the Get more applications tile. This displays a gallery of all of the
applications that have been enabled for self-service application access in the directory, with the ability to search and
filter by app category on the left.
12: Clicking on an app kicks off the request process. If no approval process is required, then the application will be
immediately added under the Applications tab after a short confirmation. If approval is required, then you will see
a dialog indicating this, and an email will be send to the approvers. (Quick note: You need to be signed into the
access panel as a non-approver to see this request process).
13: The email directs the approver to sign into the Azure AD access panel and approve the request. Once the
request is approved (and any special processes you define have been performed by the approver), the user will
then see the application appear under their Applications tab where they can sign into it.
Delegated application access management
An application access approver can be any user in your organization who is the most appropriate person to
approve or deny access to the application in question. This user could be responsible for account provisioning,
licensing, or any other business process your organization requires before granting access to an app.
When configuring self-service application access described above, any assigned application Approvers will see an
additional Manage Applications tile in the Azure AD access panel, which shows them which applications that they
are the access administrator for. Clicking an app shows a screen with several options.
Approve Requests
The Approve Requests tile allows approvers to see any pending approvals specific to that app, and redirects to the
Approvals tab where the requests can be confirmed or denied. Note that the approver also receives automated
emails whenever a request is created that instructs them what to do.
Add Users
The Add Users tile allows approvers to directly grant selected users access to the application. Upon clicking this tile,
the approver sees a dialog allows them to view and search for users in their directory. Adding a user results in the
application being shown in those users Azure AD access panels or Office 365. If any manual user provisioning
process is required at the app before the user will be able to sign in, then the approver should perform this process
before assigning access.
Manage Users
The Manage Users tile allows approvers to directly update or remove which users have access to the application.
Configure Password SSO Credentials (if applicable )
The Configure tile is only shown if the application was configured by the IT administrator to use password-based
single sign on, and the administrator granted the approver the ability to set password SSO credentials as described
previously. When selected, the Approver is presented with several options for how the credentials will be
propagated to assigned users:
Users sign in with their own passwords In this mode, the assigned users know what their usernames and
passwords are for the application, and will be prompted to enter them upon their first sign-in to the application.
This corresponds to the password SSO case where the users manage credentials.
Users are automatically signed in using separate accounts that I manage In this mode, the assigned
users not be required to enter or know their app-specific credentials when signing into the application. Instead,
the approver sets the credentials for each user after assigning access using the Add User tile. When the user
clicks on the application in their access panel or Office 365, they will be automatically signed in using the
credentials set by the approver. This corresponds to the password SSO case where the administrators manage
credentials.
Users are automatically signed in using a single account that I manage - This is a special case, and is
appropriate to use when all assigned users need to be granted access using a single shared account. The most
common use case for this is social media applications, where an organization has a single company account
and multiple users need to make updates to that account. This also corresponds to the password SSO case
where the administrators manage credentials. However, after selecting this option, the approver will be
prompted to enter the username and password for the single shared account. Once completed, all assigned
users will be signed in using this account when clicking on the application in their Azure AD access panels or
Office 365.
Managing Certificates for Federated Single Sign-On
in Azure Active Directory
This article covers common questions related to the certificates that Azure Active Directory creates in order to
establish federated single sign-on (SSO) to your SaaS applications.
This article is only relevant to apps that are configured to use Azure AD Single Sign-On, as shown in the example
below:
How to Customize the Expiration Date for your Federation Certificate

By default, certificates are set to expire after two years. You can choose a different expiration date for your
certificate by following the steps below. The included screenshots use Salesforce for the sake of example, but these
steps can apply to any federated SaaS app.
1. In Azure Active Directory, on the Quick Start page for your application, click on Configure single sign-on.
2. Select Azure AD Single Sign-On, and then click Next.

3. Type in the Sign-On URL of your application, and select the checkbox for Configure the certificate used
for federated single sign-on. Then click Next.
4. On the next page, select Generate a new certificate, and select how long you'd like the certificate to be
valid for. Then click Next.
5. Next, click on Download certificate. To learn how to upload the certificate to your particular SaaS app,
click View configuration instructions.
6. The certificate won't be enabled until you select the confirmation checkbox at the bottom of the dialog and then
press submit.
How to Renew a Certificate that will Soon Expire

The renewal steps shown below should ideally result in no significant downtime for your users. The screenshots
used in this section feature Salesforce as an example, but these steps can apply to any federated SaaS app.
1. In Azure Active Directory, on the Quick Start page for your application, click on Configure Single Sign-On.
2. On the first page of the dialog, Azure AD Single Sign-On should already be selected, so click Next.
3. On the second page, select the checkbox for Configure the certificate used for federated single sign-
on. Then click Next.
4. On the next page, select Generate a new certificate, and select how long you'd like the new certificate to
be valid for. Then click Next.
5. Click on Download certificate. To successfully renew your certificate, you must perform the following two
steps:
Upload the new certificate to the SaaS app's single sign-on configuration screen. To learn how to do this
for your particular SaaS app, click View configuration instructions.
In Azure AD, Select the confirmation checkbox at the bottom of the dialog to enable the new
certificate, and then click Next to submit.
IMPORTANT
Single sign-on to the app will be disabled the moment either one of these two steps is completed, but it will
be enabled again once the second step is completed. Therefore, to minimize downtime, please prepare to
accomplish both steps within a short amount of time from each other.
Related Articles
Application access and single sign-on with Azure Active Directory
Troubleshooting SAML-Based Single Sign-On
Using SCIM to enable automatic provisioning of users
and groups from Azure Active Directory to
applications
Overview
Azure Active Directory 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 SCIM 2.0 protocol specification. Azure Active Directory
can send requests to create, modify and delete assigned users and groups to this Web service, which can then
translate those requests into operations upon the target identity store.
Figure: 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 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 will work with Azure AD of the box.
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 Azure ADs SCIM endpoint and
whatever API the application supports for user provisioning. To aid in the development of a SCIM endpoint, we
provide 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 Active Directory 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.
You should 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 above can be connected to Azure Active Directory using the
"custom" app feature in the Azure AD application gallery. Once connected, Azure AD runs a synchronization
process every 5 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:
1. In a web browser, launch the Azure management portal at https://manage.windowsazure.com.
2. Browse to Active Directory > Directory > [Your Directory] > Applications, and select Add > Add an
application from the gallery.
3. Select the Custom tab on the left, enter a name for your application, and click the checkmark icon to create an
app object.
1. In the resulting screen, select the second Configure account provisioning button.
2. In the Provisioning Endpoint URL field, enter the URL of the application's SCIM endpoint.
3. 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 Authentication Token (optional) field. Is 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 idenity provider can validate this Azure AD -issued token.
4. Click Next, and click on the Start Test button to have Azure Active Directory attempt to connect to the SCIM
endpoint. If the attempts fail, diagnostic information will be displayed.
5. If the attempts to connect to the application succeed, then click Next on the remaining screens, and click
Complete to exit the dialog.
6. In the resulting screen, select the third Assign Accounts button. In the resulting Users and Groups section,
assign the users or groups you want to provision to the application.
7. Once users and groups are assigned, click the Configure tab near the top of the screen.
8. Under Account Provisioning, confirm that the Status is set to On.
9. Under Tools, click Restart account provisioning to kick-start the provisioning process.
Note that 5-10 minutes may elapse before the provisioning process will begin to send requests to the SCIM
endpoint. A summary of connection attempts is provided on the applications Dashboard tab, and both a report of
provisioning activity and any provisioning errors can be downloaded from the directorys Reports tab.
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.
Heres 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 applications
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 5
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. See the README file
included with the sample for additional details
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 commands
below 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 command below, replacing with the IP or domain name of the Windows Machine.
FileAgnt.exe http://: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 will need 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:
1. In a web browser, launch the Azure management portal at https://manage.windowsazure.com.
2. Browse to Active Directory > Directory > [Your Directory] > Applications, and select Add > Add an
application from the gallery.
3. Select the Custom tab on the left, enter a name such as SCIM Test App, and click the checkmark icon to create
an app object. Note that the application object created is intend to represent the target app you would be
provisioning to and implementing single sign-on for, and not just the SCIM endpoint.
1. In the resulting screen, select the second Configure account provisioning button.
2. In the dialog, 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.
3. Click Next, and click on the Start Test button to have Azure Active Directory attempt to connect to the SCIM
endpoint. If the attempts fail, diagnostic information will be displayed.
4. If the attempts to connect to your Web service succeed, then click Next on the remaining screens, and click
Complete to exit the dialog.
5. In the resulting screen, select the third Assign Accounts button. In the resulting Users and Groups section,
assign the users or groups you want to provision to the application.
6. Once users and groups are assigned, click the Configure tab near the top of the screen.
7. Under Account Provisioning, confirm that the Status is set to On.
8. Under Tools, click Restart account provisioning to kick-start the provisioning process.
Note that 5-10 minutes may elapse before the provisioning process will begin to send requests to the SCIM
endpoint. A summary of connection attempts is provided on the applications Dashboard tab, and both a report of
provisioning activity and any provisioning errors can be downloaded from the directorys Reports tab.
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 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 figure below. 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 easily deploy a Web service that conforms to the SCIM specification, either hosted
within Internet Information Services, or any executable Common Language Infrastructure assembly. Requests to
that Web service will be translated into calls to the providers 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 libraries described above, 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;
}
}
}
It is important to note that 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, like so:
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 Common Language
Infrastructure 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 Azure Active Directorys 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 Directorys Graph Web
service, then the identifier of that service, 00000002-0000-0000-c000-000000000000, should be in the value of
the tokens aud claim.
Developers using the Common Language Infrastructure 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 services endpoints authenticated as
bearing a token issued by Azure Active Directory on behalf of a specified tenant, for access to Azure Active
Directorys 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 tenants
// 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

URN:IETF:PARAMS:SCIM:SCHEMAS:EXTENSION:ENTERPRISE:2.0:USE
AZURE ACTIVE DIRECTORY USER R
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
objectId id
proxyAddresses emails[type eq "other"].Value
User Provisioning and De-Provisioning

The figure below shows the messages that Azure Active Directory will send 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
Common Language Infrastructure libraries provided by Microsoft for building such services will translate those
requests into calls to the methods of a provider.
Figure: User provisioning and de-provisioning sequence

1: Azure Active Directory will query the service for a user with an externalId attribute value matching the
mailNickname attribute value of a user in Azure Active Directory. The query will be expressed as a Hypertext
Transfer Protocol request like this one, 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 will be translated into a call to the Query method of the services
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 case of the foregoing sample of a query for a user with a given value for the externalId attribute, values of
the arguments passed to the Query method will be as follows:
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 service for a user with an externalId attribute value matching the mailNickname
attribute value of a user in Azure Active Directory does not return any users, then Azure Active Directory will
request 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 services 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 the case of a request to provision a user, the value of the resource argument will be 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 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 will proceed by
requesting the current state of that user from the service with a request like this one:
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 will be translated into a call to the Retrieve method of the services 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 case of the foregoing 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 will be 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 will query 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. In the case of users, the only attribute of which the current value
will be 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 resources id attribute. Of course, the value of the id attribute is known to the
requestorit 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 will be translated into a call to the Query method of the services
provider. The value of the properties of the object provided as the value of the parameters argument will be 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 services provider. Here is the signature of that 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; }
<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 case of the foregoing example of a request to update a user, the object provided as the value of the patch
argument will have 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 Active Directory will send a
request like this one:
DELETE ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

implementing SCIM services, then the request will be translated into a call to the Delete method of the services
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 will have these property values in the case of
the foregoing 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 figure below shows the messages that Azure Active Directory will send 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 will be identified as
http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/Group.
Requests to retrieve groups will 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 will be requests about the members
attribute.
Figure: 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
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 Application Access and Single Sign-on in Azure Active
to enabling single sign-on, defining who has access to Directory
apps, 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

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
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 Android version of the Azure Azure Authenticator for Android
Authenticator app for policies involving multi-factor
authentication
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-
supports the SCIM protocol Enabled App
Get notified of provisioning failures Provisioning Notifications
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. This feature is currently in preview.
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 preview and how to Simple, Secure, Cloud Partner Integration with Azure AD
get 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
Preview
Detailed walkthrough of using Azure AD B2B

Collaboration Preview
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
The B2B Collaboration preview 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 Using the Office 365 App Launcher
website
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
Azure Multi-Factor Authentication
Conceptual overview of custom domain names in
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 to be owned by
the directory that contains the resource. Only a global administrator can perform domain management tasks in
Azure AD.
Domain names in Azure AD are globally unique. A domain name can be used by a single Azure AD. If one Azure AD
directory has verified a domain name, then no other Azure AD directory can verify or use that same domain name.
Initial and custom domain names

Every domain name in Azure AD is either an initial domain name, or a custom domain name.
Every Azure AD comes with an initial domain name in the form contoso.onmicrosoft.com. This third level domain
name, in this example contoso.onmicrosoft.com, was established when the directory was created, typically by the
admin who created the directory. The initial domain name for a directory can't be changed or deleted. The initial
domain name, while fully functional, is intended primarily to be used as a bootstrapping mechanism until a custom
domain name is verified.
In most production environments, a directory has at least one verified custom domain, such as contoso.com, and
it is that custom domain that is visible to end users. A custom domain name is a domain name that is owned and
used by that organization, such as contoso.com, for uses such as hosting its web site. This domain name is
familiar to employees because it is part of the user name that they use to sign in to the corporate network, or to
send and retrieve email.
Before it can be used by Azure AD, the custom domain name must be added to your directory and verified.
Verified and unverified domain names

The initial domain name for a directory is implicitly evaluated as verified by Azure AD. When an administrator adds
a custom domain name to an Azure AD, it is initially in an unverified state. Azure AD will not allow any directory
resources to use an unverified domain name. This ensures that only one directory can use a particular domain
name, and that the organization uses the domain name actually owns that domain name.
Azure AD verifies ownership of a domain name by looking for a particular entry in the domain name service (DNS)
zone file for the domain name. To verify ownership of a domain name, an admin gets the DNS entry from Azure
AD that Azure AD will look for, and adds that entry to the DNS zone file for the domain name. The DNS zone file is
maintained by the domain name registrar for that domain. The steps to verify a domain are shown in the article for
adding a custom domain to your Azure AD directory.
Adding a DNS entry to the zone file for the domain name does not affect other domain services such as email or
web hosting.
Federated and managed domain names

A custom domain name in Azure AD can be configured to give users a federated sign in experience between your
on-premises Active Directory and Azure AD. Configuring a domain for federation requires updates to privileged
resources in Azure AD and also to your Windows Server Active Directory. Configuring a federated domain must be
completed from Azure AD Connect or using PowerShell. Federating a custom domain cannot be initiated from the
Azure classic portal. Watch this video to learn about configuring AD FS for user sign in with Azure AD Connect.
Domains that are not federated are sometimes called managed domains. The initial domain for an Azure AD
directory is implicitly evaluated as a managed domain.
Primary domain names

The primary domain name for a directory is the domain name that is pre-selected as the default value for the
domain portion of the user name, when an administrator creates a new user in the Azure classic portal or another
portal such as the Office 365 admin portal. A directory can have only one primary domain name. An administrator
can change the primary domain name to be any verified custom domain that is not federated, or to the initial
domain.
Domain names in Azure AD and other Microsoft Online Services

A domain name must be verified in Azure AD before it can be used by another Microsoft Online Service such as
Exchange Online, SharePoint Online, and Intune. These other services typically require an administrator to add one
or more DNS entries that are particular to the service.
An Azure web app uses its own mechanism to verify ownership of a domain. A domain must be verified for use
with Azure AD even if it has been previously verified for use by an Azure web app in a subscription that relies on
that Azure AD. An Azure web app can use a domain name that has been verified in a different directory from the
directory that secures the web app.
Managing domain names

Domain management tasks can be completed from the Azure classic portal and from PowerShell. Many tasks can
be completed using the Azure AD Graph API (in public preview).
Adding and verifying a custom domain name
Managing domains in the Azure classic portal
Using PowerShell to manage domain names in Azure AD
Using the Azure AD Graph API to manage domain names in Azure AD
Add a custom domain name to Azure Active
Directory preview
You've got one or more domain names that your organization uses to do business, and your users sign in to your
corporate network using your corporate domain name. Using Azure Active Directory (Azure AD) preview, you can
add your corporate domain name to Azure AD as well. What's in the preview? This allows you to assign user
names in the directory that are familiar to your users, such as alice@contoso.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
How do I add a domain name?

3. On the directory-name blade, select Domain names.

4. On the directory-name - Domain names blade, select the Add command.
5. On the Domain name blade, 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.
6. On the domainname blade (that is, the blade that opens that has your new domain name in the title), get
the DNS entry information that Azure AD will use to verify that your organization owns the custom domain
name.
Now that you've added the domain name, Azure AD must verify that your organization owns the domain name.
Before Azure AD can perform this verification, you must add a DNS entry in the DNS zone file for the domain
name. This task is performed at the website for domain name registrar for the domain name.
Add the DNS entry at the domain name registrar for the domain
The next step to use your custom domain name with Azure AD is to update the DNS zone file for the domain. This
enables Azure AD to verify that your organization owns the custom domain name.
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. This DNS entry
enables Azure AD to verify your ownership of the domain. The DNS entry doesn't change any behaviors such as
mail routing or web hosting.
For help with this adding the DNS entry, read Instructions for adding a DNS entry at popular DNS registrars
Verify the domain name with 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 doesnt work the first time, try again later.
2. Select Browse, enter User Management in the text box, and then select Enter.
3. On the User management - Domain names blade, select the unverified domain name that you want to verify.
4. On the domainname blade (that is, the blade that opens that has your new domain name in the title), select
Verify to complete the verification.
Now you can assign user names that include your custom domain name.
Troubleshooting
If you can't verify a custom domain name, try the following. We'll start with the most common and work down to
the least common.
1. Wait an hour. DNS records need to propagate before Azure AD can verify the domain. This 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 cannot verify the domain name if the DNS entry is not present in the
DNS zone file, or if 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 was previously verified in another directory, it must be deleted there before it
can be verified in your new directory. To learn about deleting domain names, read Manage custom domain
names.
Add more custom domain names

If your organization uses multiple custom domain names, such as contoso.com and contosobank.com, you can
add them up to a maximum of 900 domain names. Use the same steps in this article to add each of your domain
names.
Next steps
Manage custom domain names
Add a custom domain name to Azure Active
Directory
You've got one or more domain names that your organization uses to do business, and your users sign in to your
corporate network using your corporate domain name. Now that you're using Azure Active Directory (Azure AD),
you can add your corporate domain name to Azure AD as well. This allows you to assign user names in the
directory that are familiar to your users, such as alice@contoso.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
NOTE
If you plan to configure your custom domain name to be used with Active Directory Federation Services (AD FS) or a
different security token service (STS) on your corporate network, follow the instructions in Add and configure a domain for
federation with Azure Active Directory. This is useful if you plan to synchronize users from your corporate directory to Azure
AD, and password hash sync does not meet your requirements.
Add a custom domain name to your directory

1. Sign in to the Azure classic portal with a user account that is a global administrator of your Azure AD directory.
2. In Active Directory, open your directory and select the Domains tab.
3. On the command bar, select Add. Enter the name of your custom domain, such as 'contoso.com'. Be sure to
include the .com, .net, or other top-level extension, and leave the checkbox for "single sign-on" (federation)
cleared.
4. Select Add.
5. On the second page of the Add Domain wizard, get the DNS entry that Azure AD will use to verify that your
organization owns the custom domain name.
Now that you've added the domain name, Azure AD must verify that your organization owns the domain name.
Before Azure AD can perform this verification, you must add a DNS entry in the DNS zone file for the domain
name. This task is performed at the website for domain name registrar for the domain name.
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. This DNS
entry enables Azure AD to verify your ownership of the domain. The DNS entry doesn't change any behaviors
such as mail routing or web hosting.
For help with this adding the DNS entry, read Instructions for adding a DNS entry at popular DNS registrars
If you still have the Add domain wizard open, select Verify on the third page of the wizard. When you select
Verify, Azure AD will look for the DNS entry in the DNS zone file for the domain. Azure AD can verify the domain
name only after the DNS records have propagated. This propagation often takes only seconds, but it can
sometimes take an hour or more. If verification doesnt work the first time, try again later.
If the Add domain wizard isn't still open, you can verify the domain in the Azure classic portal:
1. Sign in with a user account that is a global administrator of your Azure AD directory.
2. Open your directory and select the Domains tab.
3. Select the domain name that you want to verify and select Verify on the command bar.
4. Select Verify in the dialog box to complete the verification.
Now you can assign user names that include your custom domain name.
Troubleshooting
the least common.
1. Wait an hour. DNS records need to propagate before Azure AD can verify the domain. This 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 cannot verify the domain name if the DNS entry is not
present in the DNS zone file, or if 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.
single directory. If a domain name was previously verified in another directory, it must be deleted there before
it can be verified in your new directory. To learn about deleting domain names, read Manage custom domain
names.

names.
Next steps
Assign user names that include your custom domain name
Learn about domain management concepts in Azure AD
Show your company's branding when your users sign in
Use PowerShell to manage domain names in Azure AD
Add your custom domain name to Azure Active
Directory
You can configure a custom domain name, such as contoso.com, so that users in contoso.com can have a
federated single sign-on experience from your corporate network. If you already have Active Directory Federation
Services (AD FS) or a different federation server running on your corporate network, you can configure Azure AD to
use your custom domain name using the Azure AD Connect tool. You can also use Azure AD Connect to deploy a
new AD FS environment, and configure that for federated single sign-on to Azure AD.
If you do not have and do not plan to deploy AD FS or another federation server, follow these instructions: Add a
custom domain name to Azure Active Directory.
Add a custom domain name to your directory

2. In Active Directory, open your directory and select the Domains tab.
3. On the command bar, select Add, and then enter the name of your custom domain, such as 'contoso.com'. Be
sure to include the .com, .net, or other top-level extension.
4. Select the I plan to configure this domain for single sign-on with my local Active Directory checkbox.
5. Select Add.
Run the Azure AD Connect tool to get the DNS entry that Azure AD will use to verify the domain. You will see the
DNS entry 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.
1. Sign in to the website for domain name registrar for your domain name. If you don't have access to do this, ask
the person or team in your organization 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. This DNS entry
enables Azure AD to verify your ownership of the domain. The DNS entry doesn't change any behaviors such as
mail routing or web hosting.
For help with this step, read Instructions for adding a DNS entry at popular DNS registrars

To verify the domain, select Next on the Azure AD Domain step of the Azure AD Connect wizard. Azure AD will
look for the DNS entry in the DNS zone file for the domain. Azure AD only verify the domain name once the DNS
records have propagated. Propagation often takes only seconds, but it can sometimes take an hour or more. If
verification doesnt work the first time, try again later.
Then, proceed with the remaining steps in the Azure AD Connect wizard. This will synchronize users from your
Windows Server AD to Azure AD. Synchronized users in the domain that you configured for federation will be able
to get a federated single sign-on experience from your corporate network to Azure AD.
Troubleshooting
the least common.
1. Wait an hour. DNS records need to propagate before Azure AD can verify the domain. This 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 cannot verify the domain name if the DNS entry is not present in the
DNS zone file, or if 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.
single directory. If a domain name was previously verified in another directory, it must be deleted there before it
can be verified in your new directory. To learn about deleting domain names, read Manage custom domain
names.

names.
Next steps
Show your company's branding when your users sign in
Use PowerShell to manage domain names in Azure AD
Assign users to a custom domain
After you have added your custom domain to Azure Active Directory, you must add the user accounts for this
domain so that you can begin authenticating them.
Users synced in from a directory on your corporate network

If you have already set up a connection between your on-premises Active Directory and Azure Active Directory,
synchronization can populate the accounts. For more information on how to synchronize Azure Active Directory
with your on-premises Active Directory, see Integrating your on-premises identities with Azure Active Directory.
Users added and managed in the cloud

To change the domain for an existing user account:
1. Open the Azure classic portal using an account that is a global admin or a user admin.
3. Select the Users tab.
4. Select the user from the list.
5. Change the domain for the user, and then select Save.
This can also be done using Microsoft PowerShell or the Graph API.
Select a custom domain when creating a new user

1. Open the Azure classic portal using an account that is a global admin or a user admin.
3. Select the Users tab.
4. In the command bar, select Add.
5. When you add the user name, choose the custom domain from the domain list.
6. Select Save.
Next steps
Using custom domain names to simplify the sign-in experience for your users
Managing custom domain names in your Azure
resource in Azure Active Directory (Azure AD) preview can include a domain name that is already verified to be
owned by the directory that contains the resource. What's in the preview? 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. This
streamlines the process for an administrator to create new users in the portal. To change the primary domain
name:
3. On the directory-name blade, select Domain names.

4. On the directory-name - Domain names blade, select the domain name you would like to make the primary
domain name.
5. On the domainname blade (that is, the blade that opens that has your new domain name in the title), 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

You can add up to 900 custom domain names to each Azure AD directory. The process to add an additional custom
domain name is the same for the first custom domain name.
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 (in public preview).
Using Graph API to manage domain names in Azure AD
Next steps
Add custom domain names
Managing custom domain names in your Azure
Active Directory
resource in Azure Active Directory (Azure AD) can include a domain name that is already verified to be 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 for your directory. The primary domain is the default domain name for a new user when you create
a new user in the Azure classic portal, or other portals such as the Office 365 admin portal. This streamlines the
process for an administrator to create new users in the portal.
To change the primary domain name for your directory:
2. Select Active Directory on the left navigation bar.
4. Select the Domains tab.
5. Select the Change primary button on the command bar.
6. Select the domain that you want to be the new primary domain for your directory.
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

You can add up to 900 custom domain names to each Azure AD directory. The process to add an additional
custom domain name is the same for the first custom domain name.
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 in your directory.
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 include 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 (in public preview).
Using Graph API to manage domain names in Azure AD
Next steps
Learn about domain names in Azure AD
Add company branding to your sign-in page in the
To avoid confusion, many companies want to apply a consistent look and feel across all the websites and services
they manage. Azure Active Directory preview provides this capability by allowing you to customize the appearance
of the sign-in page with your company logo and custom color schemes. What's in the preview? 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.
If you want to show your company brand, colors and other customizable elements on this page, see the following
images to understand the difference between the two experiences.
The following screenshot shows and example for the Office 365 sign-in page on a desktop computer before a
customization:
The following screenshot shows and example for the Office 365 sign-in page on a desktop computer after a
customization:
Customizing the sign-in page

Typically, if you need browser-based access to your cloud apps and services that your organization subscribes to,
you use the sign-in page.
If you have applied changes to your sign-in page, it can take up to an hour for the changes to appear.
A branded sign-in page only appears when you visit a service with a tenant-specific URL such as
https://outlook.com/**contoso**.com, or https://mail.contoso.com.
When you visit a service with non-tenant specific URLs (e.g.: https://mail.office365.com), a non-branded sign-in
page appears. in this case, your branding appears once you have entered your user ID or you have selected 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 custom domain names.
Sign-in page branding doesnt carry over to the consumer sign in page of Microsoft. If you sign in with a Microsoft
account, you may see a branded list of user tiles rendered by Azure AD, but the branding of your organization does not
apply to the Microsoft account sign-in page.
On your sign-in page, the Keep me signed in checkbox allows a user to remain signed in when they close and re-
open their browser.
It does not effect session lifetime. You can hide the checkbox on the Azure Active Directory sign-in page. Whether
the checkbox is displayed depends on the setting of Keep me signed in disabled.
To hide the checkbox, configure this setting to Yes.
NOTE
Some features of SharePoint Online and Office 2010 depend on users being able to check this box. If you configure this
setting to hidden, your users may see additional and unexpected prompts to sign-in.
To add company branding to your directory:

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.
Next steps
Add language-specific company branding
Add language-specific company branding to your
sign-in page in the Azure Active Directory preview
they manage. Azure Active Directory preview provides this capability by allowing you to customize the appearance
of the sign-in page with your company logo and custom color schemes. What's in the preview? 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.
Customizing the sign-in page for another language

You can add language-specific elements to your custom sign-in page only if you have already created a custom
sign-in page as described in Add company branding to your sign-in page. You can configure one sign-in page per
directory with a default set of customizable elements. After youve configured the default set of page elements, you
can configure more versions for different locales. You can also mix and match various elements. For example, you
could:
Create a default Sign-in page image that works for all cultures, then create specific versions for English and
French. When you set your browsers to one of these two languages, the language-specific image appears, while
the default illustration appears for all other languages.
Configure different logos for your organization (for example, Japanese or Hebrew versions).
We recommend that you keep the number of language variations low, for maintenance and performance reasons.
To add company branding to your directory:
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
Add company branding to your sign-in page
Add company branding to your sign-in and Access
Panel pages
they manage. Azure Active Directory provides this capability by allowing you to customize the appearance of the
following web pages with your company logo and custom color schemes:
Sign-in page - This 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 either during a Home Realm
Discovery or to enter your credentials. The Home Realm Discovery allows the system to redirect federated
users to their on-premises STS (such as AD FS).
Access Panel page - The Access Panel is a web-based portal that allows you to view and launch the cloud-
based applications your Azure AD administrator has granted you access to. To access the Access Panel, use the
following URL: https://myapps.microsoft.com.
This topic explains how you can customize the sign-in page and the access panel page.
NOTE
Company branding is a feature that is available only if you upgraded to the Premium or Basic edition of Azure Active
Directory, or are an Office 365 user. For more information, see Azure Active Directory editions.
Customizing the sign-in page

Typically, if you need browser-based access to your cloud apps and services that your organization subscribes to,
you use the sign-in page.
If you have applied changes to your sign-in page, it can take up to an hour for the changes to appear.
A branded sign-in page only appears when you visit a service with a tenant-specific URL such as
https://outlook.com/**contoso**.com, or https://mail.contoso.com.
When you visit a service with non-tenant specific URLs (e.g.: https://mail.office365.com), a non-branded sign-in
page appears. in this case, your branding appears once you have entered your user ID or you have selected a user
tile.
NOTE
Your domain name must appear as Active in the Active Directory > Directory > Domains section of the Azure
classic portal where you have configured branding.
Sign-in page branding doesnt carry over to the consumer sign in page of Microsoft. If you sign in with a personal
Microsoft account, you may see a branded list of user tiles rendered by Azure AD, but the branding of your organization
does not apply to the Microsoft account sign-in page.
If you want to show your company brand, colors and other customizable elements on this page, see the following
images to understand the difference between the two experiences.
The following screenshot shows and example for the Office 365 sign-in page on a desktop computer before a
customization:
The following screenshot shows and example for the Office 365 sign-in page on a desktop computer after a
customization:
The following screenshot shows an example of the Office 365 sign-in page on a mobile device before a
customization:
The following screenshot shows an example of the Office 365 sign-in page on a mobile device after a
customization:
When you resize a browser window, the large Illustration, like the one shown previously, is often cropped to
accommodate different screen aspect ratios. With this in mind, you should try to keep the key visual elements in
the illustration so that they always appear in the top-left corner (top-right for right-to-left languages). This is
important because resizing typically occurs from the bottom-right corner going towards the top / left or from the
bottom towards the top.
The following picture shows how the illustration is cropped when the browser is resized to the left:
Here is how it appears after the browser is resized toward the top:
What elements on the page can I customize?
You can customize the following elements on the sign-in page:
PAGE ELEMENT LOCATION ON THE PAGE
Banner Logo Shown at the top-right of the page. Replaces the logo the
destination site you are signing in to displays (For example.
Office 365 or Azure).
PAGE ELEMENT LOCATION ON THE PAGE
Large Illustration / Background Color Shown at the left of the page. Replaces the image the
destination site you are signing in to displays. The
Background Color may be shown in place of the Large
Illustration on low bandwidth connections, or on narrow
screens.
Keep me signed-in Shown under the Password textbox.
Sign-in Page Text Shown above the page footer when you need to convey
helpful information before a sign-in with a work or school
account. For example, you may want to include the phone
number to your help desk, or a legal statement.
NOTE
All elements are optional. For example, if you specify a Banner Logo but no Large Illustration, the sign-in page shows your
logo and the illustration for the destination site (that is, the Office 365 California highway image).
On your sign-in page, the Keep me signed in checkbox allows a user to remain signed in when they close and
re-open their browser. It does not effect session lifetime. You can hide the checkbox on the Azure Active Directory
sign-in page.
Whether the checkbox is displayed depends on the setting of Hide KMSI.
To hide the checkbox, configure this setting to Hidden.
NOTE
Some features of SharePoint Online and Office 2010 depend on users being able to check this box. If you configure this
setting to hidden, your users may see additional and unexpected prompts to sign-in.
You can also localize all elements on this page. Once youve configured a default set of customization elements,
you can configure more versions for different locales. You can also mix and match various elements. For example,
you can:
Create a default Large Illustration that works for all cultures, then create specific versions for English and
French. When you set your browsers to one of these two languages, the specific image appears, while the
default illustration appears for all other languages.
Configure different logos for your organization (e.g. Japanese or Hebrew versions).
Access panel page customization

The Access Panel page is essentially a portal page for quick access to the cloud apps you have been granted
access to by your administrator. On this page, your apps appear as clickable application tiles.
The following screenshot shows an example of an access panel page after customization.
Configure your directory with company branding
You can configure one default set of customizable elements per directory in the Azure classic portal. After the
defaults have been saved, an administrator can add localized versions of each element, for different languages /
locales. All customizable elements are optional.
For example, if you configure a default Banner Logo but no Large Illustration, the sign-in page displays your logo
in the upper-right corner. However the default illustration of the site is displayed.
Imagine the following configuration:
A default Banner Logo and Sign-In Page Text in English
A language-specific sign in Page Text for German
If your language preference is German, you get the default Banner Logo but the German text.
While you could technically configure a different set for each language supported by Azure AD, we recommend
that you keep the number of variations low, for maintenance and performance reasons.
To add company branding to your directory, perform the following steps:
1. Sign in to the Azure classic portal as an administrator of the directory you want to customize.
2. Select the directory you want to customize.
3. In the toolbar on the top, click Configure.
4. Click Customize Branding.
5. Modify the elements you want to customize. All fields are optional.
6. Click Save.
It can take up to an hour for new change you made to the sign-in page branding to appear.
To add language-specific company branding, perform the following steps:
5. Click Add branding for a specific language.
6. Select the language you want to customize the logo for, and then click Next.
7. Edit only the elements for which you want to configure language-specific overrides. All fields are optional. If a
field is left blank, then the custom default value is displayed instead (or the Microsoft default if a custom
default is not configured).
8. Click Save.
To remove company branding from your directory, perform the following steps:
5. On the Customize Branding page, select Edit Existing Branding Settings and then go to the next page.
6. Depending on which elements you want to remove, do one or more of the following:
a. Under Banner Logo, select Remove uploaded logo.
b. Under Tile Logo, select Remove uploaded logo.
c. Remove the text from all textboxes.
d. Click Next.
e. Remove the text from all textboxes.
7. Click Save to remove the elements.
8. If necessary, click Customize Branding again and repeat these steps for all language-specific branding that
needs to be removed. All branding settings have been removed when you click Customize Branding and see
the Customize Default Branding form with no existing settings configured.
Testing and examples

We recommend that you experiment with a test tenant before making changes in your production environment.
To verify whether your branding has been applied:
1. Open an InPrivate or Incognito browser session.
2. Visit https://outlook.com/contoso.com, replacing contoso.com with the domain youve customized.
This also works with domains that look like contoso.onmicrosoft.com.
To help you create effective customization sets, we have customized the following two fictitious sign-in pages:
http://aka.ms/aaddemo001
http://aka.ms/aaddemo002
To test the language-specific settings, you need to modify the default language preferences in your web browser
to a language you have set in your customization. In Internet Explorer, you configure this in the Internet Options
menu.
Customizable elements
Some customizable elements in Azure AD have multiple use cases. You can configure company logos once per
directory and is used on both, the sign-in and Access Panel pages. Some customizable elements are specific only
to the sign-in page. The following table provides details for the different customizable elements.
NAME DESCRIPTION CONSTRAINTS RECOMMENDATIONS
Banner Logo The Banner Logo is JPG or PNG Use your organizations
displayed on the sign-in full logo (including
page and the Access panel. 60x280 pixels pictogram and
10 KB logotype)
Keep it under 30 pixels
high to avoid
introducing scrollbars
on mobile devices
Keep it under 4 KB
Use a transparent PNG
(dont assume that the
sign-in page always has
a white background)
Tile Logo (currently not used in the JPG or PNG Keep it simple (no small
sign-in page) In the future, text), as this image may
this text may be used to 120x120 pixels be resized to 50%
replace the generic work or 10 KB
school account pictogram
in different places of the
experience.
Sign-in Page User Name (currently not used in the Unicode text, up to 50 Keep it short and simple
Label sign-in page) In the future, characters
this text may be used to Ask your users how
replace the generic work or Plain text only (no links they usually refer to the
school account string in or HTML tags) work or school account
different places of the you provide them with.
experience. You can set it to
something like Contoso
account or Contoso ID.
Sign-in Page Text This boilerplate text Unicode text, up to 256 Keep it under 250
appears below the sign-in characters characters (approximately 3
page form and can be used lines of text)
to communicate additional Plain text only (no links
instructions, or where to get or HTML tags)
help and support.
NAME DESCRIPTION CONSTRAINTS RECOMMENDATIONS
Sign-in Page Illustration The illustration is a large JPG or PNG 1420x1200 pixels
image that is displayed on
the sign-in page to the left 1420x1200 Important: Keep it as
of the sign-in page form. small as possible, ideally
500 KB under 200 KB. If this
image is too large, the
performance of the
Sign-in page is impacted
when the image isnt
cached
This image is often
cropped, to
accommodate different
screen ratios. Keep the
primary visual elements
in the top left corner
(top right for RTL
languages), because
resizing occurs from the
bottom/right corner,
going towards the top /
left, as the browser
window shrinks.
Sign-in Page Background The sign-in page Must be an RGB color in The background color
Color background color is used in hexadecimal form (example: may be shown in place
the area to the left of the #FFFFFF) of the large Illustration
sign-in page form. on low-bandwidth
connections
We suggest picking the
primary color of the
Banner Logo
Next Steps
Administer your Azure AD directory
What is an Azure AD tenant?

In the physical workplace, the word tenant can be defined as a group or company that occupies a building. For
instance, your organization may own office space in a building. This building may be on a street with several
other organizations. Your organization would be considered a tenant of that building. This building is an asset of
your organization and provides security and ensures that you can conduct business safely. It also is separated
from the other businesses on your street. This ensures that your organization and the assets therein are isolated
from other organizations.
In the cloud-enabled workplace, a tenant can be defined as a client or organization that owns and manages a
specific instance of that cloud service. With the identity platform provided by Microsoft Azure, a tenant is simply
a dedicated instance of Azure Active Directory (Azure AD) that your organization receives and owns 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 from co-mingling. This means 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 Microsofts cloud
services, including:
Azure
Microsoft Office 365
Microsoft Dynamics CRM Online
Microsoft Intune
You will 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.
NOTE
After you sign up for your first service, we recommend that you use the same administrator account associated with your
organization when you sign up for other Microsoft cloud services.
The first time you sign up for a Microsoft cloud service, you are prompted to provide details about your
organization and your organizations Internet domain name registration. This information is then used to create
a new Azure AD directory instance for your organization. That same directory is used to authenticate sign in
attempts when you subscribe to multiple Microsoft cloud services.
The additional services fully leverage any existing user accounts, policies, settings or on-premises directory
integration you configure to help improve efficiency between your organizations identity infrastructure on-
premises and Azure AD.
For example, if you originally signed up for a Microsoft Intune subscription and completed the steps necessary to
further integrate your on-premises Active Directory with your Azure AD directory by deploying directory
synchronization and/or single sign-on servers, you can sign up for another Microsoft cloud service such as Office
365 which can also leverage the same directory integration benefits you now use with Microsoft Intune.
For more information about integrating your on-premises directory with Azure AD, see Directory integration.
Associate an 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. Sign in to the Azure Management Portal using your work or school
account. The Management Portal returns a message that it was unable to find any subscriptions for that account.
Select Sign Up For Azure, and your directory will be available for administration within the portal. For more
information, see Manage the directory for your Office 365 subscription in Azure.
For a video about common usage questions for Azure AD, see Azure Active Directory - Common Sign-up, sign-in
and usage questions.
Create an Azure AD directory by signing up for a Microsoft cloud service as an organization
If you dont yet have a subscription to a Microsoft cloud service, use one of the links below to sign up. The act of
signing up for your first service will create an Azure AD directory automatically.
Microsoft Azure
Office 365
Microsoft Intune
Manage an Azure -provisioned Default directory
Today, a directory is automatically created when you sign up for Azure and your subscription is associated with
that directory. But if you originally signed up for Azure before October 2013, a directory was not automatically
created. In that case, Azure may have backfilled for your account by provisioning a Default directory for it. Your
subscription was then associated with that Default directory.
Backfilling of directories was done in October 2013 as part of an overall improvement to the security model for
Azure. It helps offer organizational identity features to all Azure customers and ensures that all Azure resources
are accessed in the context of a user in directory. You cannot use Azure without a directory. To achieve that, any
user who was signed up prior to July 7, 2013 but did not have a directory had to have one created. If you had
already created a directory, then your subscription was associated with that directory.
There are no costs for using Azure AD. The directory is a free resource. There is an additional Azure Active
Directory Premium tier that is licensed separately and provides additional features such as company branding
and self-service password reset.
To change the display name of your directory, click the directory in the portal and click Configure. As explained
later in this topic, you can add a new directory or delete a directory that you no longer need. To associate your
subscription with a different directory, click the Settings extension in the left navigation, and at the bottom of the
Subscriptions page, click Edit Directory. You can also create a custom domain using a DNS name that you
have registered instead of the default *.onmicrosoft.com domain, which may be preferable with a service such as
SharePoint Online.
How can I manage directory data

As an administrator of one or more Microsoft cloud service subscriptions, you can either use the Azure
Management Portal, the Microsoft Intune account portal, or the Office 365 Admin Center to manage your
organizations directory data. You can also download and run Microsoft Azure Active Directory Module for
Windows PowerShell cmdlets to help you manage data stored in Azure AD.
From either of these portals (or cmdlets), you can:
Create and manage user and group accounts
Manage related cloud service(s) your organization subscribes to
Set up on-premises integration with your directory service
The Azure Management Portal, 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
organizations directory, as shown in the following illustration. In this way, portals (or cmdlets) act as a front-end
interface that pull in and/or modify your directory data.
These account portals and the associated Azure AD PowerShell cmdlets used to manage users and groups are
built on top of the Azure AD platform.
When you make a change to your organizations data using any of the portals (or cmdlets) while signed in under
the context of one of these services, the change will also be shown in the other portals the next time you sign-in
under the context of that service because this data is shared across the Microsoft cloud services you are
subscribed to. For example, if you used the Office 365 Admin Center to block a user from signing in, that action
will block the user from signing in to any other service that your organization is currently subscribed to. If you
were to pull up that same users account under the context of the Microsoft Intune account portal you will see
that the user is blocked.
How can I add and manage multiple directories?
You can add an Azure AD directory in the Azure Management Portal. Select the Active Directory extension on
the left and click Add.
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, described below. If you use a
custom domain 'contoso.com' with one directory, it cannot be used with any other directory.
Administrative independence. If a non-administrative user of directory 'Contoso', creates a test
directory 'Test' then:
The directory sync tool, to synchronize data with a single AD forest.
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 which
created 'Test.'
And if you change (add 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 independently to get data
synchronized from a single instance of either:
The directory sync tool, to synchronize data with a single AD forest
The Azure Active Directory Connector for Forefront Identity Manager, to synchronize data with one or
more on-premises forests, and/or non-AD data sources.
Also note that 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 can I delete an Azure AD directory?

A global administrator can delete an Azure AD directory from the portal. When a directory is deleted, all
resources contained in the directory are also deleted; so you should be sure you dont 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 his or her 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.
Conditions that must be met to delete an Azure AD directory

Azure AD requires that certain conditions are met to delete a directory. This reduces risk that deletion of a
directory would negatively impact 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 became unintentionally deleted, then
users could not access the Azure resources for that subscription.
The following conditions are checked:
The only user in the directory is the global administrator who will delete the directory. Any other users must
be deleted before the directory can be deleted. If users are synchronized from on-premises, then sync will
need to be turned off, and the users must be deleted in the cloud directory by using the Management Portal
or the Azure module for Windows PowerShell. 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.
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 cannot delete a directory if another user has associated a subscription with it. To associate your
subscription with a different directory, sign in to the Azure Management Portal and click Settings in the left
navigation. Then on the bottom of the Subscriptions page, click Edit Directory. For more information about
Azure subscriptions, see How Azure subscriptions are associated with Azure AD.
NOTE
If the user is signed in with a work or school account, the user must not be attempting to delete his or her 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.
No Multi-Factor Authentication providers can be linked to the directory.
Azure AD Forum
Azure Multi-Factor Authentication Forum
Stackoverflow
Manage Azure AD using Windows PowerShell
Assigning administrator roles in Azure AD
Add and manage multiple Azure Active Directory
directories
In Azure Active Directory (Azure AD), each directory is a fully independent resource: 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, described below. If you use a custom domain 'contoso.com' with one directory,
it cannot be used with any other directory.
Administrative independence
If a non-administrative user of directory 'Contoso' creates a test directory 'Test' then:
By default, the user who creates a directory is added as an external user in that new directory, and assigned the
global administrator role in that directory.
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' if they control the user account which created 'Test.'
If you change (add or remove) an administrator role for a user in one directory, the change does not affect any
administrator role that the user might have in another directory.
Synchronization independence
You can configure each Azure AD directory independently to get data synchronized from a single instance of either:
The Directory Synchronization (DirSync) tool, to synchronize data with a single AD forest.
The Azure Active Directory 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 directory

To add an Azure AD directory in the Azure classic portal, select the Azure Active Directory extension on the left and
tap Add.
NOTE
Unlike other Azure resources, your directories are not child resources of an Azure subscription. If you cancel or allow your
Azure subscription to expire, you can still access your directory data using Azure PowerShell, the Azure Graph API, or other
interfaces such as the Office 365 Admin Center. You can also associate another subscription with the directory.
For a broad overview of Azure AD licensing issues and best practices, see What is Azure Active Directory licensing?.
Manage the directory for your Office 365
subscription in Azure
This article describes how to manage a directory that was created for an Office 365 subscription, using the Azure
classic portal. You must be either the Service Administrator or a co-administrator of an Azure subscription to sign
in to the Azure classic portal. If you dont yet have an Azure subscription, you can sign up for a free 30-day trial
today and deploy your first cloud solution in under 5 minutes, using this link. Be sure to use the work or school
account that you use to sign in to Office 365.
After you complete the Azure subscription, you can sign in to the Azure classic portal and access Azure services.
Click the Active Directory extension to manage the same directory that authenticates your Office 365 users.
If you do already have an Azure subscription, the process to manage an additional directory is also straightforward.
For example, Michael Smith might have an Office 365 subscription for Contoso.com. He also has an Azure
subscription that he signed up for by using his Microsoft account, msmith@hotmail.com. In this case, he manages
two directories.
SUBSCRIPTION OFFICE 365 AZURE
Display name Contoso Default Azure Active Directory (Azure

AD) directory
Domain name contoso.com msmithhotmail.onmicrosoft.com
He wants to manage the user identities in the Contoso directory while he is signed in to Azure using his Microsoft
account, so that he can enable Azure AD features such as multifactor authentication. The following diagram may
help to illustrate the process.
In this case, the two directories are independent of each other.
To manage two independent directories

In order for Michael Smith to manage both directories while he is signed in to Azure as msmith@hotmail.com, he
must complete the following steps:
NOTE
These steps can be completed only when a user is signed in with a Microsoft account. If the user is signed in with a work or
school account, the option to Use existing directory isn't available. A work or school account can be authenticated only by
its home directory (that is, the directory where the work or school account is stored, and that the business or school owns).
1. Sign in to the Azure classic portal as msmith@hotmail.com.

2. Click New > App services > Active Directory > Directory > Custom Create.
3. Click Use existing directory and select the I am ready to be signed out now checkbox.
4. Sign in to the Azure classic portal as global admin of Contoso.onmicrosoft.com (for example,
msmith@contoso.com).
5. When prompted to Use the Contoso directory with Azure?, click Continue.
6. Click Sign out now.
7. Sign in to the Azure classic portal as msmith@hotmail.com. The Contoso directory and the Default directory
appear in the Active Directory extension.
After completing these steps, msmith@hotmail.com is a global administrator in the Contoso directory.
To administer resources as the global admin

Now lets suppose that Jane Doe needs administer websites and database resources that are associated with the
Azure subscription for msmith@hotmail.com. Before she can do that, Michael Smith needs to complete these
additional steps:
1. Sign in to the Azure classic portal using the Service Administrator account for the Azure subscription (in this
example, msmith@hotmail.com).
2. Transfer the subscription to the Contoso directory: click Settings > Subscriptions > select the subscription >
Edit Directory > select Contoso (Contoso.com). As part of the transfer, any work or school accounts that are
co-administrators of the subscription are removed.
3. Add Jane Doe as co-administrator of the subscription: click Settings > Administrators > select the
subscription > Add > type JohnDoe@Contoso.com.
Next steps
For more information about the relationship between subscriptions and directories, see How a subscription is
associated with a directory.
What is Self-Service Signup for Azure?
This topic explains the self-service signup process and how to take over a DNS domain name.
Why use self-service signup?

Get customers to services they want faster.
Create email-based offers for a service.
Create email-based signup flows which quickly allow users to create identities using their easy-to-remember
work email aliases.
Unmanaged Azure directories can be made into managed directories later and be reused for other services.
Terms and Definitions

Self-service sign up: This is the method by which a user signs up for a cloud service and has an identity
automatically created for them in Azure Active Directory (Azure AD) based on their email domain.
Unmanaged Azure 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.
User experience
For example, let's say a user whose email is Dan@BellowsCollege.com receives sensitive files via email. The files
have been protected by Azure Rights Management (Azure RMS). But Dan's organization, Bellows College, has not
signed up for Azure RMS, nor has it deployed Active Directory RMS. In this case, Dan can sign up for a free
subscription to RMS for individuals in order to read the protected files.
If Dan is the first user with an email address from BellowsCollege.com to sign up for this self-service offering, then
an unmanaged directory will be created for BellowsCollege.com in Azure AD. If other users from the
BellowsCollege.com domain sign up for this offering or a similar self-service offering, they will also have email-
verified user accounts created in the same unmanaged directory in Azure.
Admin experience
An admin who owns the DNS domain name of an unmanaged Azure directory can take over or merge the directory
after proving ownership. The next sections explain the admin experience in more detail, but here's a summary:
When you take over an unmanaged Azure directory, you simply become the global administrator of the
unmanaged directory. This is sometimes called an internal takeover.
When you merge an unmanaged Azure directory, you add the DNS domain name of the unmanaged directory
to your managed Azure directory and a mapping of users-to-resources is created so users can continue to
access services without interruption. This is sometimes called an external takeover.
What gets created in Azure Active Directory?

directory
An Azure Active Directory directory for the domain is created, one directory per domain.
The Azure AD directory has no global admin.
Users
For each user who signs up, a user object is created in the Azure AD directory.
Each user object is marked as external.
Each user is given access to the service that they signed up for.
How do I claim a self-service Azure AD directory for a domain I own?
You can claim a self-service Azure AD directory by performing domain validation. Domain validation proves you
own the domain by creating DNS records.
There are two ways to do a DNS takeover of an Azure AD directory:
internal takeover (Admin discovers an unmanaged Azure directory, and wants to turn into a managed directory)
external takeover (Admin tries to add a new domain to their managed Azure directory)
You might be interested in validating that you own a domain because you are taking over an unmanaged directory
after a user performed self-service signup, or you might be adding a new domain to an existing managed directory.
For example, you have a domain named contoso.com and you want to add a new domain named contoso.co.uk or
contoso.uk.
What is domain takeover?

This section covers how to validate that you own a domain
What is domain validation and why is it used?
In order to perform operations on a directory, Azure AD requires that you validate ownership of the DNS domain.
Validation of the domain allows you to claim the directory and either promote the self-service directory to a
managed directory, or merge the self-service directory into an existing managed directory.
Examples of domain validation

There are two ways to do a DNS takeover of a directory:
internal takeover (For example, an admin discovers a self-service, unmanaged directory, and wants to turn into
managed directory)
external takeover (For example, a admin tries to add a new domain to a managed directory)
Internal Takeover - promote a self-service, unmanaged directory to be a managed directory
When you do internal takeover, the directory gets converted from an unmanaged directory to a managed directory.
You need to complete DNS domain name validation, where you create an MX record or a TXT record in the DNS
zone. That action:
Validates that you own the domain
Makes the directory managed
Makes you the global admin of the directory
Let's say an IT administrator from Bellows College discovers that users from the school have signed up for self-
service offerings. As the registered owner of the DNS name BellowsCollege.com, the IT administrator can validate
ownership of the DNS name in Azure and then take over the unmanaged directory. The directory then becomes a
managed directory, and the IT administrator is assigned the global administrator role for the BellowsCollege.com
directory.
External Takeover - merge a self-service directory into an existing managed directory
In an external takeover, you already have a managed directory and you want all users and groups from an
unmanaged directory to join that managed directory, rather than own two separate directories.
As an admin of a managed directory, you add a domain, and that domain happens to have an unmanaged directory
associated with it.
For example, let's say you are an IT administrator and you already have a managed directory for Contoso.com, a
domain name that is registered to your organization. You discover that users from your organization have
performed self-service sign up for an offering by using email domain name user@contoso.co.uk, which is another
domain name that your organization owns. Those users currently have accounts in an unmanaged directory for
contoso.co.uk.
You don't want to manage two separate directories, so you merge the unmanaged directory for contoso.co.uk into
your existing IT managed directory for contoso.com.
External takeover follows the same DNS validation process as internal takeover. Difference being: users and
services are remapped to the IT managed directory.
What's the impact of performing an external takeover?
With an external takeover, a mapping of users-to-resources is created so users can continue to access services
without interruption. Many applications, including RMS for individuals, handle the mapping of users-to-resources
well, and users can continue to access those services without change. If an application does not handle the mapping
of users-to-resources effectively, external takeover may be explicitly blocked to prevent users from a poor
experience.
directory takeover support by service
Currently the following services support takeover:
RMS
The following services will soon be supporting takeover:
PowerBI
The following do not and require additional admin action to migrate user data after an external takeover.
SharePoint/OneDrive
How to perform a DNS domain name takeover

You have a few options for how to perform a domain validation (and do a takeover if you wish):
1. Azure Management Portal
A takeover is triggered by doing a domain addition. If a directory already exists for the domain, you'll have
the option to perform an external takeover.
Sign in to the Azure portal using your credentials. Navigate to your existing directory and then to Add
domain.
2. Office 365
You can use the options on the Manage domains page in Office 365 to work with your domains and DNS
records. See Verify your domain in Office 365.
3. Windows PowerShell
The following steps are required to perform a validation using Windows PowerShell.
STEP CMDLET TO USE
Create a credential object Get-Credential

STEP CMDLET TO USE
Connect to Azure AD Connect-MsolService
get a list of domains Get-MsolDomain
Create a challenge Get-MsolDomainVerificationDns
Create DNS record Do this on your DNS server
Verify the challenge Confirm-MsolEmailVerifiedDomain
For example:
1. Connect to Azure AD using the credentials that were used to respond to the self-service offering:
import-module MSOnline
2. Get a list of domains:

Get-MsolDomain
3. Then 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.
How do I control self-service settings?

Admins have two self-service controls today. They can control:
Whether or not users can join the directory via email.
Whether or not users can license themselves for applications and services.
How can I control these capabilities?
An admin can configure these capabilities using these 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 sign up. 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 sign up. For
example, the following command will allow users to perform self-service sign up, 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 cannot
perform self-service sign up):
Set-MsolCompanySettings -AllowEmailVerifiedUsers $false -AllowAdHocSubscriptions $true
The following flowchart explains all the different combinations for these parameters and the resulting conditions
for the directory and self-service sign up.
For more information and examples of how to use these parameters, see Set-MsolCompanySettings.
See Also
How to install and configure Azure PowerShell
Azure PowerShell
Azure Cmdlet Reference
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 users 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 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.
When you enable Enterprise State Roaming, your organization will be automatically granted licenses for a free,
limited-use subscription to Azure Rights Management. This free subscription is limited to encrypting and
decrypting enterprise settings and application data synced by the Enterprise State Roaming service; you must have
a paid subscription to use the full capabilities of Azure Rights Management.
After obtaining a Premium Azure AD subscription, follow these steps to enable Enterprise State Roaming:
1. Login to the Azure classic portal.
2. On the left, select ACTIVE DIRECTORY, and then select the directory for which you want to enable Enterprise
State Roaming.
3. Go to the CONFIGURE tab on the top.
4. Scroll down the page and select USERS MAY SYNC SETTINGS AND ENTERPRISE APP DATA, and then click
SAVE.
For a Windows 10 device to roam settings with the Enterprise State Roaming service, the device must authenticate
using an Azure AD identity. For devices that are joined to Azure AD, the users primary login is the Azure AD
identity, so no additional configuration is required. For devices that use a traditional on-premises Active Directory,
the IT admin must connect the domain-joined devices to Azure AD for Windows 10 experiences.
Sync data storage

Enterprise State Roaming data is hosted in one or more Azure regions that best aligns 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, customers who have their
country/region value set to one of EMEA countries like France or Zambia will have their data hosted in one or
of the Azure regions within Europe. Customers who set their country/region value in Azure AD to one of North
America countries like United States or Canada will have their data hosted in one or more of the Azure regions
within the US. Customers who set their country/region value in Azure AD to one of APAC countries like Australia
or New Zealand will have their data hosted in one or more of the Azure regions within Asia. South American
countries and Antarctica data will be hosted in 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 data storage location, please file a ticket with Azure support.
Manage Enterprise State Roaming

Azure AD global administrators can enable and disable Enterprise State Roaming in the Azure classic portal.
Global administrators can limit settings sync to specific security groups.

Global admins can also view a per-user device sync status report by selecting a particular user in the Active
Directory instance USERS list and clicking on DEVICES tab and selecting view Devices syncing settings and
enterprise app data.
Data retention
Data synced to Azure via Enterprise State Roaming will be retained indefinitely unless a manual delete operation is
performed or the data in question is determined to be stale.
Explicit deletion: The data is deleted when an Azure admin deletes a user or a directory or an admin requests
explicitly that data is to be deleted.
User deletion: When a user is deleted in Azure AD, the user account roaming data will be marked for deletion
and will be deleted between 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 will be marked for deletion and will be deleted between 90 to 180 days.
On request deletion: If the Azure AD admin wants to manually delete a specific users 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 (e.g., an application is removed from the device, or a settings
group such as Theme is disabled for all of a users devices), then that collection will become 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 has been permanently
deleted, it will not be recoverable. However, its important to note that the settings data will only be deleted from
Azure, not the end-user device. If any device later reconnects to the Enterprise State Roaming service, the settings
will again be 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 users 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 users 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 users
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: all other X X

Edge settings
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)
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. Its 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 apps 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 apps 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 classic portal and select an Azure AD tenant. The GUID
for the tenant is in the URL in the address bar of your browser. For example:
https://manage.windowsazure.com/YourAccount.onmicrosoft.com#Workspaces/ActiveDirectoryExtension/Directory/Tenant
GUID/directoryQuickStart
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 thats 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 users 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 Microsofts 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, as
well as provides a list of known issues.
Preliminary steps for troubleshooting

Before beginning 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 domain-joined and registered with Azure AD .
3. In the Azure Active Directory portal, Enterprise State Roaming is enabled for the directory under Configure
> Devices > Users May Sync Settings and Enterprise App Data. Either all users are selected, or the user is
enabled for syncing through the selected option, and included in the security group.
4. The user has an Azure Active Directory Premium subscription assigned to them.
5. The device has been restarted, and the user has logged in after Enterprise State Roaming has been enabled.

If you cannot solve your issue with the guidance below, you can contact our support engineers. When you contact
them, it is recommended to 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 log into the device? How is the user logging
into 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 will help us to 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, logon
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 5 minutes.
Locking and unlocking the screen (Win + L) can help trigger a sync.
You must be using the same logon 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: The settings page has the toggles grayed out, and instead of seeing an account, you see the text
Some Windows features are only available if you are using a Microsoft account or work account. This issue may
arise for devices that have been set up to be domain-joined and registered to Azure AD, but the device has not
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. To verify this issue, follow the steps in
verify the device registration status to check if this is the case.
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, as well
as confirm thumbprint, Azure AD settings URL, NGC status, and other information.
1. Open the command prompt un-elevated. 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 into the device before Enterprise State Roaming was enabled in the Azure Active Directory Portal. 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.
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, please 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.
Event ID 6065: 80070533 This user cant sign in because this account is currently disabled
In Event Viewer under the SettingSync/Debug logs, this error can be seen when the tenant did not automatically
have AzureRMS provisioned.
Recommended action
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 details, see the Enterprise State Roaming overview.
Related topics
Azure AD B2B collaboration preview: Simple, secure
cloud partner integration
As companies focus more on their core business, the need to partner with other businesses increases. Companies
need to easily and securely share resources (such as access to corporate applications) with their partners to
engage in effective collaboration. Azure Active Directory B2B collaboration supports your cross-company
relationships by enabling partners to selectively access your corporate applications and data using their self-
managed identities. Azure AD B2B collaboration is:
Simple: Each partner user uses an existing Azure AD account or one that is easily created during invitation
acceptance. You can provide this user with direct access to your chosen corporate app or a set of applications
through the App Access Panel.
Secure: Your admin controls all access to your corporate apps through your Azure AD directory. When
collaboration is terminated, partner users can be removed from your Azure AD and their access to your apps is
immediately revoked. Additionally, when the partner user leaves the partner organization, access is lost
automatically.
Seamless: The partner companies who need access to your corporate apps do not need to have Azure AD.
Azure AD B2B collaboration provides a simple user sign-up experience to provide these partners with
immediate access to your apps.
Check out the blog post announcing public preview and this deep dive video walking through Azure AD B2B
collaboration.
For a comparison of the use cases for Azure AD B2B collaboration, Azure AD B2C, and the Azure AD Multi-tenant
App, check out Comparing capabilities for managing external identities using Azure AD.
Related articles
Browse our other articles on Azure AD B2B collaboration:
How it works
Detailed walkthrough
CSV file format reference
External user token format
External user object attribute changes
Current preview limitations
Azure Active Directory B2B collaboration
Azure Active Directory (Azure AD) B2B collaboration lets you enable access to your corporate applications from
partner-managed identities. You can create cross-company relationships by inviting and authorizing users from
partner companies to access your resources. Complexity is reduced because each company federates once with
Azure Active Directory and each user is represented by a single Azure AD account. Security is increased if your
business partners manage their accounts in Azure AD because access is revoked when partner users are
terminated from their organizations, and unintended access via membership in internal directories is prevented.
For business partners who don't already have Azure AD, B2B collaboration has a streamlined sign-up experience to
provide Azure AD accounts to your business partners.
Your business partners use their own sign-in credentials, which frees you from managing an external partner
directory, and from the need to remove access when users leave the partner organization.
You manage access to your apps independently of your business partner's account lifecycle. This means, for
example, that you can revoke access without having to ask the IT department of your business partner to do
anything.
Capabilities
B2B collaboration simplifies management and improves security of partner access to corporate resources including
SaaS apps such as Office 365, Salesforce, Azure Services, and every mobile, cloud and on-premises claims-aware
application. B2B collaboration enables partners manage their own accounts and enterprises can apply security
policies to partner access.
Azure Active Directory B2B collaboration is easy to configure with simplified sign-up for partners of all sizes even if
they dont have their own Azure Active Directory via an email-verified process. It is also easy to maintain with no
external directories or per partner federation configurations.
B2B collaboration process

1. Azure AD B2B collaboration allows a company administrator to invite and authorize a set of external users
by uploading a comma-separated values (CSV) file of no more than 2000 lines to the B2B collaboration
portal.
2. The portal will send email invitations to these external users.
3. The invited user will either sign in to an existing work account with Microsoft (managed in Azure AD), or get a
new work account in Azure AD.
4. Once signed in, the user will be redirected to the app that was shared with them.
Invitations to consumer email addresses (for example, Gmail or comcast.net) are not currently supported.
For more on how B2B collaboration works, check out this video.
Next steps
Browse our other articles on Azure AD B2B collaboration.
What is Azure AD B2B collaboration?
How it works
Azure AD B2B collaboration preview: How it works
Azure AD B2B collaboration is based on an invite and redeem model. You provide the email addresses of the
parties you want to work with, along with the applications you want them to use. Azure AD sends them an email
invite with a link. The partner user follows the link and is prompted to sign in using their Azure AD account or sign
up for a new Azure AD account.
1. Your admin invites partner users by uploading a structured .csv file using the Azure portal.
2. The portal sends invite emails to these partner users.
3. The partner users click the link in the email, and are prompted to sign in using their work credentials (if they're
already in Azure AD), or to sign up as an Azure AD B2B collaboration user.
4. Partner users are redirected to the application they were invited to, where they now have access.
Directory operations
Partner users exist in your Azure AD as external users. This means your admin can provision licenses, assign group
membership, and further grant access to corporate apps through the Azure portal or using Azure PowerShell just
like for users in your company.
While a paid Azure AD subscription (Basic or Premium) is not necessary to use Azure AD B2B, tenants who do
have a paid Azure AD subscription (Basic or Premium) receive the following additional benefits:
Admins can assign groups to apps, providing for simpler management of invited user access.
Admin tenant branding is used to brand the invitation emails and redemption experience, providing more
context to invited partner users.
Related articles
Browse our other articles on Azure AD B2B collaboration
Comparing capabilities for managing external
identities using Azure Active Directory
In addition to managing mobile workforce access to SaaS apps, Azure Active Directory (Azure AD) can help your
organization share resources with business partners and deliver applications to businesses and consumers.
Developing applications for businesses

Do you provide a service or application, such as a payroll service, to businesses? Azure AD provides the identity
platform that allows you to build applications that seamlessly integrate with millions of organizations that have
already configured Azure AD as part of deploying Office 365 or other enterprise services.
Example: A pharmaceutical distributor provides medical supplies and information systems to the healthcare
industry. They needed to field an analytics application to medical practices and wanted customers to manage their
own identities. This company chose Azure AD as the identity platform for their practice management application,
providing Azure AD identities to their customers at sign up when necessary. For more information, see Azure
Active Directory developer's guide.
Enabling business partner access to your corporate resources

Do you have business partners or others outside your company who need to access your enterprise resources,
such as a SharePoint site or your ERP system? Azure AD enables admins to grant external users (who may or may
not exist in Azure AD) single sign on access to corporate applications. This improves security as users lose access
when they leave the partner organization, while you control access policies within your organization. This also
simplifies administration as you dont need to manage an external partner directory or per partner federation
relationships.
Example: An imaging company provides retailers with photo imaging services and operates the largest retail
network of printing kiosks. They chose Azure AD to enable thousands of users at their retail business partners to
use their own credentials to download the latest partner marketing materials and reorder photo processing
supplies from the companys supplier extranet. For more information, see Azure AD B2B collaboration.
Developing applications for consumers

Do you need to securely and cost-effectively publish online applications, such as a retail store front, to millions of
consumers? Azure AD provides a platform enabling social as well as username/password sign-in, branded self-
service sign up, and self-service password reset for consumers of your application. This increases convenience for
your consumers while reducing load on your developers.
Example: The #1 sports franchise in the world needed to directly engage with its 450 million fans. To do this, they
built a mobile app using Azure AD for user authentication and profile storage. Fans get simplified registration and
sign-in through use of social accounts like Facebook, or they can use traditional username/passwords for a
seamless experience across iOS, Android, and Windows phones. Building on the established Azure AD platform
significantly reduced custom code while giving the franchise customized branding and alleviating concerns about
security, data breaches, and scalability. For more information, see Azure AD B2C.
Comparison of Azure AD capabilities

Each of the scenarios already discussed in this article is addressed by capabilities within Azure AD. This table
should help clarify which capabilities are most relevant to you:
AZURE AD MULTI-TENANT AZURE AD B2B

CONSIDER THIS PRODUCT... SAAS APP COLLABORATION AZURE AD B2C
If I need to provide... a service to businesses partner access to my apps a service to consumers
And I am similar to... Pharma distributor Imaging company Sports franchise
Deploying an app for... Practice management Supplier extranet Soccer fans
Targeting... Doctors offices Approved business partners Anyone with email
Accessible when... Customer admin consents My admin invites The consumer signs up
Azure AD B2B collaboration preview: Detailed
walkthrough
This walkthrough outlines how to use Azure AD B2B collaboration. As the IT administrator of Contoso, we want to
share applications with employees from three partner companies. None of the partner companies need to have
Azure AD.
Alice from Simple Partner Org
Bob, from Medium Partner Org, needs access to a set of apps
Carol, from Complex Partner Org, needs access to a set of apps, and membership in groups at Contoso
After invitations are sent out to partner users, we can configure them in Azure AD to grant access to apps and
membership to groups through the Azure portal. Let's start by adding Alice.
Adding Alice to the Contoso directory

1. Create a .csv file with the headers as shown, populating only Alice's Email, DisplayName, and
InviteContactUsUrl. DisplayName is the name that appears in the invite, and also the name that appears in
the Contoso Azure AD directory. InviteContactUsUrl is a way for Alice to contact Contoso. In the following
example, InviteContactUsUrl specifies the LinkedIn profile of Contoso. It is important to spell the labels in the
first row of the .csv file exactly as specified in the CSV file format reference.
2. In the Azure portal, add a user into the Contoso directory (Active Directory > Contoso > Users > Add User). In
the "Type of User" drop down, select "Users in partner companies". Upload the .csv file. Make sure that the .csv
file is closed before uploading.
3. Alice is now represented as an External User in the Contoso Azure AD directory.
4. Alice receives the following email.

5. Alice clicks the link, and she is prompted to accept the invitation and to sign in using her work credentials. If
Alice is not in the Azure AD directory, Alice is prompted to sign up.
6. Alice is redirected to the App Access Panel, empty until she is granted access to apps.
This procedure enables the simplest form of B2B collaboration. As a user in the Contoso Azure AD directory, Alice
can be granted access to applications and groups through the Azure portal. Now let's add Bob, who needs access
to the applications Moodle and Salesforce.
Adding Bob to the Contoso directory and granting access to apps

1. Use Windows PowerShell with the Azure AD Module installed to find the application IDs of Moodle and
Salesforce. The IDs can be retrieved using the cmdlet:
Get-MsolServicePrincipal | fl DisplayName, AppPrincipalId This brings up a list of all available applications in
Contoso and their AppPrincialIds.
2. Create a .csv file containing Bob's Email and DisplayName, InviteAppID, InviteAppResources, and
InviteContactUsUrl. Populate InviteAppResources with the AppPrincipalIds of Moodle and Salesforce found
from PowerShell, separated by a space. Populate InviteAppId with the same AppPrincipalId of Moodle to
brand the email and sign in pages with a Moodle logo.
3. Upload the .csv file through the Azure Portal just as it was done for Alice. Bob is now an external user in the
Contoso Azure AD directory.
4. Bob receives the following email.
5. Bob clicks the link and is prompted to accept the invitation. After he is signed in, he is directed to the Access
Panel and can already use Moodle and Salesforce.
We will add Carol next, who needs access to applications as well as membership to groups in the Contoso
directory.
Adding Carol to the Contoso directory, granting access to apps, and

giving group membership
1. Use Windows PowerShell with the Azure AD Module installed to find the application IDs and group IDs
within Contoso.
Retrieve AppPrincipalId using cmdlet Get-MsolServicePrincipal | fl DisplayName, AppPrincipalId , same
as for Bob
Retrieve ObjectId for groups using cmdlet Get-MsolGroup | fl DisplayName, ObjectId . This brings up a
list of all groups in Contoso and their ObjectIds. Group IDs can also be retrieved as the Object ID in the
Properties tab of the group in the Azure portal.
2. Create .csv file, populating Carol's Email, DisplayName, InviteAppID, InviteAppResources,
InviteGroupResources, and InviteContactUsUrl. InviteGroupResources is populated by the ObjectIds of the
groups MyGroup1 and Externals, separated by a space.
3. Upload the .csv file through the Azure portal.

4. Carol is a user in the Contoso directory and is also a member of the groups MyGroup1 and Externals, as seen
in the Azure portal.
5. Carol receives an email containing a link to accept the invitation. After she signs in, she is redirected to the App
Access Panel to have access to Moodle and Salesforce.
That's all there is to adding users from partner businesses in Azure AD B2B collaboration. This walkthrough
showed how to add users Alice, Bob, and Carol to the Contoso directory using three separate .csv files. This
process can be made easier by condensing the separate .csv files into a single file.
Related articles
How it works
Azure AD B2B collaboration preview: Current
preview limitations
Multi-factor authentication (MFA) not supported on external users. For example, if Contoso has MFA, but
Partner Org does not, then Partner Org users can't be granted MFA through B2B collaboration.
Invites are possible only via CSV; individual invites and API access are not supported.
Only Azure AD Global Administrators can upload .csv files.
Invitations to consumer email addresses (such as hotmail.com, Gmail.com, or comcast.net) are currently not
supported.
External user access to on-premises applications not tested.
External users are not automatically cleaned up when the actual user is deleted from their directory.
Invitations to distribution lists are not supported.
Maximum of 2,000 records can be uploaded via CSV.
Related articles
How it works
Azure AD B2B collaboration preview: CSV file
format
The preview version of Azure AD B2B collaboration requires a CSV file specifying partner user information to be
uploaded through the Azure AD portal. The CSV file should contain the required labels below, and optional fields
as necessary. Modify the sample CSV file (below) without changing the spelling of the labels in the first row.
NOTE
The first row of labels (such as Email, DisplayName, and so on) is necessary for the CSV file to be parsed successfully. The
spelling must match the fields specified below. These labels identify the content beneath them. For optional fields that
aren't needed, their labels can be removed from the CSV file. The entire column can be left empty.
Required fields:
Email: Email address of invited user.
DisplayName: Display name for invited user (typically, first and last name).
Optional fields:
InvitationText: Customize invitation email text after app branding and before the redemption link.
InvitedToApplications: AppIDs to corporate applications to assign users. AppIDs are retrievable in PowerShell
by calling Get-MsolServicePrincipal | fl DisplayName, AppPrincipalId
InvitedToGroups: ObjectIDs for groups to add user to. ObjectIDs are retrievable in PowerShell by calling
Get-MsolGroup | fl DisplayName, ObjectId
InviteRedirectURL: URL to direct an invited user after invite acceptance. This should be a company-specific URL
(such as contoso.my.salesforce.com). If this optional field is not specified, the invited user is directed to the App
Access Panel where they can navigate to your chosen corporate apps. The App Access Panel URL is of the form
https://account.activedirectory.windowsazure.com/applications/default.aspx?tenantId=<TenantID> .
CcEmailAddress: Email address to copy emailed invitation. If the CcEmailAddress field is used, this invitation
cannot be used for email-verified user or tenant creation.
Language: Language for invitation email and redemption experience, with "en" (English) as the default when
unspecified. The other 10 supported language codes are:
1. de: German
2. es: Spanish
3. fr: French
4. it: Italian
5. ja: Japanese
6. ko: Korean
7. pt-BR: Portuguese (Brazil)
8. ru: Russian
9. zh-HANS: Simplified Chinese
10. zh-HANT: Traditional Chinese
Sample CSV file
Here is a sample CSV you can modify.
NOTE
Copy and paste this into Notepad, and save it with a '.csv' file extension. Then edit this in Excel. It will be structured into a
table with labels in the first row.
Add more optional fields in Excel by specifying the label and populating the column beneath it.
Email,DisplayName,InvitationText,InviteRedirectUrl,InvitedToApplications,InvitedToGroups,CcEmailAddress,Lang
uage
wharp@contoso.com,Walter Harp,Hi Walter! I hope youve been doing well.,,cd3ed3de-93ee-400b-8b19-
b61ef44a0f29,,you@yourcompany.com,en
jsmith@contoso.com,Jeff Smith,Hi Jeff! I hope youve been doing well.,,cd3ed3de-93ee-400b-8b19-
bsmith@contoso.com,Ben Smith,Hi Ben! I hope youve been doing well.,,cd3ed3de-93ee-400b-8b19-
Related articles
Browse our other articles on Azure AD B2B collaboration
How it works
Azure AD B2B collaboration preview: External user
object attribute changes
Each user in an Azure AD directory is represented by a user object. The user object in Azure AD undergoes
attribute changes in various stages of the B2B collaboration invite-redeem flow. The user object representing the
partner user in the directory has attributes that change at redeem time, when the partner user clicks the link in the
invite email. Specifically:
The SignInName and AltSecId attributes are populated
The DisplayName attribute changes from the User Principal Name (user_fabrikam.com#EXT#@contoso.com)
to the sign-in name (user@fabrikam.com)
Tracking these attributes in Azure AD can help you troubleshoot whether or not a partner user has redeemed
their B2B collaboration invitation.
Related articles
How it works
Azure AD B2B collaboration preview: External user
token format
The claims for a standard Azure AD token are described in the Supported Token and Claim Types article on
azure.microsoft.com.
The claims that are different for an authenticated B2B collaboration external user are as follows:
OID: the object ID from the resource tenant
TID: tenant ID from the resource tenant
Issuer: this is the resource tenant
IDP: this is the home tenant of the user
AltSecId: this is the alternative security ID, which is opaque to you
Related articles
How it works
Integrating your on-premises identities 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 and will reach end of support on 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.
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.
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.
Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central location in
the Azure portal to view this activity. For additional information, see Azure Active Directory Connect Health.
Install Azure AD Connect

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
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 customizaton 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
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.
Assigning administrator roles in Azure Active
Directory
Using Azure Active Directory (Azure AD), you can designate separate administrators to serve different functions.
These administrators will have access to various features in the Azure portal or Azure classic portal and,
depending on their role, will be able to 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 that your organization has subscribed to,
regardless of whether you assign the role in the Office 365 portal, or in the Azure classic 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.
Global administrator / Company Administrator: Has access to all administrative features. The person
who signs up for the Azure account becomes a global administrator. Only global administrators can
assign other administrator roles. There can be more than one global administrator at your company.
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.
Compliance administrator: Users with this role have management permissions within in the Office 365
Security & Compliance Center and Exchange Admin Center, and access to read reports in the Office 365
Admin Center. More information at About Office 365 admin roles.
CRM service administrator: Users with this role have global permissions within Microsoft CRM Online,
when the service is present. More information at About Office 365 admin roles.
Device administrators: Users with this role become Administrators on all Windows 10 devices that are
joined to 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.
Intune service administrator: Users with this role have global permissions within Microsoft Intune Online,
when the service is present. More information at About Office 365 admin roles.
Skype for Business service administrator: Users with this role have global permissions within Microsoft
Skype for Business, when the service is present. More information at About Office 365 admin roles. This role
was referred to previously as the Lync service administrator role.
Guest inviter: Users in this role can manage guest invitations. It does not include any other permissions.
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: Resets passwords, manages service requests, and
monitors 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".
SharePoint service administrator: Users with this role have global permissions within Microsoft
SharePoint Online, when the service is present. More information at About Office 365 admin roles.
Service administrator: Manages service requests and monitors service health.
NOTE
To assign the service administrator role to a user, the global administrator must first assign administrative
permissions to the user in the service, such as Exchange Online, and then assign the service administrator role to
the user in the Azure classic portal.
User account administrator: Resets passwords, monitors service health, and manages user accounts, user
groups, and service requests. Some limitations apply to the permissions of a user management
administrator. For example, they cannot delete a global administrator or create other administrators. Also,
they cannot reset passwords for billing, global, and service administrators.
Security reader: Read-only access to a number of security features of Identity Protection Center, Privileged
Identity Management, Monitor Office 365 Service Health, and Office 365 Security & Compliance Center.
Security administrator: All of the read-only permissions of the Security reader role, plus a number of
additional administrative permissions for the same services: Identity Protection Center, Privileged Identity
Management, Monitor Office 365 Service Health, and Office 365 Security & Compliance Center.
Administrator permissions
Billing administrator
CAN DO CANNOT DO
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 reports
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
Create and manage user views
Create, edit, and delete users and groups, and manage
user licenses
Manage domains
Enable or disable multi-factor authentication
View reports
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
user licenses
Manage domains
View reports
Service administrator
CAN DO CANNOT DO
View company and user information Reset user passwords

Manage Office support tickets Perform billing and purchasing operations for Office
products
user licenses
Manage domains
View reports
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. He or she cannot
reset passwords for billing, global, and service Manage company information
administrators.
user licenses, with limitations. He or she cannot delete a Enable or disable multi-factor authentication
global administrator or create other administrators. View reports
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.
Assign or remove administrator roles
1. In the Azure classic portal, click Active Directory, and then click the name of your organizations directory.
2. On the Users page, click the display name of the user you want to edit.
3. In the Organizational Role list, select the administrator role that you want to assign to this user, or select
User if you want to remove an existing administrator role.
4. In the Alternate Email Address box, type an email address. This email address is used for important
notifications, including password self-reset, so the user must be able to access the email account whether or
not the user can access Azure.
5. Select Allow or Block to specify whether to allow the user to sign in and access services.
6. Specify a location from the Usage Location drop-down list.
7. When you have finished, click Save.
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 preview
This article explains how to assign an administrative role to a user in Azure Active Directory (Azure AD) preview.
What's in the preview? 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

3. On the Users and groups blade, select All users.

4. On the Users and groups - All users blade, select a user from the list.
5. On the blade 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.
What's next
Add a user
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 create and use administrative units only if you enable Azure Active Directory Premium. For more information, see
Getting started with Azure AD Premium.
From the central administrators point of view, an administrative unit is a directory object that can be created and
populated with resources. In this 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.
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 Manage Azure AD using Windows PowerShell.
Next steps
Azure Active Directory editions
Understanding resource access in Azure
NOTE
This topic explains concepts about using subscription administrators to control resource access in the full Azure portal. As an
alternative, the Azure Preview portal provides role-based access control so Azure resources can be managed more precisely.
In October 2013, the Azure classic portal and Service Management APIs were integrated with Azure Active
Directory in order to lay the groundwork for improving the user experience for managing access to Azure
resources. Azure Active Directory already provides great capabilities such as user management, on-premises
directory sync, multi-factor authentication, and application access control. Naturally, these should also be made
available for managing Azure resources across-the-board.
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 classic 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 users (that is, Microsoft Accounts).
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 classic portal enables SAs that are signed in using a Microsoft Account to change
the directory that a subscription is associated with by using the Edit Directory command on the Subscriptions
page in Settings. Note that this operation has implications on the access control of that subscription.
NOTE
The Edit Directory command in the Azure classic portal is not available to users who are signed in using a work or school
account because those accounts can sign in only to the directory to which they belong.
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 classic 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 isnt 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
classic 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 access management in the Azure
portal
Security-oriented companies should focus on giving employees the exact permissions they need. Too many
permissions exposes 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 cant 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.
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 with Azure Resource Manager APIs, or the Azure classic portal and Azure classic
deployment model. 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 classic management portal and the Azure classic deployment model.
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 cannot. 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 - Public preview
With Role-Based Access Control (RBAC) in the Azure Active Directory preview, you can manage access to your
Azure resources. What's in the preview?
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.
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 won'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.
Related topics
Get started with Role-Based Access Control to Use role assignments to manage access to your Azure
subscription resources
Use role assignments 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.
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 users were Assigned access while others Inherited it. 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. Select the role assignment on the Access control blade.
2. Select Remove in the assignment details blade.
3. Select yes to confirm removal.
Inherited assignments cannot be removed. Notice in the image below that the remove button is grayed out.
Instead, look at the Assigned At detail. 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
RBAC: Built-in roles
Azure Role-Based Access Control (RBAC) comes with the following built-in roles that can be assigned to users,
groups, and services. You cant 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.
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 cmdlets (get-azurermroledefinition "<role name>").actions or
(get-azurermroledefinition "<role name>").notactions as applicable.
ROLE NAME DESCRIPTION
API Management Service Contributor Can manage API Management services
Application Insights Component Contributor Can manage Application Insights components
Automation Operator Able to start, stop, suspend, and resume jobs
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 DocumentDB accounts
Intelligent Systems Account Contributor Can manage Intelligent Systems accounts
Network Contributor Can manage all network resources

ROLE NAME DESCRIPTION
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
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
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 Services
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
Microsoft.Resources/subscriptions/resourceGroups/read Read roles and role assignments
Microsoft.Support/* Create and manage support tickets
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

ACTIONS
Microsoft.Automation/automationAccounts/jobs/streams/rea Read automation account job streams

d
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
BizTalk Contributor
Can manage BizTalk services
ACTIONS
Microsoft.BizTalkServices/BizTalk/* Create and manage BizTalk services

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 Cant delete roles and role assignments
Microsoft.Authorization/*/Write Cant 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.

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
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

ACTIONS
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 DocumentDB accounts
ACTIONS
Microsoft.DocumentDb/databaseAccounts/* Create and manage DocumentDB accounts
Intelligent Systems Account Contributor

Can manage Intelligent Systems accounts
ACTIONS
Microsoft.IntelligentSystems/accounts/* Create and manage intelligent systems accounts
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

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
*/read Read resources of all types, except secrets.
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

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
Microsoft.Security/* Create and manage security components and policies
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
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
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

ACTIONS
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
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

ACTIONS
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/read Read virtual networks
Microsoft.Network/virtualNetworks/subnets/join/action Join virtual network subnets
Microsoft.Storage/storageAccounts/listKeys/action List storage account keys
Microsoft.Storage/storageAccounts/read Read storage accounts
Classic Network Contributor

Can manage classic virtual networks and reserved IPs
ACTIONS
Microsoft.ClassicNetwork/* Create and manage classic networks
Web Plan Contributor

Can manage web plans
ACTIONS

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.
Custom Roles in Azure RBAC
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, custom roles can be assigned 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 all
subscriptions that use that tenant as the Azure AD directory for the subsciption.
The following is an example of 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
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.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 will be 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.
Learn how to manage access with:
PowerShell
Azure CLI
REST API
Built-in roles: Get details about the roles that come standard in RBAC.
Create an access change history report
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.
More details about this cmdlet are available in the PowerShell Gallery.
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
Date The date and time that access was changed
DirectoryName The Azure Active Directory directory
PrincipalName The name of the user, group, or application
PrincipalType Whether the assignment was for a user, group, or application
RoleId The GUID of the role that was granted or revoked
RoleName The role that was granted or revoked
ScopeName The name of the subscription, resource group, or resource
ScopeType Whether the assignment was at the subscription, resource

group, or resource scope
SubscriptionId The GUID of the Azure subscription
SubscriptionName The name of the Azure subscription
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.
See also
Get started with Azure Role-Based Access Control
Work with Custom roles in Azure RBAC
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:
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":.propertie
s.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":.propertie
s.scope}'
azure role assignment list --expandPrincipalGroups --signInName sameert@aaddemo.com --json | jq '.[] |

{"DisplayName":.properties.aADObject.DisplayName,"RoleDefinitionName":.properties.roleName,"Scope":.propertie
s.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. The 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. The 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 show 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 show 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 example lists all role 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 isnt available in the Production4 subscription
because that subscription isnt in the AssignableScopes of the role.
azure role list --json | jq '.[] | if .properties.type == "CustomRole" then .properties.roleName else empty
end'
RBAC Topics
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 must have the following:
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.
Create role with PSRoleDefinitionObject
When you create a custom role by using PowerShell, you can start from scratch or use one of the built-in roles as
a starting point, the latter being used in this example. 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 contents. Note that the Id
should be set to null on intial role creation as a new ID will be generated.
{
"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 below. Note that the definitions
listed in the template are not cumulatively applied to an existing definition, meaning that the role will appear
exactly as you specify in the template. Als note that you also need to update the Id 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 isnt available in the Production4 subscription
because that subscription isnt 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
Managing 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"
}
Role Based Access Control

Manage access using Azure Powershell
Manage access using the Azure CLI
RBAC Built in Roles
Role-Based Access Control troubleshooting
Introduction
Role-Based Access Control is a powerful feature that allows you to delegate fine-grained access to resources in
Azure. This means you can feel confident granting a specific person the right to use exactly what they need, and no
more. However, at times the resource model for Azure resources can be complicated and it can be difficult to
understand exactly what you are granting permissions to.
This document will let you know what to expect when using some of the roles in the Azure portal. These three roles
cover all resource types:
Owner
Contributor
Reader
Owners and contributors both have full access to the management experience, but a contributor cant give access
to other users or groups. Things get a little more interesting with the reader role, so thats where well 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 wont be
available in any read-only scenario.
Commands (e.g. 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'll 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 will be disabled.
These items require write access to the App Service plan that corresponds to your website:
Viewing the web apps 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 (This is because 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, you'll need to 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.
Configurable Token Lifetimes in Azure Active
Directory (Public Preview)
NOTE
This capability is currently in public preview. You should be prepared to revert or remove any changes. We are opening up
this feature for everyone to try during the public preview, however, certain aspects may require an Azure AD Premium
subscription once generally available.
Introduction
This feature is used by admins and developers to specify the lifetimes of tokens issued by Azure AD. Token lifetimes
can be configured for all apps in an organization, for a multi-tenant (multi-organization) application, or for a
specific Service Principal in a organization.
In Azure AD, a policy object represents a set of rules enforced on individual applications or 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 policy can be designated as the default for an organization. This policy then takes effect on any application that
resides within that organization as long as it is not overridden by a policy with a higher priority. Policies can also be
assigned to specific applications. The order of priority varies by policy type.
Token lifetime policies can be configured for refresh tokens, access tokens, session tokens, and ID tokens.
Access tokens
An access token is used by a client to access a protected resource. An access token can only be used 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 access token lifetime
is a trade-off between improving system performance and increasing the amount of time that the client retains
access after the users 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, it 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. Refresh tokens are bound to combinations of user and client. They can be revoked and their validity is
checked every time they are used.
It is important to make a distinction between confidential and public clients. For more information on the different
types of clients see RFC 6749.
Token Lifetimes with Confidential Client Refresh Tokens
Confidential clients are applications that are able to securely store a client password (secret), allowing them to
prove that requests are coming from the client application and not a malicious actor. For example, a web app is a
confidential client since it can store a client secret on the web server and thus is not exposed. As these flows are
more secure, the default lifetimes of refresh tokens issued to these flows are higher and cannot be changed using
policy.
Token Lifetimes with Public Client Refresh Tokens
Public clients are unable to securely store a client password (secret). For example, an iOS/Android app cannot
obfuscate a secret from the resource owner, and as such is considered a public client. Policies can be set on
resources to prevent refresh tokens from public clients older than a specified period from obtaining a new
access/refresh token pair (Refresh Token Max Inactive Time). Additionally, policies can be used to set a period of
time beyond which the refresh tokens are no longer accepted (Refresh Token Max Age). Adjusting refresh token
lifetime allows you to control when and how often the user is required to reenter credentials instead of being
silently re-authenticated when using a public client application.
ID tokens
ID tokens are passed to web sites and native clients and 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 expiry. Normally, a web
application matches a users session lifetime in the application to the lifetime of the ID token issued for the user.
Adjusting ID token lifetime allows you to control how often the web application will expire the application session
and require the user to be re-authenticated with Azure AD (either silently or interactively).
Single Sign-On Session token
When a user authenticates with Azure AD and checks the "Keep me signed in" box, a single sign-on session is
established with the users browser and Azure AD. The Single Sign-On Session Token, in the form of a cookie,
represents this session. It is important to 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.
There are two kinds of SSO session tokens. Persistent session tokens are stored as persistent cookies by the
browser and non-persistent session tokens are stored as session cookies (these are destroyed when the browser is
closed).
Non-persistent session tokens have a lifetime of 24 hours whereas persistent tokens have a lifetime of 180 days.
Any time the SSO session token is used within its validity period, the validity period is extended another 24 hours
or 180 days. If the SSO session token is not used within its validity period, it is considered expired and will no
longer be accepted.
Policies can be used to set a period of time after the first session token was issued beyond which the session tokens
are no longer accepted (Session Token Max Age). Adjusting session token lifetime allows you to control when and
how often the user is required to re-enter 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. The properties of the policy are
used 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 MaxAgeSingleFac Refresh tokens 90 days 10 minutes Until-revoked*

Refresh Token tor (for any users)
Max Age
POLICY PROPERTY
PROPERTY STRING AFFECTS DEFAULT MINIMUM MAXIMUM
Multi-Factor MaxAgeMultiFact Refresh tokens 90 days 10 minutes Until-revoked*

Refresh Token or (for any users)
Max Age
Single-Factor MaxAgeSessionSi Session Until-revoked 10 minutes Until-revoked*

Session Token ngleFactor** tokens(persistent
Max Age and non-
persistent)
Multi-Factor MaxAgeSessionM Session tokens Until-revoked 10 minutes Until-revoked*

Session Token ultiFactor*** (persistent and
Max Age non-persistent)
*365 days is the maximum explicit length that can be set for these attributes.
**If MaxAgeSessionSingleFactor is not set then this value takes the MaxAgeSingleFactor value. If neither
parameter is set, the property takes on the default value (Until-revoked).
***If MaxAgeSessionMultiFactor is not set then this value takes the MaxAgeMultiFactor value. If neither
parameter is set, the property takes on the default value (Until-revoked).
Exceptions
PROPERTY AFFECTS DEFAULT
Refresh Token Max Inactive Time Refresh tokens (Issued for federated 12 hours
(federated users with insufficient users with insufficient revocation
revocation information) information)
Refresh Token Max Inactive Time Refresh tokens (Issued for Confidential 90 days
(Confidential Clients) Clients)
Refresh token Max Age (Issued for Refresh tokens (Issued for Confidential Until-revoked
Confidential Clients) Clients)
Priority and evaluation of policies

Token Lifetime policies can be created and assigned to specific applications, organizations and service principals.
This means that it is possible for multiple policies to 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 will be enforced.
If no policy is explicitly assigned to the service principal, a policy explicitly assigned to the parent organization of
the service principal will be enforced.
If no policy is explicitly assigned to the service principal or the organization, the policy assigned to the
application will be enforced.
If no policy has been assigned to the service principal, the organization, or the application object, the default
values will be enforced (see table above).
For more information on the relationship between application objects and service principal objects in Azure AD, see
Application and service principal objects in Azure Active Directory.
A tokens validity is evaluated at the time it is used. The policy with the highest priority on the application that is
being accessed takes effect.
NOTE
Example
A user wants to access 2 web applications, A and B.
Both applications are in the same parent organization.
Token lifetime policy 1 with a Session Token Max Age of 8 hours is set as the parent organizations default.
Web application A is a regular use web application and isnt linked to any policies.
Web application B is used for highly sensitive processes and its service principal is linked to token lifetime policy 2 with a
Session Token Max Age of 30 minutes.
At 12:00PM the user opens up 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 drops a cookie with a session token in the browser. The user is redirected back to web
application A with an ID token that allows them to access the application.
At 12:15PM, the user then tries to access web application B. The browser redirects to Azure AD which detects the session
cookie. Web application Bs service principal is linked to policy 2, but is also part of the parent organization with default policy
1. Policy 2 takes effect since 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 granting them access.
At 1:00PM the user tries navigating to web application A. The user is redirected to Azure AD. Web application A is not linked
to any policies, but since it is in a organization with default policy 1, this policy takes effect. The session cookie is detected that
was originally issued within the last 8 hours and the user is silently redirected back to web application A with a new ID token
without needing to authenticate.
The user immediately tries to access web application B. The user is redirected to Azure AD. As before, policy 2 takes effect. As
the token was issued longer than 30 minutes ago, the user is then prompted to re-enter their credentials, and a brand new
session and ID token are issued. The user can then access web application B.
Configurable policy properties: In-Depth

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 mitigates the risk of an access or ID token being used by a malicious actor for an extended
period of time (as they cannot be revoked) but also adversely impacts performance as the tokens will 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. Since a new Refresh token is usually returned
when a refresh token is used, the client must not have reached out to any resource using the current refresh token
for the specified period of time before this policy would prevent access.
This policy will force users who have not been active on their client to re-authenticate to retrieve a new refresh
token.
It is important to note that the Refresh Token Max Inactive Time must be set to a lower value than the Single-Factor
Token Max Age and the Multi-Factor Refresh Token Max Age.
Single -factor refresh token max age
String: MaxAgeSingleFactor
Summary: This policy controls how long a user can continue to use refresh tokens to get new access/refresh token
pairs after the last time they authenticated successfully with only a single factor. Once a user authenticates and
receives a new refresh token, they will be able to use the refresh token flow (as long as the current refresh token is
not revoked and it is not left unused for longer than the inactive time) for the specified period of time. At that point,
users will be forced to re-authenticate to receive a new refresh token.
Reducing the max age will force users to authenticate more often. Since single-factor authentication is considered
less secure than a multi-factor authentication, it is recommended that this policy is set to an equal or lesser value
than the Multi-Factor Refresh Token Max Age Policy.
Multi-factor refresh token max age
String: MaxAgeMultiFactor
Summary: This policy controls how long a user can continue to use refresh tokens to get new access/refresh token
pairs after the last time they authenticated successfully with multiple factors. Once a user authenticates and
receives a new refresh token, they will be able to use the refresh token flow (as long as the current refresh token is
not revoked and it is not left unused for longer than the inactive time) for the specified period of time. At that point,
users will be forced to re-authenticate to receive a new refresh token.
less secure than a multi-factor authentication, it is recommended that this policy is set to an equal or greater value
than the Single-Factor Refresh Token Max Age Policy.
Single -factor session token max age
String: MaxAgeSessionSingleFactor
Affects: Session tokens (persistent and non-persistent)
Summary: This policy controls how long a user can continue to use session tokens to get new ID and session
tokens after the last time they authenticated successfully with only a single factor. Once a user authenticates and
receives a new session token, they will be able to use the session token flow (as long as the current session token is
not revoked or expired) for the specified period of time. At that point, users will be forced to re-authenticate to
receive a new session token.
less secure than a multi-factor authentication, it is recommended that this policy is set to an equal or lesser value
than the Multi-Factor Session Token Max Age Policy.
Multi-factor session token max age
String: MaxAgeSessionMultiFactor
Affects: Session tokens (persistent and non-persistent)
Summary: This policy controls how long a user can continue to use session tokens to get new ID and session
tokens after the last time they authenticated successfully with multiple factors. Once a user authenticates and
receives a new session token, they will be able to use the session token flow (as long as the current session token is
not revoked or expired) for the specified period of time. At that point, users will be forced to re-authenticate to
receive a new session token.
less secure than a multi-factor authentication, it is recommended that this policy is set to an equal or greater value
than the Single-Factor Session Token Max Age Policy.
Sample token lifetime policies

Being able to create and manage token lifetimes for apps, service principals, and your overall organization exposes
all kinds of new scenarios possible in Azure AD. We're going to walk through a few common policy scenarios that
will help you impose new rules for:
Token Lifetimes
Token Max Inactive Times
Token Max Age
We'll walk through a few scenarios including:
Managing an Organization's Default Policy
Creating a Policy for Web Sign-in
Creating a Policy for Native Apps calling a Web API
Managing an Advanced Policy
Prerequisites
In the sample scenarios we'll be creating, updating, linking, and deleting policies on apps, service principals, and
your overall organization. If you are new to Azure AD, checkout this article to help you get started before
proceeding with these samples.
1. To begin, download the latest Azure AD PowerShell Cmdlet Preview.
2. Once you have the Azure AD PowerShell Cmdlets, run Connect command to sign into your Azure AD admin
account. You'll need to do this whenever you start a new session.
Connect-AzureAD -Confirm
3. Run the following command to see all policies that have been created in your organization. This command
should be used after most operations in the following scenarios. It will also help you get the Object ID of
your policies.
Get-AzureADPolicy
Sample: Managing a organization's default policy
In this sample, we will create a policy that allows your users to sign in less frequently across your entire
organization.
To do this, we create a token lifetime policy for Single-Factor Refresh Tokens that is applied across your
organization. This policy will be applied to every application in your organization, and each service principal that
doesnt already have a policy set to it.
1. Create a Token Lifetime Policy.
Set the Single-Factor Refresh Token to "until-revoked" meaning it won't expire until access is revoked. The policy
definition below is what we will be creating:
@("{
`"TokenLifetimePolicy`":
{
`"Version`":1,
`"MaxAgeSingleFactor`":`"until-revoked`"
}
}")
Then run the following command to create this policy.
New-AzureADPolicy -Definition @("{`"TokenLifetimePolicy`":{`"Version`":1, `"MaxAgeSingleFactor`":`"until-

revoked`"}}") -DisplayName OrganizationDefaultPolicyScenario -IsOrganizationDefault $true -Type
TokenLifetimePolicy
To see your new policy and get its ObjectID, run the following command.
Get-AzureADPolicy
2. Update the Policy

You've decided that the first policy is not quite as strict as your service requires, and have decided you want your
Single-Factor Refresh Tokens to expire in 2 days. Run the following command.
Set-AzureADPolicy -ObjectId <ObjectID FROM GET COMMAND> -DisplayName OrganizationDefaultPolicyUpdatedScenario -

Definition @("{`"TokenLifetimePolicy`":{`"Version`":1,`"MaxAgeSingleFactor`":`"2.00:00:00`"}}")
3. You're done!
Sample: Creating a policy for web sign-in
In this sample, we will create a policy that will require your users to authenticate more frequently into your Web
App. This policy will set 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 will set the Access/Id Token lifetime and the Max Single-Factor Session Token Age to 2
hours.
New-AzureADPolicy -Definition @("{`"TokenLifetimePolicy`":

{`"Version`":1,`"AccessTokenLifetime`":`"02:00:00`",`"MaxAgeSessionSingleFactor`":`"02:00:00`"}}") -DisplayName
WebPolicyScenario -IsOrganizationDefault $false -Type TokenLifetimePolicy
Get-AzureADPolicy
2. Assign the policy to your service principal.

We're going to link this new policy with a service principal. You'll also need a way to access the ObjectId of your
service principal. You can query the Microsoft Graph or go to our Graph Explorer Tool and sign into your Azure AD
account to see all your organization's service principals.
Once you have the ObjectId, Run the following command.
Add-AzureADServicePrincipalPolicy -ObjectId <ObjectID of the Service Principal> -RefObjectId <ObjectId of the

Policy>
3. You're Done!
Sample: Creating a policy for native apps calling a Web API

In this sample, we will create a policy that requires users to authenticate less and will lengthen the amount of time
they can be inactive without having to authenticate again. The policy will be applied to the Web API, that way when
the Native App requests it as a resource this policy will be applied.
This command will create a strict policy for a Web API.

{`"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.

We're going to link this new policy with an application. You'll also need a way to access the ObjectId of your
application. The best way to find your app's ObjectId is to use the Azure Portal.
Add-AzureADApplicationPolicy -ObjectId <ObjectID of the App> -RefObjectId <ObjectId of the Policy>
3. You're Done!
Sample: Managing an advanced policy
In this sample, we will create a few policies to demonstrate how the priority system works, and how you can
manage multiple policies applied to several objects. This will give some insight into the priority of policies explained
above, and will also help you manage more complicated scenarios.
1. Create a Token Lifetime Policy
So far pretty simple. We've created a organization default policy that sets the Single-Factor Refresh Token lifetime
to 30 days.

{`"Version`":1,`"MaxAgeSingleFactor`":`"30.00:00:00`"}}") -DisplayName ComplexPolicyScenario -
IsOrganizationDefault $true -Type TokenLifetimePolicy
To see your new policy and get it's ObjectID, run the following command.
Get-AzureADPolicy
2. Assign the Policy to a Service Principal

Now we have a policy on the entire organization. Let's say we want to preserve this 30 day policy for a specific
service principal, but change the organization default policy to be the upper limit of "until-revoked".
First, We're going to link this new policy with our service principal. You'll also need a way to access the ObjectId of
your service principal. You can query the Microsoft Graph or go to our Graph Explorer Tool and sign into your
Azure AD account to see all your organization's service principals.
Add-AzureADServicePrincipalPolicy -ObjectId <ObjectID of the Service Principal> -RefObjectId <ObjectId of the

Policy>
3. Set the IsOrganizationDefault flag to false using the following command.
Set-AzureADPolicy -ObjectId <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
5. You're Done!
You now have the original policy linked to your service principal and the new policy 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
The following cmdlets can be used 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 The array of stringified JSON that -Definition @("{

contains all the rules of the policy. "TokenLifetimePolicy ":{ "Version
":1, "MaxInactiveTime ": "20:00:00
"}}")
-DisplayName String of the policy name -DisplayName MyTokenPolicy
-IsOrganizationDefault If true sets the policy as organization's -IsOrganizationDefault $true

default policy, if false does nothing
-Type The type of policy, for token lifetimes -Type TokenLifetimePolicy

always use "TokenLifetimePolicy"
-AlternativeIdentifier [Optional] Sets an alternative id to the policy. -AlternativeIdentifier myAltId
Get-AzureADPolicy
Gets all AzureAD Policies or specified policy
Get-AzureADPolicy
-ObjectId [Optional] The object Id of the Policy you would -ObjectId <ObjectID of Policy>
like to get.
Get-AzureADPolicyAppliedObject
Gets all apps and service principals linked to a policy
Get-AzureADPolicyAppliedObject -ObjectId <object id of policy>
-ObjectId The object Id of the Policy you would -ObjectId <ObjectID of Policy>
like to get.
Set-AzureADPolicy
Updates an existing policy
Set-AzureADPolicy -ObjectId <object id of policy> -DisplayName <string>
like to get.
-DisplayName String of the policy name -DisplayName MyTokenPolicy
-Definition [Optional] The array of stringified JSON that -Definition @("{

contains all the rules of the policy. "TokenLifetimePolicy ":{ "Version
":1, "MaxInactiveTime ": "20:00:00
"}}")
-IsOrganizationDefault [Optional] If true sets the policy as organization's -IsOrganizationDefault $true

default policy, if false does nothing
-Type [Optional] The type of policy, for token lifetimes -Type TokenLifetimePolicy
always use "TokenLifetimePolicy"
-AlternativeIdentifier [Optional] Sets an alternative id to the policy. -AlternativeIdentifier myAltId
Remove-AzureADPolicy
Deletes the specified policy
Remove-AzureADPolicy -ObjectId <object id of policy>

like to get.
Application policies
The following cmdlets can be used for application policies.
Add-AzureADApplicationPolicy
Links the specified policy to an application
Add-AzureADApplicationPolicy -ObjectId <object id of application> -RefObjectId <object id of policy>
-ObjectId The object Id of the Application. -ObjectId <ObjectID of Application>
-RefObjectId The object Id of the Policy. -RefObjectId <ObjectID of Policy>
Get-AzureADApplicationPolicy
Gets the policy assigned to an application
Get-AzureADApplicationPolicy -ObjectId <object id of application>
Remove-AzureADApplicationPolicy
Removes a policy from an application
Remove-AzureADApplicationPolicy -ObjectId <object id of application> -PolicyId <object id of policy>
-PolicyId The ObjectId of Policy. -PolicyId <ObjectID of Policy>
Service principal policies

The following cmdlets can be used for service principal policies.
Add-AzureADServicePrincipalPolicy
Links the specified policy to a service principal
Add-AzureADServicePrincipalPolicy -ObjectId <object id of service principal> -RefObjectId <object id of policy>
-RefObjectId The object Id of the Policy. -RefObjectId <ObjectID of Policy>
Get-AzureADServicePrincipalPolicy
Gets any policy linked to the specified service principal
Get-AzureADServicePrincipalPolicy -ObjectId <object id of service principal>
Remove-AzureADServicePrincipalPolicy
Removes the policy from specified service principal
Remove-AzureADServicePrincipalPolicy -ObjectId <object id of service principal> -PolicyId <object id of

policy>
-PolicyId The ObjectId of Policy. -PolicyId <ObjectID of Policy>

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 organizations identities
Configure automated responses to detected suspicious actions that are related to your organizations
identities
Investigate suspicious incidents and take appropriate action to resolve them
Getting started
Microsoft secures 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
users 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
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
Aure Active Directory detects some risk event types in real-time. All real-time risk events that have been
detected during a sign-in of a user contribute 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.
The lifecycle of a risky sign-in ends when a user signs out.
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 policicies. 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 risk events that were detected by Azure Active Directory for a user contribute to a logical concept called users
flagged for risk. A user flag for risk or risky user 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 users 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 events 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 user to reset 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
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
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, its 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 wont 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 - 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.
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 optionsphone 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
Types of risk events detected by Azure Active
Directory
In Azure Active Directory, risk events are events that:

were flagged as suspicious
indicate that an identity may have been compromised.
This topic gives you a detailed overview of the available types of risk events.
Leaked credentials
Leaked credentials are found posted publicly in the dark web by Microsoft security researchers. These credentials
are usually found in plain text. They are checked against Azure AD credentials, and if there is a match, they are
reported as Leaked credentials.
Leaked credentials risk events are classified as a High severity risk event, because they provide a clear indication
that the user name and password are available to an attacker.
Impossible travel to atypical locations

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. In addition, the time between the two sign-ins is
shorter than the time it would have taken the user to travel from the first location to the second, indicating that a
different user is using the same credentials.
This machine learning algorithm that ignores obvious "false positives" contributing to the impossible travel
condition, 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 users sign-in behavior.
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 applications 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.
Sign-ins from infected devices

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 users device against IP addresses that were
in contact with a bot server.
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.
Sign-ins from anonymous IP addresses

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 devices IP address, and
may be used for malicious intent.
We recommend that you immediately contact the user to verify if they were using anonymous IP addresses. The
risk level for this risk event type is Medium because in itself an anonymous IP is not a strong indication of an
account compromise.

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.
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.
Sign-in from unfamiliar locations

This risk event type 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 information about previous
locations used by a user, and considers these familiar locations. The risk even 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 14
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.
Unfamiliar locations can provide a strong indication that an attacker is able attempting to use a stolen identity.
False-positives may occur when a user is traveling, trying out a new device or uses a new VPN. As a result of these
false positives, the risk level for this event type is Medium.
Azure AD Anomalous Activity reports

Some of these risk events have been available through the Azure AD Anomalous Activity reports in the Azure
portal. The table below lists the various risk event types and the corresponding Azure AD Anomalous Activity
report. Microsoft is continuing to invest in this space, and plans to continuously improve the detection accuracy of
existing risk events and add new risk event types on an ongoing basis.
RISK EVENT TYPE CORRESPONDING AZURE AD ANOMALOUS ACTIVITY REPORT
Leaked credentials Users with leaked credentials
Impossible travel to atypical locations Irregular sign-in activity
Sign-ins from infected devices Sign-ins from possibly infected devices

RISK EVENT TYPE CORRESPONDING AZURE AD ANOMALOUS ACTIVITY REPORT
Sign-ins from anonymous IP addresses Sign-ins from unknown sources
Sign-ins from IP addresses with suspicious activity Sign-ins from IP addresses with suspicious activity
Signs in from unfamiliar locations -
Lockout events -
The following Azure AD Anomalous Activity reports are not included as risk events in Azure AD, and will therefore
not be available through Azure AD. These reports are still available in the Azure portal however they will be
deprecated at some time in the future as they are being superseded by risk events in Azure AD.
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.
Sign-ins from anonymous IP addresses
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 devices 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 accounts 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
notifications
Azure AD Identity Protection sends two types of automated notification emails to help you manage user risk and
risk events:
User compromised alert email
Weekly digest email
User compromised alert email

A user compromised email alert is generated when Azure AD Identity Protection identifies an account as
compromised. The email includes a link to the Users flagged for risk report in the Identity Protection dashboard.
We recommend that you immediately investigate notifications of compromised accounts.
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
You can switch sending a weekly digest email off.

1. On the Azure AD Identity Protection blade, click Settings.
2. In the General section, click Notifications.

See also
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 organizations 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 users 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 Microsofts unified API endpoint and the home of Azure Active Directory Identity Protections
APIs. Our 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 three steps to accessing Identity Protection data through Microsoft Graph:
1. Add an application with a client secret.
2. Use this secret and a few other pieces of information to authenticate to Microsoft Graph, where you receive an
authentication token.
3. Use this token to make requests to the API endpoint and get Identity Protection data back.
Before you get started, youll need:
Administrator privileges to create the application in Azure AD
The name of your tenant's domain (for example, contoso.onmicrosoft.com)
Add an application with a client secret

1. Sign in to your Azure classic portal as an administrator.
2. On on the left navigation pane, click Active Directory.
3. From the Directory list, select the directory for which you want to enable directory integration.
5. Click Add at the bottom of the page.
6. On the What do you want to do dialog, click Add an application my organization is developing.
7. On the Tell us about your application dialog, 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. Click Next.
8. On the App properties dialog, perform the following steps:
a. In the Sign-On URL textbox, type http://localhost .

b. In the App ID URI textbox, type http://localhost .
c. Click Complete.
Your can now configure your application.
Grant your application permission to use the API
1. On your application's page, in the menu on the top, click Configure.
2. In the permissions to other applications section, click Add application.
3. On the permissions to other applications dialog, perform the following steps:
a. Select Microsoft Graph.

b. Click Complete.
4. Click Application Permissions: 0, and then select Read all identity risk event information.
5. Click Save at the bottom of the page.
Get an access key

1. On your application's page, in the keys section, select 1 year as duration.
2. Click Save at the bottom of the page.
3. in the keys section, copy the value of your newly created key, 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.
4. In the properties section, copy the Client ID, and then paste it into a safe location.
Authenticate to Microsoft Graph and query the Identity Risk Events

API
At this point, you should have:
The client ID you copied above
The key you copied above
The name of your tenant's domain
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:
client_secret:
NOTE
You need to provide values for the client_id and the client_secret parameter.
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 see fit.
Heres sample code for authenticating and calling the API using Powershell.
Just add your client ID, key, and 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, youll see them on that page.
Additional resources
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 those that administer and manage IT systems. Cyber-attackers target these accounts to gain access to
an organizations data and systems. In order 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 to manage access to Azure, 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 multi-factor authentication (MFA)
before granting privileges. MFA is a method of verifying who you are that requires the use of more than just a
Azure Multi-Factor Authentication 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, or verification code and 3rd party OATH tokens.
For an overview of how Azure Multi-Factor Authentication works see the following video.
For more details, 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), when they need to perform a task. For Azure Active Directory 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 organizations 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.
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
Set up a hybrid cloud environment for testing
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 decisions 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 todays 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 VMs 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 classic portal. Today, using the classic 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 servers 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 classic 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. Lets 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
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 firewallone 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.
OFFICE 365 SINGLE SIGN-ON USING AD FS AND DIRSYNC OFFICE 365 SAME SIGN-ON USING DIRSYNC + PASSWORD SYNC
4. Since Azure AD cant authenticate the user and understands 4. Azure AD cant 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 users 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 Azures 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 Networks 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 services 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 services 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
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 DCs 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 VMs 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 topic shows how to install additional domain controllers (also known as replica DCs) for an on-premises
Active Directory domain on Azure virtual machines (VMs) in an Azure virtual network.
You might also be interested in these related topics:
You can optionally install a new Active Directory forest on an Azure virtual network. For those steps, see Install
a new Active Directory forest on 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 replica DCs are installed in an Azure virtual network. The virtual network can be
connected to the on-premises network by a site-to-site VPN connection, as shown in the following diagram, or
you can use ExpressRoute for a faster connection.
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 Active Directory site for the Azure virtual network
Its a good idea to create a site in Active Directory that represents the network region corresponding to the virtual
network. That helps 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

1. In the Azure classic portal, click New > Network Services > Virtual Network > Custom Create and use
the following values to complete the wizard.
ON THIS WIZARD PAGE SPECIFY THESE VALUES
Virtual Network Details Name: Type a name for the virtual network, such as
WestUSVNet.
Region: Choose the closest region.
DNS and VPN connectivity DNS Servers: Specify the name and IP address of one
or more on-premises DNS servers.
Connectivity: Select Configure a site-to-site VPN.
Local network: Specify a new local network.
If you are using ExpressRoute instead of a VPN, see
Configure an ExpressRoute Connection through an
Exchange Provider.
Site-to-site connectivity Name: Type a name for the on-premises network.

VPN Device IP address: Specify the public IP address
of the device that will connect to the virtual network.
The VPN device cannot be located behind a NAT.
Address: Specify the address ranges for your on-
premises network (such as 192.168.0.0/16 in the
scenario diagram).
Virtual network address spaces Address Space: Specify the IP address range for VMs
that you want to run in the Azure virtual network
(such as 10.1.0.0/16 in the scenario diagram). This
address range cannot overlap with the address ranges
of the on-premises network.
Subnets: Specify a name and address for a subnet for
the application servers (such as Frontend, 10.1.1.0/24)
and for the DCs (such as Backend, 10.1.2.0/24).
Click add gateway subnet.
2. Next, you'll configure the virtual network gateway to create a secure site-to-site VPN connection. See Configure
a Virtual Network Gateway for the instructions.
3. Create the site-to-site VPN connection between the new virtual network and an on-premises VPN device. See
Configure a Virtual Network Gateway for the instructions.
Create Azure VMs for the DC 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 classic portal, click New > Compute > Virtual Machine > From Gallery. Use the following
values to complete the wizard. Accept the default value for a setting unless another value is suggested or
required.
Choose an Image Windows Server 2012 R2 Datacenter
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.
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
DC role.
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 DC role.
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.
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 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. In the Azure classic portal, click the name of the virtual network, and then click the Configure tab to
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 of an on-premises DNS servers.
2. To ensure that all the replica DC VMs on the virtual network are configured with to use DNS servers on the
virtual network, click Virtual Machines, click the status column for each VM, and then click Restart. Wait until
the VM shows Running state before you try to sign into it.
Create VMs for application servers

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.
as AppServer1).
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
application.
name
you create more VMs that will host the application.
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.
Additional resources
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 topic shows how to create a new Windows Server Active Directory environment on an Azure virtual network
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 topics:
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

1. Sign in to the Azure classic portal.
2. Create a virtual network. Click Networks > Create a virtual network. Use the values in the following
table to complete the wizard.
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.
1. In the classic portal, click New > Compute > Virtual Machine > From Gallery. Use the following values
to complete the wizard. Accept the default value for a setting unless another value is suggested or required.

as AzureDC1).
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
DC role.
name
you create more VMs that will host the DC role.
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 DIP 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.
as AppServer1).
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
application.
name
you create more VMs that will host the application.
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.
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
How to install and configure Azure PowerShell
Azure PowerShell
Azure Cmdlet Reference
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)
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. Microsofts 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 will detail a series of steps and tasks that you can follow to help you design a hybrid identity solution
that meets your organizations 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 organizations 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
organizations 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 dont 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
companys 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 Microsofts 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 dont 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 organizations 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 access this tool go to https://appdiscovery.azure.com
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 organizations 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 users 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 doesnt 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 users location?
Once you understand these requirements, it is important to also evaluate the users 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, youll 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 theyre 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 premise
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 Directorys 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
youve 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, youll 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 it was explained in Determine directory synchronization requirements, Microsoft Azure AD can synchronize
with your Active Directory Domain Services (AD DS) located on-premises. This integration enables organizations
to leverage Azure AD to verify users credentials when they are trying to access corporate resources. This can be
done 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 and the replicated
partition and container corresponding to the users domain is determined. Information on the users existence,
enabled state, and role is used by the authorization system to determine whether the requested access to the
target tenant is authorized for this user in this session. Certain authorized actions (specifically, create user,
password reset) create an audit trail that can be used by a tenant administrator 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 will
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 Azures 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 will assist you on that. The
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 that the data will be.
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 users perspective. The user will try to access a shared resource, the resource requires authentication,
the user will have to send an authentication request to Azure AD in order to obtain the token and access the
resource. This entire process happens in 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 leverage Azure AD as the
main repository for users 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 leverage the Automatic File Classification in Windows Server
2012 to accomplish this.
If your organization doesnt 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, theres 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 Doesntleverage 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
Doesnt 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
tenants key with BYOK capability.
Hybrid (Azure RMS integrated with,On- This scenario accumulates the Your organization must have a cloud
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 will be
able to enable your company to use a central identity repository while allowing users and partners to use single
sign-on (SSO) as shown in the figure below:
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. Please read 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 will be used by the partner and validate if this method is supported by Azure. Currently
these are methods 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 with the
other identity providers we already support (which include Microsoft Accounts, Facebook ID, Google ID, and
Twitter ID). If the on-premises apps uses the users credential located at the companys AD DS, the access from
partners and users coming from the cloud should be transparent. You can manage users conditional access
control to (cloud-based) web applications, web API, Microsoft cloud services, 3rd 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 this in a non-production environment or with a limited amount 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 will 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 will have
it. The level of access that the user will have over a resource can vary, while Azure AD can add an additional
security layer by controlling access to some resources, you must also 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 figure
below 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 Azure Management Portal: Azure also has the capability
to control access to the Management Portal by using RBAC (Role Based Access Control). This method 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.
NOTE
read Role-based access control in Azure to know more details about this capability. For developers that 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.
3.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.
4.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 organizations 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 users activity, IT can
leverage Azure AD Access and Usage reports capability to gain visibility into the integrity and security of your
organizations 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 shown below:
Anomaly reports: Contain sign in events that we found to be anomalous. Our goal is to make you aware of
such activity and enable you to be able 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 these 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 available in Azure AD Premium that can be leveraged during an
Incident Response investigation process, IT can also leverage Audit Report to obtain information such as:
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
Since the options for incident response 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
use Azure AD reporting capability as part of your companys 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 companys data secure and maintain users 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 organizations 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 users 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 users 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 users 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
organizations 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 users credentials, policies and administration can be centralized on-premises or
in the cloud.
Hybrid: in this model the users 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 users
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 users credentials?
Does your company need to audit users 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.
Thats 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, youll 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 users 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 companys 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 wont 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 organizations 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 users 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 companys security requirement:
Multi-factor design options:
ASSET TO SECURE MFA IN THE CLOUD MFA ON-PREMISE
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 youve completed defining your requirements and examining all the options for your mobile device
management solution, youre ready to take the next steps for deploying the supporting infrastructure thats 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 companys 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 theyre 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 FR
on-premises
LDAP directory
Connect to FR
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- FR
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.
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
Writeback of
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
Writeback of
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.
1 min to read
Edit on Git Hub
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 organizations 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
replying party trust
Overview
Azure 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.
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
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 AD service limits and restrictions
This article contains the usage constraints and other service limits for the Azure Active Directory (Azure AD) service.
If youre 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 used 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 10 users can be owners of a single application.

CATEGORY LIMITS
Groups A maximum of 10 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.
What's next
How Azure subscriptions are associated with Azure AD
Integrating your on-premises identities 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 and will reach end of support on April 13, 2017.
Why use Azure AD Connect

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.
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.
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.
Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central location in
the Azure portal to view this activity. For additional information, see Azure Active Directory Connect Health.
Install Azure AD Connect

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
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 customizaton 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
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.
Monitor your on-premises identity infrastructure and
synchronization services in the cloud
Azure AD Connect Health helps you monitor and gain insight 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 AD FS Servers, Azure AD
Connect servers (aka Sync Engine), Active Directory Domain Controllers etc. It also makes the key data points
about these components easily accessible, making it easy to get usage and other important insights to take
informed decisions.
The information is presented to you in the Azure AD Connect Health Portal. Using the Azure AD Connect Health
portal you can view alerts, performance monitoring, usage analytics and much more. Azure AD Connect Health
enables the single lens of health for your key identity components, all at one place.
Future updates to Azure AD Connect Health will include additional monitoring and insight into additional identity
components. Thus providing you a single dash board through the lens of identity, enabling you to have an even
more robust, healthy, and integrated environment that your users can take advantage of to increase their ability
to get things done.
Why use Azure AD Connect Health

common identity for accessing both cloud and on-premises resources. However, with this integration comes the
challenges of ensuring that this environment is healthy so that users can reliably access resources both on-
premises and in cloud from any device. Azure AD Connect Health provides an easy cloud-based approach to
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, AD FS in Windows Server
2012 and Windows Server 2012R2. 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
View trends in performance data, useful for capacity planning of AD FS
Usage analytics for AD FS logins with different pivot (apps, users, network location etc.) useful in understand
how AD FS is getting utilized.
Reports for AD FS such as Top 50 users with bad Username/Password attempts with last IP address
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 on the synchronizations that occur
between your on-premises Active Directory and Azure Active Directory. Azure AD Connect Health for Sync
provides the following set of key capabilities:
Monitoring with alerts to know when Azure AD Connect servers aka the Sync Engine is not healthy
Email notifications for critical alerts
Sync operational insights including latency charts for Sync Operations and trends in different operations such
as adds, updates, deletes.
Quick glance information about sync properties, last successful export to Azure AD
Reports about object level synchronization errors (does not require Azure AD Premium)
The following video provides an overview of Azure AD Connect Health for sync
Azure AD Connect Health for AD DS (preview)

Azure AD Connect Health for AD DS provides monitoring for Domain Controllers installed on Windows Server
2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. An easy and low-cost
health agent installation, enables you to monitor your on-premises AD DS environment straight 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, along with email notifications for critical
alerts.
Domain Controllers dashboard, which provides a quick view into the health and operational status of your
domain controllers.
Replication Status dashboard with latest replication information, along with links to troubleshooting guides
when errors are detected.
Quick anywhere access to performance data graphs of popular performance counters, necessary for
troubleshooting and monitoring purposes.
The following video provides an overview of Azure AD Connect Health for AD DS
Get started with Azure AD Connect Health

It is very easy to get started with Azure AD Connect Health. Follow the steps below:
1. Get Azure AD Premium or start a trial
2. Download and Install Azure AD Connect Health agents on your identity servers.
3. View Azure AD Connect Health dashboard at https://aka.ms/aadconnecthealth
NOTE
Remember that before you see any data in your Azure AD Connect Health Dashboard, you will need to install the Azure AD
Connect Health Agents on your targeted servers.
Download and Install Azure AD Connect Health Agent

Make sure you satisfy the requirements for Azure AD Connect Health
To get started using Azure AD Connect Health for AD FS you can download the latest version of the agent here:
Download Azure AD Connect Health Agent for AD FS.
To get started using Azure AD Connect Health for sync, download and install the latest version of Azure AD
Connect. The health agent will be installed as part of the Azure AD Connect installation (version 1.0.9125.0 or
higher). Azure AD Connect supports an in-place upgrade from previous versions.
To get started using Azure AD Connect Health for AD DS you can download the latest version of the agent
here: Download Azure AD Connect Health Agent for AD DS.
Azure AD Connect Health Portal

The Azure AD Connect Health portal allows you to view alerts, performance monitoring, and usage analytics.
https://aka.ms/aadconnecthealth 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. Below the screenshot is a brief explanation of each of these. After you've
deployed the agents, the health service automatically identifies for the services Azure AD Connect Health is
monitoring.
Quick Start by selecting this you will open the Quick Start blade. Here you will be able to download the
Azure AD Connect Health agent by choosing Get Tools, access documentation, and provide feedback.
Active Directory Federation Services this represents all of the AD FS services that Azure AD Connect
Health is currently monitoring. By selecting one of the instances, a blade will open with information about that
services instance. This information includes an overview, properties, alerts, monitoring, and usage analytics.
Read more about the capabilities here.
Azure Active Directory Connect (Sync) this represents your Azure AD Connect servers that Azure AD
Connect Health is currently monitoring. By selecting the entry, a blade will open with information about your
Azure AD Connect servers. Read more about the capabilities here.
Active Directory Domain Services this represents all of the AD DS forests that Azure AD Connect Health is
currently monitoring. By selecting one of the forests, a blade will open with information about that forest. This
information includes an overview of essential information, Domain Controllers dashboard, Replication Status
dashboard, alerts and monitoring. Read more about the capabilities here.
Configure this allows you to turn the following on or off:
1. Auto update to automatically update the Azure AD Connect Health agent to the latest version - This
means that you will be automatically updated to the latest version of the Azure AD Connect Health
Agent when they become available. This is enabled by default.
2. Allow Microsoft access to your Azure AD directorys health data for troubleshooting purposes only -
This means that if this is enabled, Microsoft will be able to see the same data that you are seeing. This
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
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 those that administer and manage IT systems. Cyber-attackers target these accounts to gain access to
an organizations data and systems. In order 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 to manage access to Azure, 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 multi-factor authentication (MFA)
before granting privileges. MFA is a method of verifying who you are that requires the use of more than just a
Azure Multi-Factor Authentication 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, or verification code and 3rd party OATH tokens.
For an overview of how Azure Multi-Factor Authentication works see the following video.
For more details, 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), when they need to perform a task. For Azure Active Directory 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 organizations 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.

Active Directory Azure

Încărcat de

Informații document

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

Active Directory Azure

Încărcat de

Drepturi de autor:

Formate disponibile

Table of Contents

How reliable is Azure AD?

What are the benefits of Azure AD?

How does Azure AD compare to on-premises Active Directory Domain

Authentication and authorization details

Object repository details

Programmatic access details

SSO to applications details

Access management details

Group management details

Supported credentials details

How can I get started?

Where can I learn more?

Comparing generally available features

PREMIUM (P1 AND P2)

User/Group Management (add/update/delete), User-based provisioning, Device registration

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

3 Basic reports 3 Basic reports Advanced reports 3 Basic reports

Premium and Basic Features

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

Self-Service Password Reset/Change/Unlock with on-premises write-back

PREMIUM (P1 AND P2)

Multi-Factor Authentication (Cloud and On-premises (MFA Server))

PREMIUM (P1 AND P2)

Limited to cloud only for

PREMIUM (P1 AND P2)

Cloud App Discovery

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

PREMIUM (P1 AND P2)

Privileged Identity Management

Azure Active Directory Join Windows 10 only related features

PREMIUM (P1 AND P2)

Enterprise State Roaming

PREMIUM (P1 AND P2)

Azure AD preview features

Running Windows Server Active Directory in virtual machines

Using Azure Active Directory

Using Azure Active Directory Access Control

About the Author

Learn about what you can do in the preview experience

Manage the same Azure AD tenants

Use the same authorization logic

Tell us what you think

To sign up for Active Directory Premium, you have several options:

Step 1: Sign up for Active Directory Premium

Step 2: Activate your license plan

Step 4: Assign license to user accounts

Accounts that you can use to sign in

MICROSOFT ACCOUNT AZURE AD ACCOUNT

How to manage a subscription and a directory

Why can't I manage the directory with my current user account?

Using your work or school account to manage an Azure subscription

Manage the directory for your Office 365 subscription in Azure

1. Sign in to the Azure classic portal using your Microsoft account.