03 - Azure Active Directory Retail Deployment Guide - Security

Securing Your Identities with Azure
AD
Microsoft Azure™ Active Directory Deployment Guide
for Retail Industry Customers
Abstract
As a follow-on to configuring identities at scale, and enabling productivity, this guide helps you enable a holistic security
posture for information and kiosk workers.
Intended Audience
Identity Architects, Deployment Advisors, and System Integrators
Microsoft Corporation
Securing Your Identities with Azure AD
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of publication.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN

THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
The descriptions of other companies’ products in this document, if any, are provided only as a
convenience to you. Any such references should not be considered an endorsement or support by
Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the
descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For
authoritative descriptions of these products, please consult their respective manufacturers.
© 2016 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without
express authorization of Microsoft Corp. is strictly prohibited.
Microsoft and Windows are either registered trademarks of Microsoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
Microsoft Azure Active Directory Deployment Guide Page ii

Table of Contents
Overview ................................................................................................................................... 4
Key Concepts ............................................................................................................................ 5
Build Your Identity Organization Teams .................................................................................... 7
Prerequisites ............................................................................................................................. 8
Security Deployment Guidelines ................................................................................................ 9

Deploying Multi-Factor Authentication .............................................................................................................................. 9
Deploying Conditional Access Policies ............................................................................................................................ 12
Assigning Administrative Roles ........................................................................................................................................... 15
Using Security Reports ........................................................................................................................................................... 18
Security with Windows 10 ........................................................................................................ 21
Additional EMS Security Components ...................................................................................... 22
Conclusion .............................................................................................................................. 23
Reference ................................................................................................................................ 24
Microsoft Azure Active Directory Deployment Guide Page 3

Overview
Azure Active Directory (AD) Premium is a cloud-based identity and access management (IAM) system. The
Managing Identity Lifecycles at Scale guide addresses the onboarding and off-boarding processes for
workers in your organization. The Increasing Productivity with Azure AD guide addresses how to manage
applications and provide self service capabilities to those workers. The third deployment guide in this
series dedicated to customers in the Retail Industry focuses on security.
When used to secure identities, Azure AD Premium solves common challenges:
▪ Multi-factor Authentication provides additional factors of authentication beyond passwords.
▪ Conditional Access allows you to configure access policies based on different criteria such as location,
device state and risk level.
▪ Administrative Roles allow you to perform administrative tasks with the minimum level of privileges
necessary, granted on demand and for a limited amount of time.
▪ Security Reporting gives you visibility into activity such as sign ins-and auditing.

Key Concepts
Multi-Factor Authentication (MFA)
The use of more than one verification method, which adds a layer of security to user sign-ins and
transactions. MFA works by requiring two or more of the following verification methods:
▪ Something you know (typically a password)

▪ Something you have (a trusted device that is not easily duplicated, like a phone)
▪ Something you are (biometrics)
Learn More: Azure Multi-Factor Authentication – What is It?
Device Registration / Authentication

Registering a device in Azure AD, providing the device an identity which can be used to authenticate it
when users sign-in. Authenticated devices, as well as the attributes of the device, can be used to enforce
conditional access policies for applications.
Learn More: Azure Active Directory Device Registration overview
Privileged Identities
User accounts that have one or more administrative roles to manage, control, and monitor access to
resources in Azure AD as well as other Microsoft online services.
Learn More: Azure AD Privileged Identity Management
Just-Enough-Access (JEA)
Granting the minimum level of permissions required to accomplish a set of administrative tasks.
Just-In-Time Access (JIT)

Giving administrative accounts privileges only when needed, with additional security controls and
reporting.
Conditional Access
Creating policies that grant access to resources based on the context of a request such as network
location (inside or outside the corporate network), device used (compliant or known), or risk level.

Learn More: Azure Active Directory conditional access
Machine Learning
A technique of data science that helps computers learn from existing data in order to forecast future
behaviors, outcomes, and trends. Azure AD uses machine learning techniques to assess risk events.
Learn More: What is Machine Learning? and Azure Active Directory Identity Protection
Risk Event
Logins flagged as suspicious by Azure AD Identity Protection, indicating that an identity might have been
compromised.
Learn More: Azure Active Directory Identity Protection

Build Your Identity Organization

