You are on page 1of 920

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
What is Azure Active Directory?
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
1/17/2017 9 min to read Edit on GitHub

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
Privileged Identity Management
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


Type: Common Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Administer your Azure AD directory
Azure Active Directory Device Registration overview
Single Sign-On (SSO)
Type: Common Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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
Type: Common Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
How to update your own password
Connect (Sync engine that extends on-premises directories to Azure Active Directory )
Type: Common Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Integrating your on-premises identities with Azure Active Directory
Security/Usage Reports
Type: Common Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Using a group to manage access to SaaS applications
Self-Service Password Reset for cloud users
Type: Basic Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Azure AD Password Reset for Users and Admins
Company Branding (Logon Pages/Access Panel customization )
Type: Basic Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Add company branding to your Sign In and Access Panel pages
Application Proxy
Type: Basic Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
How to provide secure remote access to on-premises applications
SLA 99.9%
Type: Basic Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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


Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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


Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

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.
Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

Cloud App Discovery


Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Finding unmanaged cloud applications with Cloud App Discovery
Azure AD Connect Health
Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Monitor your on-premises identity infrastructure and synchronization services in the cloud
Automatic password rollover for group accounts
Type: Premium Features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

Identity Protection
Type: Premium Features

FREE EDITION BASIC EDITION PREMIUM P2 EDITION OFFICE 365 APPS ONLY

Privileged Identity Management


Type: Premium Features

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)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

MDM auto-enrollment, Self-Service Bitlocker recovery, Additional local administrators to Windows 10 devices via Azure AD Join
Type: Azure Active Directory Join Windows 10 only related features
Availability:
PREMIUM (P1 AND P2)
FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

Enterprise State Roaming


Type: Azure Active Directory Join Windows 10 only related features
Availability:

PREMIUM (P1 AND P2)


FREE EDITION BASIC EDITION EDITIONS OFFICE 365 APPS ONLY

More details:
Enterprise State Roaming

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
Add company branding to your Sign In and Access Panel pages
View your access and usage reports
The fundamentals of Azure identity management
1/17/2017 13 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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
Getting started with Azure Active Directory Premium
1/17/2017 4 min to read Edit on GitHub

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
Add company branding to your Sign In and Access Panel pages
View your access and usage reports
How Azure subscriptions are associated with Azure
Active Directory
1/17/2017 9 min to read Edit on GitHub

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?
1/17/2017 10 min to read Edit on GitHub

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
Sign up for Azure as an organization
1/17/2017 1 min to read Edit on GitHub

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
1/20/2017 7 min to read Edit on GitHub

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
1/17/2017 2 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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
Manage user profiles
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
Azure Active Directory
1/17/2017 3 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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

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
Reset a user's password in the new Azure portal
Assign a user to a role in your Azure AD
Change a user's work information
Manage user profiles
Delete a user in your Azure AD
Add users from other directories or partner
companies in Azure Active Directory
1/17/2017 4 min to read Edit on GitHub

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

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
Administering Azure AD
Manage passwords in Azure AD
Manage groups in Azure AD
Delete a user from a directory in Azure Active
Directory preview
1/17/2017 1 min to read Edit on GitHub

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
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 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
Add new users to Azure Active Directory preview
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
1/17/2017 1 min to read Edit on GitHub

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


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


4. On the Users and groups - Users blade, select a user from the list.
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
Add new users to Azure Active Directory preview
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
Reset the password for a user in Azure Active
Directory preview
1/17/2017 1 min to read Edit on GitHub

How to reset the password for a user


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 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 Reset password.

6. On the Reset password blade, select Reset password.

What's next
Add a user
Assign a user to a role in your Azure AD
Change a user's work information
Manage user profiles
Delete a user in your Azure AD
Add or change work information for a user in Azure
Active Directory preview
1/17/2017 1 min to read Edit on GitHub

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


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


4. On the Users and groups - Users blade, select a user from the list.
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
Add new users to Azure Active Directory preview
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
Sharing accounts with Azure AD
1/17/2017 3 min to read Edit on GitHub

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
Article Index for Application Management in Azure Active Directory
Protecting apps with conditional access
Self-service group management/SSAA
Managing access to resources with Azure Active
Directory groups
1/17/2017 4 min to read Edit on GitHub

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
Using a group to manage access to SaaS applications
Making a group available for end user self-service
Syncing an on-premises group to Azure using Azure AD Connect
Managing owners for a group