Teams
Identity Organization teams and responsibilities
Team Responsibilities
Identity Architecture / Development ▪ Designs the solution in cooperation with stakeholders.
Team ▪ Owns the development process and creates the user acceptance environments.
▪ Documents the solution design and operational procedures and hands them off
to the operations team.
On-premises Identity Operations ▪ Manages on-premises identity sources such as Active Directory Forests, LDAP
Team directories, HR systems, and Federation Identity Providers.
▪ Performs any remediation tasks needed before synchronizing objects to the
cloud.
▪ Provides the service accounts required for directory synchronization to take place.
▪ Provides access to configure federation to Azure AD.
Security Team ▪ Defines the security strategy.
▪ Defines access policies to resources.
▪ Provides security requirements for IT solutions.
▪ Reviews security aspects of IT solutions.
▪ Analyzes security reports from various sources and follows through on findings.
Application Business Owners ▪ Includes business stakeholders who use the applications.
▪ Understand the application use cases and have the best context of who should be
assigned to the application.
Azure AD Administrator ▪ Manages the Azure AD configuration.
▪ Provides credentials to configure the synchronization service.
▪ May assign Azure AD administrative roles to distribute administration
responsibilities, including password, application, and user management.
▪ May use Administrative Units (AU) to divide management boundaries based on
geography, department or similar criteria.
Network Team ▪ Owns the network infrastructure.
▪ Provides the required access at the network level for the synchronization service
to access the data sources and cloud services (firewall rules, ports opened, IPsec
rules and so on).
Helpdesk ▪ Manages support incidents related to the migration process.
Learn More: Assign administrator roles in Azure Active Directory, Office 365, Azure AD Administrative
Units

Prerequisites
Review the following process for configuring prerequisites:
Process for configuring prerequisites

Set Up Common Infrastructure
Create Azure AD Tenant(s) and activate Azure AD Premium license(s). Get an Azure AD Tenant
1. Azure AD Tenant is the home for your organization’s directory in the cloud. Most Introducing Enterprise Mobility
features discussed in this guide are available as part of Azure AD Premium and/or EMS. + Security
Create and configure custom domains. Add Domain
2.
Users reach your cloud and on-premises resources through domains.
Populate identities in Azure AD. Managing Identities at Scale
3. The users and groups must exist in the directory before they can be assigned access to retail guide
resources.
Determine Security Policy Aspects
Identify set of resources to protect. Increasing Productivity with
4. This list will provide a concrete scope of security requirements that will determine Azure AD retail guide
policies, deployment options, and available tools.
Define control functions and map to Azure AD Administration Roles. Azure AD Administration Roles
5. Roles must be assigned based on control functions, enterprise team structure and
operational requirements.
Define necessary Multi-Factor infrastructure. What is Azure Multi-Factor
The target experiences and scenarios will determine which MFA solution to deploy Authentication?
6.
(Azure MFA cloud-based solution, Azure MFA Server on-premises, smart cards, or third
party)
Define approach to representing internal networks in Azure AD. Azure Active Directory
Security policies based on network location (i.e., inside or outside the corporate network) Conditional Access technical
7. require one of the following: reference
▪ The IP addresses that constitute the internal network.
▪ A claim from the Identity Provider for federated domains.
Define on-premises security monitoring requirements and infrastructure. ATA Prerequisites
8.
An on-premises infrastructure is required to deploy Advanced Threat Analytics (ATA).

Security Deployment Guidelines

It is important to define the organization’s security posture by deploying multi-factor authentication,
defining access policies for resources, establishing role-based access control guidelines, and analyzing
security reports on an ongoing basis. This gives you a consistent set of principles whenever you onboard
new resources or actors.
Deploying Multi-Factor Authentication

Azure AD makes the onboarding of SaaS applications very straightforward. Once you have addressed the
prerequisites described above, consider the following:
Assess resources to be protected

Which kind of resources you want to protect with Multi-Factor Authentication will determine which MFA
component to deploy:
▪ MFA in the cloud: Suitable for Azure AD-protected resources such as Office 365, SaaS applications,
and internal applications published with Azure AD Application Proxy. Azure MFA in the cloud can also
be used with Windows Server 2016 for any claims-based applications that trust AD FS on-premises.
▪ MFA Server: Best for scenarios that span beyond Azure AD, such as VPN, Legacy LDAP applications, or
stand-alone usage through the SDK.
We recommend using MFA in the cloud unless it does not support the desired scenarios. When examining
on-premises resources, consider the decision from the broader toolset perspective to determine whether
a cloud-based solution will meet your requirements. A few examples:
▪ An on-premises IIS server can be published via Azure AD application proxy and use MFA in the cloud.
▪ An AD FS application can be moved to Azure AD for SSO and use MFA in the cloud.
As a cloud service, Azure AD is constantly evolving and incorporating new functionality. As a result, the
gap between the cloud-based MFA and on-premises MFA Server will reduce over time.
Learn more: Azure Multi-Factor Authentication – Getting Started
Defining Multi-Factor Authentication Methods