Next steps 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
1/17/2017 1 min to read Edit on GitHub

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?


1. Sign in to the Azure portal with an account that's a global admin for the directory.
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
1/17/2017 4 min to read Edit on GitHub

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


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

Additional information
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Azure Active Directory cmdlets for configuring group settings
Article Index for Application Management in Azure Active Directory
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
Azure Active Directory preview cmdlets for group
management
1/17/2017 5 min to read Edit on GitHub

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
OnPremisesSecurityIdentifier :
ProvisioningErrors : {}
ProxyAddresses : {}
SecurityEnabled : True

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:

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
OnPremisesSecurityIdentifier :
ProvisioningErrors : {}
ProxyAddresses : {}
SecurityEnabled : True

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:

PS C:\Windows\system32> Get-AzureADGroup -Filter "DisplayName eq 'Intune Administrators'"

DeletionTimeStamp :
ObjectId : 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df
ObjectType : Group
Description : Intune Device Administrators
DirSyncEnabled :
DisplayName : Intune Administrators
LastDirSyncTime :
Mail :
MailEnabled : False
MailNickName : 4dd067a0-6515-4f23-968a-cc2ffc2eff5c
OnPremisesSecurityIdentifier :
ProvisioningErrors : {}
ProxyAddresses : {}
SecurityEnabled : True

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


72cd4bbd-2594-40a2-935c-016f3cfeeeea

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


72cd4bbd-2594-40a2-935c-016f3cfeeeea

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.
Managing access to resources with Azure Active Directory groups
Integrating your on-premises identities with Azure Active Directory
Manage the members for a group in Azure Active
Directory preview
1/17/2017 1 min to read Edit on GitHub

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?


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


4. On the Users and groups - All groups blade, select a group.
5. On the Group - *groupname* blade, select Members.

6. To add members to the group, on the Group - Members blade, select Add Members.
7. On the Members blade, select one or more users or devices to add to the group and select the Select button at
the bottom of the blade to add them to the group. The User box filters the display based on matching your
entry to any part of a user or device name. No wildcard characters are accepted in that box.
8. To remove members from the group, on the Group - Members blade, select a member.
9. On the membername blade, select the Remove command, and confirm your choice at the prompt.

10. When you finish changing members for the group, select Save.

Additional information
These articles provide additional information on Azure Active Directory.
See existing groups
Create a new group and adding members
Manage settings of a group
Manage memberships of a group
Manage dynamic rules for users in a group
Managing owners for a group
1/17/2017 1 min to read Edit on GitHub

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

Additional information
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Azure Active Directory cmdlets for configuring group settings
Article Index for Application Management in Azure Active Directory
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
Manage the groups your group is a member of in
Azure Active Directory preview
1/17/2017 1 min to read Edit on GitHub

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?


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


4. On the Users and groups - All groups blade, select a group.
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.

Additional information
These articles provide additional information on Azure Active Directory.
See existing groups
Create a new group and adding members
Manage settings of a group
Manage members of a group
Manage dynamic rules for users in a group
View all existing groups in Azure Active Directory
preview
1/17/2017 1 min to read Edit on GitHub

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?


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

Additional information
These articles provide additional information on Azure Active Directory.
See existing groups
Create a new group and adding members
Manage settings of a group
Manage members of a group
Manage memberships of a group
Manage dynamic rules for users in a group
Dedicated groups in Azure Active Directory
1/17/2017 1 min to read Edit on GitHub

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


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 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.
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Article Index for Application Management in Azure Active Directory
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
Using a group to manage access to SaaS applications
1/17/2017 2 min to read Edit on GitHub

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
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Article Index for Application Management in Azure Active Directory
Azure Active Directory cmdlets for configuring group settings
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
Manage the settings for a group in Azure Active
Directory preview
1/17/2017 1 min to read Edit on GitHub

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?


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


4. On the Users and groups - All groups blade, select a group.
5. On the Group - *groupname* blade, select Properties.

6. When you finish changing properties for the group, select Save.
Additional information
These articles provide additional information on Azure Active Directory.
See existing groups
Create a new group and adding members
Manage members of a group
Manage memberships of a group
Manage dynamic rules for users in a group
Azure Active Directory cmdlets for configuring group
settings
1/17/2017 3 min to read Edit on GitHub

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