Deciding which MFA authentication methods to offer your users requires understanding the employee
work environment, corporate policies and local regulations. Below are some considerations:
Software Tokens / Authenticator app
Software on mobile devices (smartphone or wearable) use cryptographic algorithms to prove identity.

Advantages Tradeoffs
▪ Mobile applications can leverage computing power in the ▪ Dependency on availability of the device (battery, data
device to enable additional techniques, including Time- plan, Wi-Fi, etc.)
based One-time Password (TOTP), HMAC-based One-time ▪ Higher learning curve for users who are not tech savvy.
Password (HOTP), etc. ▪ More overhead in the onboarding process, since the
▪ More flexible authentication experiences. mobile device needs to be configured for use as a second
▪ Software can be updated on a regular basis, which enables factor.
future innovation, patching, leveraging of security ▪ Depending on the authentication method used, end-users
capabilities in the mobile platform (e.g., fingerprint may incur data costs when using their device to
readers), etc. authenticate.
▪ Users don’t need to carry another device beyond their
smartphone.
Hardware Tokens
A dedicated hardware token (Smart Card, USB dongle, or key fob) serves as a second factor.
▪ If your enterprise already uses hardware tokens, Azure AD ▪ Overhead of procuring and tracking hardware tokens.
can be integrated with these existing investments. ▪ Unlike phones, users only carry hardware tokens to
▪ Can work in harsher environments than a smartphone can. perform authentications, and are therefore more likely
▪ Less dependency on availability of network, battery, Wi-Fi, forget or lose the device.
etc. ▪ Hardware tokens are not easy to update, putting limits on
the ability to update or upgrade their crypto algorithms.
▪ As of August 2016, using hardware tokens requires
deploying on-premises components.
Learn more: Getting started with the Azure Multi-Factor Authentication Server
Call to Phone / Text Message to Phone
Users receive a phone call or acknowledge a text message to complete authentication.
▪ Low friction onboarding of users. The vast majority of users ▪ Phone and SMS systems have limitations, such as phone
have a mobile phone for receiving calls and text messages. reception and signal strength, the handling of tone dials by
▪ Turnkey authentication experience. Users can quickly the local PBX and phone network, interference on the line,
acknowledge the phone call or text message. background noise on the call, and more.
▪ Users are less likely to forget a phone and will take better ▪ Mobile phones are dependent on battery level, reception
care of it. Since mobile phones often contain personal level, etc.
information, users often take measures very quickly (report ▪ If the company does not provide a phone, then users need
to authorities, remote wipe, etc.) when they lose them. to disclose their personal phone number to the employer.
▪ Depending on the authentication method used, end-users
may incur costs when using their device (data, phone call,
SMS).
▪ Relies on the phone’s network infrastructure, which was
not designed for security. Thus, it is vulnerable to man-in-
the middle, fraud, phishing attacks, SIM cloning, etc.
Learn more: NIST Special Publication 800-63B

Windows Hello
Windows Hello provides a secure way to authenticate to Windows 10 devices with biometric gestures or a
PIN. When Windows 10 devices are deployed with Azure AD Join, Azure AD can accept Windows Hello
logins as a second factor.
▪ A login with Windows Hello can be both secure and ▪ Only works on Windows 10 devices.
turnkey for end-user authentication: By signing into the ▪ Challenging to provision a large number of users onto
device, users can seamlessly and securely access Azure AD- shared devices.
protected resources.
Learn more: What is Windows Hello?, Extending cloud capabilities to Windows 10 devices through Azure
Active Directory Join
Third-Party MFA solutions
If your enterprise has already invested in a third-party solution for MFA (e.g., RSA SecurID, Vasco, etc.), it is
possible to integrate it with Azure AD on federated domains.
▪ Preserves existing investments ▪ Requires on-premises infrastructure (an identity provider
such as AD FS, and the MFA provider)
Learn more: Configure Additional Authentication Methods for AD FS, Set-MsolDomainFederationSettings
Enroll users to MFA

Users will need to enroll to select their preferred MFA method and supply the appropriate data (e.g.,
phone number to receive phone calls). Some considerations:
▪ We recommend a communications campaign to educate users on how to enroll at

https://aka.ms/mfasetup and sign in.
▪ We recommend that users enroll in multifactor authentication as soon as possible. If a user’s password
is compromised and the user did not register for MFA, a bad actor can use their credentials to register
his or her own phone number and get access to the account.
▪ You can use Windows PowerShell to enable Cloud MFA for users.
Learn more: Automate turning on multi-factor authentication using PowerShell
▪ Azure MFA can reuse an office phone number as “pre-filled” information. However, users must go
through the process to complete their enrollment fully.
▪ Azure AD Identity Protection provides Cloud MFA registration as a policy, which can be scoped,
enabled, and tracked within the Azure management portal.
Learn more: multi-factor authentication registration policy
▪ MFA Server enables advanced customizations of the enrollment process on-premises:

− Programmatic enrollment with Web Services SDK.

− Deployment of an enrollment portal in IIS (you can decide to enable access to this portal from the
internal network only).
− Import enrollment data from flat file, or Active Directory.
Deploying Conditional Access Policies

This section describes the different criteria you can use to design access policies.
User-Based Access Policy

This is a broad policy that you can apply to users in the directory, who will be prompted for MFA when
signing into any application, unless you let them bypass MFA when authenticating from the internal
network. This policy applies to all applications the user attempts to access.
▪ Simple to deploy. ▪ Lack of flexibility, since it applies to all applications.
▪ Simple to communicate to users. ▪ High friction for end-users.
▪ Consistent behavior across all applications.
Recommendation
▪ Use this option if the long term security posture is: “All users must do MFA when outside the corporate
network.” While this is a good place to start, most customers refine this posture over time to strike a
balance between security and usability for end users.
▪ Consider using this policy to enforce MFA for high privileged accounts such as global administrators.
(You can find more information on privileged accounts in the section Assigning Administrative Roles
below.)
Location-Based Access Policy

Whether the request to authenticate comes from the internal network or an external network determines
how this policy applies to applications. Azure AD can determine what constitutes the “internal network” in
one of the following ways:
▪ An on-premises identity provider (such as AD FS) provides a claim that indicates the network location.
This is the recommended approach for federated customers.
Learn more: Trusted IPs for federated users
▪ Azure AD receives the list of IP addresses that constitute the internal network. This is the only option
when using password hash sync or cloud-only identities.
To capture the location effectively, it is important to understand the retail store’s network infrastructure. A
store network may be part of the corporate network, or it may be connected via a VPN link enabled by

third-party internet access (either a public ISP or a “store within a store”). This will determine which of the
above options you must use, or if a combination is required.
Authentication Experience
Location-based access policies for applications can be configured to deliver one of the following
authentication experiences:
▪ Require MFA always. Always require the user to perform MFA when accessing this application,
regardless of their access location
▪ Require MFA when not at work. If the user is accessing the application from a network location that
is outside your internal network (as defined above), require MFA before allowing access
▪ Block access when not at work. Do not allow access to the application from a network location that is
outside your internal network.
▪ Easy to deploy. ▪ For large customers, it is challenging to assess and
▪ Easy to communicate to customers. maintain the list of internal IP Addresses, especially when
▪ Granularity makes it possible to enable this policy for a the network and directory are managed separately.
subset of applications. ▪ The authentication experience for users such as field
representatives and store associates, who sign in on a
regular basis from outside the corporate network, will have
friction.
▪ Configuration required when onboarding each application.
Recommendation
▪ Use this policy if you have identified low-impact applications that don’t require multifactor
authentication (e.g., bulletin board)
▪ Use this policy to lock down access to applications that you do not expect to be used outside the
corporate network. (e.g., clock in/out applications)
Device-Based Access Policy

You can apply this policy to applications based on whether the request to authenticate is coming from a
compliant or a non-compliant device. The criteria to determine compliance is configurable through
Microsoft Intune.
NOTE: While Microsoft Intune is required to enable device compliance policies for iOS and Android devices, Windows 10
devices can be integrated with third-party MDM solutions such as MobileIron and Airwatch.
Learn more: Device Based Conditional Access
Device-based access policies for applications can be configured to deliver one of the following
authentication experiences:

▪ All devices must be compliant. Require that all device types need to be compliant in order to access
the application
▪ Only selected platforms must be compliant. Restrict compliance requirement for the application to
specific device types.
▪ Enforcing device health provides much better protection ▪ Enrolling personal devices for some compliance criteria
against malware, device loss, minimum mobile OS version such as complex pins or potential remote wipe creates
accepted, etc. friction. To mitigate this, Microsoft Intune provides per-
application policies without requiring MDM enrollment.
Learn more: Protect app data using MAM policies
▪ Managing the Intune infrastructure requires additional IT
resources.
Recommendation
▪ If your organization has acquired Windows Intune, then we highly recommend incorporating device
health into your security strategy through MAM, MDM, or a combination.
▪ Using device state allows retail customers to create policies that enable access to a subset of well-
known devices in locations with restricted physical access, such as warehouses or behind the counter.
Learn more: Windows Intune device compliance policies
Risk-Based Access Policies

Azure AD Identity Protection processes vast amounts of data across multiple data sources and assigns a
level of risk to sign-in activity and users. You can use this information to create access policies that define
a risk threshold and a mitigation action. Examples of risk events include the following:
▪ Sign-ins from unfamiliar locations.

▪ Sign-ins from anonymous IPs.
▪ Leaked user credentials.
Examples of mitigations that can be part of a risk policy include the following:
▪ Require MFA.
▪ Require password reset.
▪ Block login.
▪ Users will attempt to sign-in. If a risk-based policy is triggered, then the users will be presented with a
message indicating abnormal behavior.
▪ Depending on sign-in risk policy configuration, a sign-in attempt can be blocked, or the user may be
prompted to perform MFA.
▪ Depending on the user risk policy configuration, a user can be blocked from signing in, or required to
reset her password.

▪ Users will only be prompted to do MFA if the sign-in is ▪ Users might not fully understand why they see different
deemed risky, which balances security and the user behavior, which might result in support incidents.
experience. Ideally, legitimate users will never see these ▪ Some models might result in false positives (e.g., familiar
prompts, while bad actors will be prevented from signing locations or impossible travel). Identifying and correcting
in. false positives might require multiple iterations.
Recommendations
▪ Good option for customers who are user experience focused and require minimal MFA prompts.
Learn more: User Risk Security Policy, Sing-in Risk Security Policy
Deployment considerations
▪ All the access policies described above can be scoped to a subset of users. We recommend rolling out
policies to a set of pilot users first so you can verify that user experience and security goals are met.
This is especially important when deploying multiple policies that can act simultaneously.
▪ Azure AD Identity Protection provides a view to quantify the estimated impact of rolling out risk
policies or MFA policies. Use this data to inform your rollout strategy and plan accordingly.
▪ We recommend educating users on what conditional access policies mean for them in terms of user
experience. Consider a communications campaign as part of your rollout process.
▪ You can follow the order described above to transition from a simple policy to a richer one over time.
Here’s an example of a typical journey to deploy access policies:
− Enable MFA to administrators only.
− Define MFA for all users when accessing resources from outside the corporate network.
− Define MFA only for high impact applications accessed from outside the corporate network.
− Incorporate mobile device state to streamline sign-in for users with compliant devices
− Incorporate policies to require MFA only in response to risky events.
Assigning Administrative Roles

It is crucial to have a solid role-based access control that provides Just Enough Access and Just-in-Time
Access to privileged operations. Azure AD provides capabilities for implementing an enterprise-wide
administrative roles infrastructure.
Enable Just Enough Access

Each organization has different processes and a different staff breakdown, which determine the actors
who will perform Azure AD management tasks. For this reason, we recommend looking at the definitions
of the different Azure AD Administration Roles and mapping them to your IT structure.

Azure AD Administrative Units allow you to create subsets of users for roles specific to user management,
such as User Administrator or Helpdesk Administrator. Large organizations with regional helpdesk teams
can use this approach to further limit the privileges of Helpdesk operators.
NOTE: Azure AD will evolve roles over time. We recommend that you check the Enterprise Mobility and Security blog
on a regular basis to evaluate about new product capabilities and refine your roles accordingly. If you use Azure AD
Administrative Units to scope roles, executing operations available to each role requires using PowerShell.
The table below is an example of mapping roles for a typical enterprise:
Target Customer Control Functions Azure AD Role(s) Role Scope (Azure AD

Role Administrative Units)
Administrator Has full access to everything—aka, “the Global Administrator
keys to the kingdom.” Rarely used. Privileged Role
Administrator
ID Admin Has access to administer identities in the User Administrator Helpdesk teams in:
directory for troubleshooting, but cannot ▪ North America
modify privileged accounts. ▪ Europe
No access to SaaS Gallery. ▪ Asia
Helpdesk teams Provide password reset/change Helpdesk Administrator Helpdesk teams in:
assistance to customers. ▪ North America
▪ Europe
▪ Asia
Collaboration People in this role can fully administer SharePoint Service
Administrator their own service, but cannot touch any Administrator
element of each other’s service, nor can
they touch Azure AD. The “service” can (...)
be any Microsoft online service such as
Exchange Online, Intune, SharePoint, etc.
No access to modify identities is possible,
with the exception of some level of
access to modify service-specific identity
attributes.
Security Auditor Read-only access to everything, including Security Reader

audit logs.
Info Sec Fine Tune Azure AD Information Security Administrator
protection policies
Investigate risk events
Remediate user risk events
Directory Operations Looks after the hybrid infrastructure ADFS / Azure AD

Connect: On-premises
based assignment
Azure AD Connect Health:
Contributor
Enable Just in Time Access for Privileged Accounts

Just in time (JIT) Access allows administrators to elevate their privileges only when required to complete a
management task. A JIT strategy involves the following:

▪ Elevate privileges on demand.

▪ Provide privileged access only for a period of time.
▪ Track privileged access usage for monitoring and reporting.
Azure AD Privileged Identity Management provides JIT for Azure AD administration roles described above
this section, and Privileged Access Management (PAM) provides JIT to the on-premises Active Directory
infrastructure.
Recommendations for Privileged Accounts

Using federated privileged accounts has the following advantages:
▪ Federated accounts can be further secured with on-premises tools such as smart card
authentication, fine-grained access policy, etc.
Existing on-premises management account models extend nicely to Azure AD roles without
additional overhead for administrators (e.g., it is very reasonable that an on-premises domain
administrator holds one or more Azure AD administrative roles).
We recommend having at least two cloud accounts with privileged roles (Global Admin and Security
Admin) to handle emergency cases when federated accounts cannot gain access (for example, federation
itself is not working).
▪ It is only necessary for one employee to know the password of a privileged cloud account.
Corporate guidelines regarding password management (strength, generation, rotation, etc.) can
be applied here.
▪ We recommend you enable self-service password reset for privileged cloud accounts as a
precaution.
▪ Consider this fallback account to be as sensitive as an on-premises Enterprise Administrator
credential.
A defense in depth measure on of top of JEA and JIT access is to separate privileged accounts from the
accounts administrators use for their day-to-day work (e.g., email, documents, etc.). This way, if the
administrator’s standard account gets compromised (e.g., by clicking a link on a phishing email), the
privileged role is not compromised. Following this recommendation for dedicated on-premises
management accounts allows for stronger access patterns when using AD FS. To be more specific, adding
privileged accounts to on-premises security groups makes it possible for AD FS to do the following:
▪ Allow management from privileged workstations only based on the requestor’s specific IP
address, OS version, device state (requires write-back) or other additional criteria.
▪ Allow management from the intranet only so access will be allowed only when the request
comes from the internal network.
Learn More:
▪ Azure AD Privileged Identity Management

▪ Privileged Access Workstations
▪ Protecting high-value assets with secure admin workstations

▪ Administrative units management in Azure Active Directory

▪ Securing Privileged Access
Using Security Reports

You can use Azure Active Directory's reports to gain visibility into the integrity and security of your
organization’s directory so you identify possible security risks and plan mitigations:
▪ Azure AD Identity Protection helps prevent the use of compromised accounts using industry leading
machine learning (ML) that processes login signals from multiple sources such as Office 365, Xbox Live,
Azure services, Outlook.com, etc. This login data is then combined with feeds from Microsoft’s Digital
Crimes Unit, Security Response Center, phishing attack data from Outlook.com, law enforcement,
academia, security researchers and partners to provide real-time detection of risky events and
vulnerabilities.
▪ Azure AD reporting APIs allow programmatic access that can facilitate integration with SIEM tools for
archiving/auditing and forensics.
▪ Azure AD Connect Health provides reports that can be used to investigate potential security
incidents and configuration vulnerabilities based on on-premises federated login activity.
▪ Advanced Threat Analytics provides additional visibility into potential vulnerabilities in on-premises
Active Directory.
User login anomalies

Your security team must review the anomalous activity reports in order to identify and address any
findings. Some patterns are not only reported, but are also flagged as risk events by Azure AD Identity
Protection, which enables automated remediation actions as described in the section “Risk-Based Access
Policies” above.
The table below provides a summary of the scenarios that have available pre-defined reports:
Scenario Azure AD Identity Security Report Anomaly/Risk Description

Protection Risk Event Available?
Sign-ins from unknown Sign-ins from Yes May indicate an attempt to sign-in without
sources anonymous IP addresses being traced. An example of this using TOR
networks.
Users with leaked Leaked credentials Yes Indicates users whose passwords may have
credentials been compromised.
Sign-ins from IP addresses Sign-ins from IP Yes May indicate a successful sign-in after a
with suspicious activity addresses with sustained intrusion attempt.
suspicious activity
Sign-ins from possibly Sign-ins from infected Yes May indicate an attempt to sign-in from a
infected devices devices possibly infected device. The list of risky
devices is determined via the cloud machine
learning models described above.

Scenario Azure AD Identity Security Report Anomaly/Risk Description