You can find more Azure Active Directory PowerShell documentation at Azure Active Directory Cmdlets.

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
You can find more Azure Active Directory PowerShell documentation at Azure Active Directory Cmdlets.
Additional instruction from Microsoft program manager Rob de Jong is available at Rob's Groups Blog.
Managing access to resources with Azure Active Directory groups
Integrating your on-premises identities with Azure Active Directory
Using attributes to create advanced rules for group
membership in Azure Active Directory preview
1/17/2017 6 min to read Edit on GitHub

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


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


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
multiple errors. Parenthesis not in right
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

PROPERTIES ALLOWED VALUES USAGE

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


PROPERTIES ALLOWED VALUES USAGE

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:

PROPERTIES ALLOWED VALUES USAGE

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

Additional information
These articles provide additional information on groups in Azure Active Directory.
See existing groups
Create a new group and adding members
Manage settings of a group
Manage memberships of a group
Manage dynamic rules for users in a group
Using attributes to create advanced rules
1/17/2017 7 min to read Edit on GitHub

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


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 you want to edit.
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
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
multiple errors. Parenthesis not in right
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

PROPERTIES ALLOWED VALUES USAGE

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


PROPERTIES ALLOWED VALUES USAGE

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.
2. Select the Groups tab, and then open the group you want to edit.
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:

PROPERTIES ALLOWED VALUES USAGE

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)


PROPERTIES ALLOWED VALUES USAGE

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.

Additional information
These articles provide additional information on Azure Active Directory.
Troubleshooting dynamic memberships for groups
Managing access to resources with Azure Active Directory groups
Azure Active Directory cmdlets for configuring group settings
Article Index for Application Management in Azure Active Directory
Integrating your on-premises identities with Azure Active Directory
Setting up Azure Active Directory for self-service
group management
1/17/2017 3 min to read Edit on GitHub

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.

Additional information
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Azure Active Directory cmdlets for configuring group settings
Article Index for Application Management in Azure Active Directory
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
Troubleshooting dynamic memberships for groups
1/17/2017 1 min to read Edit on GitHub

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.
These articles provide additional information on Azure Active Directory.
Managing access to resources with Azure Active Directory groups
Article Index for Application Management in Azure Active Directory
What is Azure Active Directory?
Integrating your on-premises identities with Azure Active Directory
View your access and usage reports
1/17/2017 8 min to read Edit on GitHub

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

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

Password reset activity


DESCRIPTION REPORT LOCATION

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

Password reset registration activity


DESCRIPTION REPORT LOCATION

Shows all password reset registrations that have occurred in Directory > Reports tab
your organization

Self service groups activity


DESCRIPTION REPORT LOCATION

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

Integrated applications reports


Application usage: summary
DESCRIPTION REPORT LOCATION

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
DESCRIPTION REPORT LOCATION

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
DESCRIPTION REPORT LOCATION

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
Account provisioning errors
DESCRIPTION REPORT LOCATION

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
DESCRIPTION REPORT LOCATION

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
DESCRIPTION REPORT LOCATION

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 Premium
Add company branding to your Sign In and Access Panel pages
Getting started with Azure Active Directory
Reporting
1/17/2017 3 min to read Edit on GitHub

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
Account provisioning errors
Individual user devices
Individual user Activity
Groups activity report
Password Reset Registration Activity Report
Password reset activity
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
For more documentation on Azure AD Reporting, check out View your access and usage reports.

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
For more documentation on Azure AD Reporting, check out View your access and usage reports.
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
For more documentation on Azure AD Reporting, check out View your access and usage reports.
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
For more documentation on Azure AD Reporting, check out View your access and usage reports.
Known networks
1/18/2017 1 min to read Edit on GitHub

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:
View your access and usage reports
Sign ins from IP addresses with suspicious activity
Sign ins from multiple geographies
Azure Active Directory Reporting Guide
1/19/2017 1 min to read Edit on GitHub

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
1/19/2017 4 min to read Edit on GitHub

This documentation is part of the Azure Active Directory Reporting Guide.


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
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 3 min to read Edit on GitHub

This topic is part of a collection of topics about the Azure Active Directory reporting API.
Azure AD reporting provides you with an API that enables you to access audit data using code or related tools. The
scope of this topic is to provide you with reference information about the audit API.
See:
Audit logs for more conceptual information
Getting started with the Azure Active Directory Reporting API for more information about the reporting API.
For questions, issues or feedback, please contact AAD Reporting Help.

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
Supported operators: eq, contains, startsWith
Example:

$filter=actor/name eq 'test' or contains(actor/name, 'test') or startswith(actor/name, 'test')

Notes:
case-insensitive

actor/objectId
Supported operators: eq
Example:

$filter=actor/objectId eq 'e8096343-86a2-4384-b43a-ebfdb17600ba'

target/name
Supported operators: eq, contains, startsWith
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
Supported operators: eq
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
1/17/2017 3 min to read Edit on GitHub

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 sample code for the audit API.
See:
Audit logs for more conceptual information
Getting started with the Azure Active Directory Reporting API for more information about the reporting API.
For questions, issues or feedback, please contact AAD Reporting Help.

Prerequisites
Before you can use the samples in this topic, you need to complete the prerequisites to access the Azure AD
reporting API.

Known issue
App Auth will not work if your tenant is in the EU region. Please use User Auth for accessing the Audit API as a
workaround until we fix the issue.

PowerShell script
# This script will require registration of a Web Application in Azure Active Directory (see
https://azure.microsoft.com/documentation/articles/active-directory-reporting-api-getting-started/)

# Constants
$ClientID = "your-client-application-id-here" # Insert your application's Client ID, a Globally
Unique ID (registered by Global Admin)
$ClientSecret = "your-client-application-secret-here" # Insert your application's Client Key/Secret string
$loginURL = "https://login.microsoftonline.com" # AAD Instance; for example
https://login.microsoftonline.com
$tenantdomain = "your-tenant-domain.onmicrosoft.com" # AAD Tenant; for example, contoso.onmicrosoft.com
$resource = "https://graph.windows.net" # Azure AD Graph API resource URI
$7daysago = "{0:s}" -f (get-date).AddDays(-7) + "Z" # Use 'AddMinutes(-5)' to decrement minutes, for
example
Write-Output "Searching for events starting $7daysago"

# Create HTTP header, get an OAuth2 access token based on client id, secret and tenant domain
$body =
@{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body
$body

# Parse audit report items, save output to file(s): auditX.json, where X = 0 thru n for number of nextLink
pages
if ($oauth.access_token -ne $null) {
$i=0
$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
$url = 'https://graph.windows.net/' + $tenantdomain + 'activities/audit?api-
version=beta&`$filter=activityDate gt ' + $7daysago

# loop through each query page (1 through n)


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

# save the query page to an output file


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

Write-Host "Press any key to continue ..."


$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

Executing the PowerShell script


Once you finish editing the script, run it and verify that the expected data from the Audit logs report is returned.
The script returns output from the audit report in JSON format. It also creates an audit.json file with the same
output. You can experiment by modifying the script to return data from other reports, and comment out the output
formats that you do not need.

Bash script
#!/bin/bash

# Author: Ken Hoff (kenhoff@microsoft.com)


# Date: 2015.08.20
# NOTE: This script requires jq (https://stedolan.github.io/jq/)

CLIENT_ID="your-application-client-id-here" # Should be a ~35 character string insert your info here


CLIENT_SECRET="your-application-client-secret-here" # Should be a ~44 character string insert your info here
LOGIN_URL="https://login.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
1/17/2017 3 min to read Edit on GitHub

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
For questions, issues or feedback, please contact AAD Reporting Help.

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


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. In the applications list, select your newly created application.

5. In the menu on the top, click Configure.

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

4. In the Domain Name column, copy your domain name.

Get the application's client ID


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. In the applications list, select your newly created application.

5. In the menu on the top, click Configure.

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.
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. In the applications list, select your newly created application.

5. In the menu on the top, click Configure.

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.
If you would like to find out more about Azure Active Directory reporting, see the Azure Active Directory
Reporting Guide.
Azure Active Directory sign-in activity report API
reference
1/17/2017 3 min to read Edit on GitHub

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 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
Getting started with the Azure Active Directory Reporting API for more information about the reporting API.
For questions, issues or feedback, please contact AAD Reporting Help.

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
Supported operators: eq
Example:

$filter=userId+eq+00000000-0000-0000-0000-000000000000

Notes:
The value of userId is a string value

userPrincipalName
Supported operators: eq
Example:

$filter=userPrincipalName+eq+'audrey.oliver@wingtiptoysonline.com'

Notes:
The value of userPrincipalName is a string value

appId
Supported operators: eq
Example:

$filter=appId+eq+00000000-0000-0000-0000-000000000000

Notes:
The value of appId is a string value

appDisplayName
Supported operators: eq
Example:

$filter=appDisplayName+eq+'Azure+Portal'

Notes:
The value of appDisplayName is a string value

loginStatus
Supported operators: eq
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
1/17/2017 2 min to read Edit on GitHub

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 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:
Audit logs for more conceptual information
Getting started with the Azure Active Directory Reporting API for more information about the reporting API.
For questions, issues or feedback, please contact AAD Reporting Help.

Prerequisites
Before you can use the samples in this topic, you need to complete the prerequisites to access the Azure AD
reporting API.

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 =
@{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

if ($oauth.access_token -ne $null) {


$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}

$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"
$myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -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 {

Write-Host "ERROR: No Access Token"


}

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.
If you would like to find out more about Azure Active Directory reporting, see the Azure Active Directory
Reporting Guide.
Azure Active Directory audit report events
1/17/2017 15 min to read Edit on GitHub

This documentation is part of the Azure Active Directory Reporting Guide.


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.


EVENTS EVENT DESCRIPTION

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.


EVENTS EVENT DESCRIPTION

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.
EVENTS EVENT DESCRIPTION

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.


EVENTS EVENT DESCRIPTION

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.


EVENTS EVENT DESCRIPTION

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.


ATTRIBUTE DESCRIPTION

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

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.
ATTRIBUTE DESCRIPTION

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


defined set.

"Update Device" attributes


ATTRIBUTE DESCRIPTION

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.

DirSyncEnabled Indicates whether synchronization occurs from an


authoritative (customer, on premise) directory.

DisplayName The display name for an object

IsCompliant This attribute is used to manage the mobile device


management status of the device.
ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

AccountEnabled Indicates whether a security principal can authenticate.

AppPrincipalId External, application-defined identity for a security principal.

DisplayName The display name for an object

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


ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

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.

DisplayName The display name for an 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).
ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

AssignableScopes Collection of authorization scopes that can be referenced


when assigning this RoleDefinition to a security principal.

DisplayName The display name for an object

GrantedPermissions Permissions granted by this RoleDefinition.

"Update Administrative Unit" attributes


ATTRIBUTE DESCRIPTION

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


ATTRIBUTE DESCRIPTION

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.

DirSyncEnabled Indicates whether synchronization occurs from an


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.
ATTRIBUTE DESCRIPTION

DirectoryFeatures Enabled/disabled directory features.

DirSyncConfiguration Contains all DirSync configuration specific to the current


tenant.

DisplayName The display name for an object

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


ATTRIBUTE DESCRIPTION

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.
ATTRIBUTE DESCRIPTION

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
1/17/2017 1 min to read Edit on GitHub

This documentation is part of the Azure Active Directory Reporting Guide.


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
1/17/2017 1 min to read Edit on GitHub

This documentation is part of the Azure Active Directory Reporting Guide.

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
1/17/2017 1 min to read Edit on GitHub

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
Getting started with Azure Active Directory Premium
Add company branding to your Sign In and Access Panel pages
Irregular sign-in activity
1/17/2017 1 min to read Edit on GitHub

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.
Sign-ins after multiple failures
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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.
Sign-ins from multiple geographies
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 1 min to read Edit on GitHub

This is an aggregate report that combines suspicious sign-ins from the following reports:
Sign ins from unknown sources
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
Manage passwords in Azure Active Directory
1/17/2017 1 min to read Edit on GitHub

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
Administering Azure AD
Create or edit users in Azure AD
Manage groups in Azure AD
How to update your own password
1/17/2017 9 min to read Edit on GitHub

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
authentication email (you choose).
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:
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 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
authentication email (you choose).
Text my mobile phone - texts your phone with a 6 digit code to either your mobile phone or
authentication email (you choose).
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
1/17/2017 6 min to read Edit on GitHub

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.

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
Password policies and restrictions in Azure Active
Directory
1/17/2017 2 min to read Edit on GitHub

This article describes the password policies and complexity requirements associated with user accounts stored in
your Azure AD directory.

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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
1/17/2017 1 min to read Edit on GitHub

How to reset the password for a user


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 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 Reset
password.

6. On the Reset password blade, select Reset password.

What's next
Add a user
Assign a user to a role in your Azure AD
Change a user's work information
Manage user profiles
Delete a user in your Azure AD
Reset the password for a user
1/17/2017 1 min to read Edit on GitHub

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.
1. Open your directory.
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
Administering Azure AD
Manage passwords in Azure AD
Manage groups in Azure AD
Set password expiration policies in Azure Active
Directory
1/17/2017 2 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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


1. Connect to Windows PowerShell using your company administrator credentials.
2. Do one of the following:
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


1. Connect to Windows PowerShell using your company administrator credentials.
2. Do one of the following:
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
Are you here because you're having problems signing in? If so, here's how you can change and reset your
own password.
Getting started with Password Management
1/17/2017 19 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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 1: Configure password reset policy
Step 2: Add contact data for your test user
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.
Step 1: Configure password reset policy
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.
Step 2: Add contact data for your test user
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 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
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.

Step 1: Download the latest version of Azure AD Connect


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.

Step 3: Configure your firewall


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.
Links to password reset documentation
Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
How it works - learn about the six different components of the service and what each does
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
Deploying Password Management and training users
to use it
1/17/2017 8 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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!
Links to password reset documentation
Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
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
Azure AD Password Reset for IT Administrators
1/17/2017 11 min to read Edit on GitHub

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.

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset your
own password.
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
Customizing Password Management to fit your
organization's needs
1/17/2017 20 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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.
Policy Control Description Affects?

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
http://aka.ms/ssprsetup.

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
http://aka.ms/ssprsetup.
Password reset portal:
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
http://aka.ms/ssprsetup.
Password reset portal:
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.

Registration portal:
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.

Password reset portal:


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.
(Only visible if users enabled for
password reset is set to yes).
Registration portal:
Determines the minimum
number of authentication
methods a user must register
before being able to finish the
registration experience.

Password reset portal:


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.

Registration portal:
Determines the minimum
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.

Password reset portal:


Determines the minimum
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
questions required to register.

Registration portal:
Determines which questions a
user is able to provide answers
for when registering for
password reset.

Password reset portal:


Determines which questions a
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
questions required to register.

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.

Registration portal:
Determines which questions a
user is able to provide answers
for when registering for
password reset.

Password reset portal:


Determines which questions a
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).
Registration portal:
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.
(Only visible if users enabled for
password reset is set to yes).
Password reset portal:
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


administrators, send the
email to all user
administrators, up to a
maximum of 100 total
recipients.

If there are no user


administrators, send the
email to all global
administrators, up to a
maximum of 100 total
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.

Registration portal:
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.

Password reset portal:


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.
Password reset portal:
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.

Policy Control Description Affects?


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.

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
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 to get operational insights with Password
Management reports
1/17/2017 8 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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:

COLUMN ALLOWED VALUES AND THEIR MEANINGS

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.
COLUMN ALLOWED VALUES AND THEIR MEANINGS

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

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
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
Learn more about Password Management
1/17/2017 14 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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:
Authentication Phone
Authentication Email
Security Questions and Answers
If you have provided a value for Mobile Phone or Alternate Email, users can immediately use those 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
Authentication Phone
Authentication Email
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

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
Password Management Frequently Asked Questions
1/17/2017 11 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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.

Links to password reset documentation


Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
Troubleshooting - learn how to quickly troubleshoot problems with the service
Learn more - go deep into the technical details of how the service works
How to troubleshoot Password Management
1/17/2017 38 min to read Edit on GitHub

IMPORTANT
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
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.

Information to include when you need help


If you cannot solve your issue with the guidance below, you can contact our support engineers. When you
contact them, 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:

Error Case What error does a user see? Solution

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:

Error Case What error does a user see? Solution

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:

Error Case What error does a user see? Solution

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:

Error Case What error does a user see? Solution


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


the on-premises service
detected a password
change request for a
federated or password
hash syncd user
originating from the
cloud. This event is the
first event in every
password change
writeback operation.

31007 ChangePasswordSucces PasswordResetService This event indicates that


s a user selected a new
password during a
password change
operation, we
determined that this
password meets
corporate password
requirements, and that
password has been
successfully written
back to the local AD
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,
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 situations can
cause this error.

31009 ResetUserPasswordByA PasswordResetService The on-premises service


dminStart detected a password
reset request for a
federated or password
hash syncd user
originating from the
administrator on behalf
of a user. This event is
the first event in every
admin-initiated
password reset
writeback operation.
31010 ResetUserPasswordByA PasswordResetService The admin selected a
dminSuccess new password during
an admin-initiated
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.

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,
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.
31012 OffboardingEventStart PasswordResetService This event occurs if you
disable Password
Writeback with Azure
AD Connect and
indicates that we
started offboarding
your organization to
the Password Writeback
web service.

31013 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


the Password Writeback
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-
premises environment.
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
authorization token for
the global administrator
account specified during
Azure AD Connect
setup. This error can be
caused by a bad
username or password
specified for the global
admin account 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
the on-premises service
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
https://ssprsbprodncu-
sb.accesscontrol.window
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
Azure AD Connect, only
very early builds of
DirSync which
supported writeback.

32013 OffBoardingError PasswordResetService This event indicates that


the on-premises service
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
authorization token for
your tenant. To fix this,
ensure that you are not
blocking outbound
connections over 443
or to
https://ssprsbprodncu-
sb.accesscontrol.window
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-
premises environment.
This event indicates that
we found two users in
your on-premises
directory with the same
cloud anchor attribute.
Check your sync logs,
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
the Password Writeback
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
Azure AD Connect, only
very early builds of
DirSync which
supported writeback.

34002 ADNotReachableError PasswordResetService DEPRECATED This


event is not present in
Azure AD Connect, only
very early builds of
DirSync which
supported writeback.

34003 ADInvalidAnchorError PasswordResetService DEPRECATED This


event is not present in
Azure AD Connect, only
very early builds of
DirSync which
supported writeback.

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
Troubleshoot Password Writeback
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.
Links to password reset documentation
Below are links to all of the Azure AD Password Reset documentation pages:
Are you here because you're having problems signing in? If so, here's how you can change and reset
your own password.
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
Learn more - go deep into the technical details of how the service works
Join a personal device to your organization
1/17/2017 1 min to read Edit on GitHub

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.

Additional information
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
1/17/2017 1 min to read Edit on GitHub

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

Additional information
Learn about usage scenarios for Azure AD Join
Connect domain-joined devices to Azure AD for Windows 10 experiences
Set up Azure AD Join
Authenticating identities without passwords through Microsoft Passport
Conditional access in Azure Active Directory
1/17/2017 4 min to read Edit on GitHub

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
1/17/2017 4 min to read Edit on GitHub

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
Article Index for Application Management in Azure Active Directory
Applications that use conditional access rules in Azure
Active Directory
1/17/2017 4 min to read Edit on GitHub

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"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

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)"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

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"] &&
c2:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~
"(/adfs/ls)|(/adfs/oauth2)"]
=> 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"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

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)"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
Get started with Azure Active Directory Device
Registration
1/17/2017 4 min to read Edit on GitHub

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.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.
4. Select the Configure tab.
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.
3. On the left pane, select Active Directory.
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
1/17/2017 4 min to read Edit on GitHub

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

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
Azure Active Directory Device Registration overview
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
How to configure automatic registration of Windows
domain-joined devices with Azure Active Directory
1/17/2017 11 min to read Edit on GitHub

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
Windows Server 2008 R2

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


AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

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


AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> 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
1/17/2017 2 min to read Edit on GitHub

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

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
Azure Active Directory Device Registration overview
Automatic device registration with Azure Active Directory for Windows 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
Configure automatic device registration for Windows
8.1 domain joined devices
1/17/2017 3 min to read Edit on GitHub

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

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 Active Directory Device Registration overview
Automatic device registration with Azure Active Directory for Windows 10 domain-joined devices
Configure automatic device registration for Windows 7 domain joined devices
Azure Authenticator for Android
1/17/2017 6 min to read Edit on GitHub

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
1/17/2017 3 min to read Edit on GitHub

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
1/17/2017 4 min to read Edit on GitHub

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
Azure Active Directory conditional access
Setting up on-premises conditional access using
Azure Active Directory Device Registration
1/17/2017 12 min to read Edit on GitHub

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.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.
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
Article Index for Application Management in Azure Active Directory
Azure Active Directory Conditional Access FAQ
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 3 min to read Edit on GitHub

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 R2
Windows Server 2012
Windows Server 2008 R2
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
1. Open the Settings app.
2. Click System > About.
3. Click Join Azure AD.
4. Authenticate to your organization, provide multi-factor authentication if prompted, and then follow the steps
that are shown.
5. Sign out, and then sign in with your work account (your Azure AD account).
6. Try again to access the application.
To add your work or school account, do the following steps:
Windows 10 Anniversary Update
1. Open the Settings app.
2. Click Accounts > Access work or school.
3. Click Connect.
4. Authenticate to your organization, provide multi-factor authentication if prompted, and then follow the steps
that are shown.
5. Try again to access the application.
Windows 10 November 2015 Update
1. Open the Settings app.
2. Click Accounts > Your accounts.
3. Click Add work or school account.
4. Authenticate to your organization, provide multi-factor authentication if prompted, and then follow the steps
that are shown.
5. Try again to access the application.
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.
4. Authenticate to your organization, provide multi-factor authentication if prompted, and then follow the steps
that are shown.
5. Click Turn on.
6. Try again to access the application.
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
Azure Active Directory Conditional Access technical
reference
1/17/2017 3 min to read Edit on GitHub

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
Article Index for Application Management in Azure Active Directory
Extending cloud capabilities to Windows 10 devices
through Azure Active Directory Join
1/17/2017 6 min to read Edit on GitHub

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.

Additional information
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
Usage scenarios and deployment considerations for
Azure AD Join
1/17/2017 3 min to read Edit on GitHub

Usage scenarios for Azure AD Join


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

Deployment considerations for Azure AD Join


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

Enable BYOD in your organization for Windows 10


You can set up your users and employees to use their personal Windows devices (BYOD) to access company apps
and resources. Your users can add their Azure AD accounts (work or school accounts) to a personal Windows
device to access resources in a secure and compliant fashion.
Prerequisites
At the enterprise level (administrator)
Azure AD subscription
At the user level
Windows 10 (Professional and Enterprise editions)
Administrator tasks
Set up device registration
User tasks
Join a personal Windows 10 device to your organization

Additional information
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
Setting up Azure AD Join in your organization
1/17/2017 1 min to read Edit on GitHub

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.

Set up device registration


1. Log on to the Azure portal as an administrator.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.
4. Select the Configure tab.
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

Additional information
Windows 10 for the enterprise: Ways to use devices for work
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
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 new device with Azure AD during Setup
1/17/2017 2 min to read Edit on GitHub

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.

Additional information
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
Connect domain-joined devices to Azure AD for
Windows 10 experiences
1/17/2017 2 min to read Edit on GitHub

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

Additional information
Windows 10 for the enterprise: Ways to use devices for work
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
Learn about usage scenarios for Azure AD Join
Connect domain-joined devices to Azure AD for Windows 10 experiences
Set up Azure AD Join
Authenticating identities without passwords through
Microsoft Passport
1/17/2017 3 min to read Edit on GitHub

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.

Additional information
Windows 10 for the enterprise: Ways to use devices for work
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
Learn about usage scenarios for Azure AD Join
Connect domain-joined devices to Azure AD for Windows 10 experiences
Set up Azure AD Join
Enable Microsoft Windows Hello for Business in your
organization
1/17/2017 3 min to read Edit on GitHub

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
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
Windows 10 for the enterprise: Ways to use devices
for work
1/17/2017 1 min to read Edit on GitHub

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
1/17/2017 9 min to read Edit on GitHub

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:
An Azure AD subscription.
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 subscription.
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.

Additional information
Windows 10 for the enterprise: Ways to use devices for work
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
Learn about usage scenarios for Azure AD Join
Connect domain-joined devices to Azure AD for Windows 10 experiences
Set up Azure AD Join
Get started with certificate based authentication on
Android
1/17/2017 6 min to read Edit on GitHub

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:

Get-AzureADTrustedCertificateAuthority

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


1. Retrieve the certificate authorities:
$c=Get-AzureADTrustedCertificateAuthority
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
1/17/2017 6 min to read Edit on GitHub

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:

Get-AzureADTrustedCertificateAuthority

Retrieving the list certificate authorities


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

Get-AzureADTrustedCertificateAuthority

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


1. Retrieve the certificate authorities:
$c=Get-AzureADTrustedCertificateAuthority
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:

$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).
Managing Applications with Azure Active Directory
1/17/2017 6 min to read Edit on GitHub

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
Article Index for Application Management in Azure Active Directory
Integrating Azure Active Directory with applications
getting started guide
1/17/2017 3 min to read Edit on GitHub

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 follo