Protection Risk Event Available?
Irregular sign-in activity Impossible travel to Yes Also known as “impossible travel,” this
atypical locations identifies events anomalous to users’ sign-in
patterns.
Users with anomalous sign- Yes Indicates users whose accounts may have
in activity been compromised.
Sign-ins from unfamiliar Sign-ins from unfamiliar No
locations locations
Users with threatened Yes
credentials
Bad password attempts Yes. (Azure AD May indicate attempts at brute force attacks.
with AD FS Connect Health This report encompasses applications that
for AD FS) trust AD FS as well as Azure AD.
It is also common to see applications using
service accounts with expired passwords, as
well as infrequently used devices that lack
current password information.
NTLM authentications in Yes. (Azure AD NTLM is an older protocol that is not as
domain controllers Connect health secure as Kerberos, making it a risk to your
for AD DS) organization.
Environment Vulnerabilities
Azure AD Identity Protection provides a report of vulnerabilities in the environment. We recommend

addressing all vulnerabilities reported. The vulnerabilities reported are as follows:
▪ MFA registration is not configured: Reported when users who have not configured MFA are
detected. MFA login is a valuable tool for mitigating authentication attack vectors.
▪ Unmanaged cloud apps: Reported when Azure AD Cloud App Discovery detects unsanctioned SaaS
applications.
Learn more: Finding unmanaged cloud applications with Cloud App Discovery.
▪ Security alerts from PIM: Generated when there are issues with privileged identities (e.g., too many
global administrators).
Learn more: How to configure security alerts in Azure AD Privileged Identity Management
Monitoring On-Premises Active Directory with Advanced Threat Analytics (ATA)
ATA is an on-premises platform included in Azure AD Premium and EMS to help you protect your
enterprise from advanced targeted attacks by automatically analyzing, learning, and identifying normal
and abnormal entities (user, devices, and resources). This includes the following:
▪ Malicious attacks: ATA detects known malicious attacks such as Pass-the-Hash (PtH) and Pass-the-
ticket almost as instantly as they occur:

▪ Abnormal behavior: Behavioral analytics leverage Machine Learning to uncover questionable

activities and abnormal behavior such as anomalous logins, unknown threats, password sharing and
lateral movement.
▪ Security issues and risks: ATA identifies known security issues using world-class security researchers’
work. Examples include broken trust, weak protocols, and known protocol vulnerabilities.
Reporting API
Azure AD provides a reporting API that allows you to build custom security reports based on business
needs. Examples include the following:
▪ Sign-in activity history for all users or for a single-user.

▪ List of users who have access to applications.
▪ Audit trail of operations in the directory.
The report API facilitates integration with SIEM tools.
Recommendations
▪ Set up the Azure AD Identity Protection weekly email digest to be sent to your security team.
▪ Designate owner(s) who periodically remediate risk events so you can keep your assessment of the
user risk and policies current.
▪ Maintain your list of IP address to improve the effectiveness of location-based risk events, reports, and
vulnerabilities.
▪ Enable the MFA registration policy so users sign up as soon as possible. This way, you can safely
configure policies to remediate risk with high confidence that the second factor will be available when
most needed.
▪ Deploy Azure AD Connect Health and assign owners to review reports for bad passwords and NTLM
usage, as well as future reports.
▪ Deploy Advanced Threat Analytics and assign owners to review and address the findings on a regular
basis.
▪ Export Azure AD reports to any SIEM tools deployed in your organization.
Learn more:
▪ View your access and usage reports

▪ Azure Active Directory Identity Protection
▪ Vulnerabilities detected by Azure Active Directory Identity Protection
▪ Advanced Threat Analytics
▪ Getting started with the Azure AD Reporting API

Security with Windows 10

Azure AD provides additional capabilities built into Windows 10 devices that allow a more seamless and
secure experience:
▪ Azure AD Join. This feature enables single sign on to Azure AD resources such as SaaS applications,
Office 365 and LOB applications, access to Windows Store with Azure AD credentials, enterprise
roaming settings, and other capabilities. Additionally, a device can be joined to Azure AD and on-
premises Windows Server AD, providing a seamless experience across both cloud and on-premises
resources.
▪ Shared Devices Improvements. Azure AD Join reduces the time it takes to sign-in to a device the first
time from the minutes it takes with traditional on-premises AD join to seconds. This allows turnkey
provisioning of users in shared devices such as kiosks, warehouses, and points of sale.
▪ Windows Hello for Work. This provides enterprise-wide infrastructure to recognize a device user via
different biometric gestures, authenticating using industry standards such as FIDO.
▪ Add Azure AD account for BYOD. Users can add an Azure AD account to personally owned devices
to access work applications. This enables single sign on and MDM enrollment.
Learn more:
▪ Connect domain-joined devices to Azure AD for Windows 10 experiences

▪ Windows Hello for Work guide
▪ Azure AD on Windows 10 Personal Devices
▪ Making Windows 10 More Personal and More Secure with Windows Hello

Additional EMS Security

Components
Enterprise Mobility + Security provides additional components to secure your enterprise:
▪ Microsoft Cloud App Security provides visibility and controls for cloud applications, including
popular SaaS apps like Box, Salesforce, ServiceNow, and Office 365.
Learn more: Cloud App Security, Gain enhanced visibility and control with Office 365 Advanced
Security.
▪ Microsoft Azure Rights Management (Azure RMS) helps you protect your organization’s sensitive
information from unauthorized access and control how this information is used.
Learn more: What is Azure Rights Management?
▪ Azure Information Protection combines classification and labeling with persistent data protection to
enable secure file sharing, internally and externally.
Learn more: Azure Information Protection
▪ Intune Mobile Application Management (MAM) helps you prevent data loss on mobile devices,
with the unique ability to manage the Office mobile apps without requiring device enrollment.
Learn more: Protect app data using MAM policies

Conclusion
Azure AD Premium and EMS provide a comprehensive set of capabilities that enable your retail
organization to have a robust security posture for cloud and on-premises resources. As a cloud service,
Azure AD is constantly adding more capabilities and refined models/heuristics that will further strengthen
your security posture. Check the Enterprise Mobility and Security blog periodically to learn about new
product capabilities.

Reference
For more information about Azure Active Directory, see https://azure.microsoft.com/en-
gb/services/active-directory/
To stay informed on new capabilities, visit the Enterprise Mobility and Security blog.

03 - Azure Active Directory Retail Deployment Guide - Security

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03 - Azure Active Directory Retail Deployment Guide - Security

Hochgeladen von

Copyright:

Verfügbare Formate

Securing Your Identities with Azure

MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN

Microsoft Azure Active Directory Deployment Guide Page ii

Key Concepts ............................................................................................................................ 5

Build Your Identity Organization Teams .................................................................................... 7

Security Deployment Guidelines ................................................................................................ 9

Security with Windows 10 ........................................................................................................ 21

Additional EMS Security Components ...................................................................................... 22

Microsoft Azure Active Directory Deployment Guide Page 3

When used to secure identities, Azure AD Premium solves common challenges:

▪ Multi-factor Authentication provides additional factors of authentication beyond passwords.

Microsoft Azure Active Directory Deployment Guide Page 4

▪ Something you know (typically a password)

Learn More: Azure Multi-Factor Authentication – What is It?

Device Registration / Authentication

Learn More: Azure Active Directory Device Registration overview

Learn More: Azure AD Privileged Identity Management

Learn More: Azure AD Privileged Identity Management

Just-In-Time Access (JIT)

Learn More: Azure AD Privileged Identity Management

Microsoft Azure Active Directory Deployment Guide Page 5

Learn More: Azure Active Directory conditional access

Learn More: Azure Active Directory Identity Protection

Microsoft Azure Active Directory Deployment Guide Page 6

Build Your Identity Organization

Microsoft Azure Active Directory Deployment Guide Page 7

Process for configuring prerequisites

Microsoft Azure Active Directory Deployment Guide Page 8

Security Deployment Guidelines

Deploying Multi-Factor Authentication

Assess resources to be protected

Learn more: Azure Multi-Factor Authentication – Getting Started

Defining Multi-Factor Authentication Methods

Software Tokens / Authenticator app

Microsoft Azure Active Directory Deployment Guide Page 9

Call to Phone / Text Message to Phone

Users receive a phone call or acknowledge a text message to complete authentication.

Learn more: NIST Special Publication 800-63B

Microsoft Azure Active Directory Deployment Guide Page 10

Third-Party MFA solutions

Learn more: Configure Additional Authentication Methods for AD FS, Set-MsolDomainFederationSettings

Enroll users to MFA

▪ We recommend a communications campaign to educate users on how to enroll at

Learn more: Automate turning on multi-factor authentication using PowerShell

Learn more: multi-factor authentication registration policy

▪ MFA Server enables advanced customizations of the enrollment process on-premises:

Microsoft Azure Active Directory Deployment Guide Page 11

− Programmatic enrollment with Web Services SDK.

Deploying Conditional Access Policies

User-Based Access Policy

Location-Based Access Policy

Learn more: Trusted IPs for federated users

Microsoft Azure Active Directory Deployment Guide Page 12

Device-Based Access Policy

Learn more: Device Based Conditional Access

Microsoft Azure Active Directory Deployment Guide Page 13

Learn more: Windows Intune device compliance policies

Risk-Based Access Policies

▪ Sign-ins from unfamiliar locations.

Microsoft Azure Active Directory Deployment Guide Page 14

Assigning Administrative Roles

Enable Just Enough Access

Microsoft Azure Active Directory Deployment Guide Page 15

The table below is an example of mapping roles for a typical enterprise: