MCT USE ONLY.

STUDENT USE PROHIBITED

Microsoft
Official
Course

MS-100T03
Microsoft 365 Identity
Management
 MCT USE ONLY. STUDENT USE PROHIBITED
MS-100T03
Microsoft 365 Identity
Management
MCT USE ONLY. STUDENT USE PROHIBITED
 MCT USE ONLY. STUDENT USE PROHIBITED
Contents

■■ Module 0 Course Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1

Welcome  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1
■■ Module 1 Managing User Security Groups and Licenses  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
User Accounts and Licenses in Microsoft 365  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
Admin Roles and Security Groups in Microsoft 365  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
Password Management in Microsoft 365  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
Non-Graded Practice Lab 1  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
■■ Module 2 Planning and Implementing Identity Synchronization  . . . . . . . . . . . . . . . . . . . . . . . . .  29
Introduction to Identity Synchronization  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
Planning for Azure AD Connect  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
Implementing Azure AD Connect  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  39
Managing Synchronized Identities  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  41
Non-Graded Practice Lab 2  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  45
■■ Module 3 Planning and Implementing Federated Identities  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  47
Introduction to Federated Identities  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  47
Planning an AD FS Deployment  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  55
Implementing AD FS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  57
■■ Module 4 Implementing Application and External Access  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  63
Implementing Applications in Azure AD  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  63
Configuring Azure AD Application Proxy  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  70
Designing Solutions for External Access  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  74
 MCT USE ONLY. STUDENT USE PROHIBITED
Module 0 Course Introduction

Welcome
Welcome to Microsoft 365 Identity Management

Welcome to Microsoft 365 Identity Management In this course, you will learn Learn how to manage
user security groups and licenses for cloud identities, and how to plan and implement identity synchroni-
zation, federated identities, applications, and external access. The course material is supported by a series
of hands-on lab exercises that allow you to gain invaluable experience configuring and managing your
identity environment and performing identity synchronization
By actively participating in this course, you will learn how to:
●● Manage user accounts and licenses in Microsoft 365
●● Manage admin roles and security groups in Microsoft 365
MCT USE ONLY. STUDENT USE PROHIBITED 2  Module 0 Course Introduction

●● Plan and implement password management

●● Manage Microsoft 365 authentication and provisioning options
●● Plan for directory synchronization
●● Plan and implement Azure AD Connect
●● Manage synchronized identities
●● Plan and implement an ADFS deployment
●● Implement applications in Azure AD
●● Configure Azure AD Application Proxy
●● Design solutions for external access
●● Manage Microsoft 365 tenant health and services

Video: Course Introduction

 MCT USE ONLY. STUDENT USE PROHIBITED
Module 1 Managing User Security Groups and
Licenses

User Accounts and Licenses in Microsoft 365

Lesson Introduction
As the Enterprise Administrator of your organization’s Microsoft 365 environment, you will be responsible
for creating and managing user accounts for all your users.
In this lesson, you will learn about various administrative tasks for maintaining user accounts, including
creating and managing user objects, assigning Office 365 licenses to your users, and recovering deleted
user accounts.
After this lesson, you will be able to:
●● Describe the user identities in Microsoft 365.
●● Create user accounts from both the Microsoft 365 admin center and in Windows PowerShell.
●● Manage user accounts and licenses.
●● Recover deleted user accounts.

Overview of User Identities

MCT USE ONLY. STUDENT USE PROHIBITED 4  Module 1 Managing User Security Groups and Licenses

Creating User Accounts

Managing User Accounts

Managing user accounts involves managing several account settings, such as assigning administrator
roles, setting users’ sign-in status, specifying user location settings, and assigning licenses, regardless of
the method that you use to provision user accounts. You can manage these user settings by using the Mi-
crosoft 365 admin center or Windows PowerShell cmdlets.
You can use the Microsoft 365 admin center to edit single or multiple users.
To edit a user account, you should perform the following steps:
1. On the Microsoft 365 admin center Home page, click Users, and then click Active Users.
2. Click the user account that you want to edit to open the User Properties page.
3. In the User name/Email Aliases section, you can modify the user name and add or modify email
addresses.
4. In the Product licenses section, you can modify the license assigned to the user. You can also set the
user location. Microsoft needs to know the location of each user who utilizes its Microsoft 365 services
so that it only offers permitted services to that user.
5. In the Group memberships section, you can modify group membership for the user.
6. In the Sign-in status section, you can specify the sign-in status of the selected users. You can set this
to Sign-in allowed or Sign-in blocked. If you set it to Sign-in blocked, the user cannot sign in to
Microsoft 365. The user is not immediately prevented from accessing services, but they will be
blocked at the next sign-in attempt. Typical reasons for blocking a user include the user being a
contract worker, or they have left the organization but you want to retain their email information.
7. In the Office installs section, you can view installations and deactivate Office apps for specific devices.
8. In the Roles section, you can specify whether the selected users should have Administrator permis-
sions. The last lesson in this module discusses the different administrator roles.
9. In the Display name/Office phone section, you can edit contact information for the user.
10. In the Mail Settings section, you can modify mailbox permissions, email forwarding, automatic
replies, and email apps.
11. In the OneDrive Settings section, you can obtain access to the user’s files, view the storage quota,
and force a sign-out from all Microsoft 365 sessions.
 MCT USE ONLY. STUDENT USE PROHIBITED
User Accounts and Licenses in Microsoft 365  5

Managing User Licenses

One of the most basic tasks for Microsoft 365 Enterprise Administrators is user management, and to
manage users you need to understand how to manage their licenses. Your organization’s users need
licenses to use Microsoft 365 services such as Microsoft Outlook, Microsoft SharePoint Online, and
Microsoft Skype for Business Online. When you assign a license to a user, the service is automatically set
up for that user. For example, when you assign a license for SharePoint Online, the user is assigned edit
permissions on the default team site.
Only members of the Microsoft 365 Global admin and User Management admin roles can assign or
remove licenses. You can assign or remove a license for single or multiple users.
Important: When you remove a license from one of your users, any service data that is associated with
that user is deleted. You then have a 30-day grace period in which you can recover that data, but after
the grace period, the data is not recoverable.

Assigning a License
To assign a license, you can use the Microsoft 365 admin center or Windows PowerShell. To assign or
remove licenses for multiple users in the Microsoft 365 admin center, you should perform the following
steps:
1. On the Microsoft 365 admin center Home page, click Users, and then click Active Users.
2. Select the users that you want to assign or remove licenses, and in the More list, click Edit product
licenses.
3. On the Product Licenses page, you can change the user location, specify whether to replace or add
to existing licenses, and then select the services that you want to modify.
4. If you prefer to use Windows PowerShell, the Set-MsolUserLicense cmdlet enables you to add user
licenses, remove user licenses, and update licensing options. To add a license to a user, at the com-
mand prompt, type the following command, and then press Enter:
5. Set-MsolUserLicense -UserPrincipalName username@domainname –AddLicenses “license”
6. For example, to add an Enterprise Premium license for Stella Carrillo at Adatum Corp., you would run
the following command:

‎
7. If you prefer to use Windows PowerShell, the Set-MsolUserLicense cmdlet enables you to add user
licenses, remove user licenses, and update licensing options. To add a license to a user, at the com-
mand prompt, type the following command, and then press Enter:
8. Set-MsolUserLicense –UserPrincipalName [email protected] –AddLicenses “Ada-
tum:ENTERPRISEPREMIUM”

View License Information

You can use the Microsoft 365 admin center to view important information about your users’ license
usage, such as how many licenses you have used, how many are remaining, and which users are currently
unlicensed.
To view the number of licenses remaining:
1. In the Microsoft 365 admin center, on the left navigation pane, on the Billing menu, click Licenses.
MCT USE ONLY. STUDENT USE PROHIBITED 6  Module 1 Managing User Security Groups and Licenses

2. Note how many licenses are valid and how many licenses have been assigned.

To view any unlicensed users:

1. On the Microsoft 365 admin center Home page, click Users.
2. Click the Views drop-down list.
3. In the drop-down list box, click Unlicensed users.

Using Windows PowerShell, you can use the Get-MsolAccountSku cmdlet to view the current licensing
information for your Microsoft 365 tenant, which includes the number of licenses that are currently
available and how many are in use. You can use the Get-MsolUser cmdlet with the -UnlicensedUsersOn-
ly switch to view a list of users who currently do not have a license.

Recovering Deleted User Accounts

When users leave your organization, they no longer require a user account in Microsoft 365. You must
delete their user accounts to ensure that they can no longer access Microsoft 365. When you delete a
user account, the assigned Microsoft 365 license for that user becomes available, which you can assign to
another user.
To delete one or more users:
1. In the Microsoft 365 admin center Home page, click Users, and then click Active Users.
2. Select the users that you want to delete, click the More drop-down list, and then click Delete users.
3. In the message box, click Yes to delete the selected users.
4. When they have successfully deleted, click Close.
 MCT USE ONLY. STUDENT USE PROHIBITED
User Accounts and Licenses in Microsoft 365  7

You can also use Windows PowerShell to delete user accounts by using the Remove-MsolUser command
with the –ObjectId Guid or the –UserPrincipalName string parameters.
When you delete a user account, the account becomes inactive and the user cannot sign in to access
Microsoft 365 services. However, you might need to restore a user’s account after deletion. Microsoft 365
retains the account as a soft deleted inactive account for 30 days after deletion; this enables you to
restore the account.
To restore a user:
1. In the Microsoft 365 admin center, on the Users menu, click Deleted users.
2. Select the user that you want to restore and then click Restore.
3. Select how you want to assign the user password and then click Restore.
You can also use Windows PowerShell to restore deleted user accounts by using the Restore-MsolUser
cmdlet.

Review Activity - User Accounts and Licenses

Let's play a quick game to test your knowledge of user accounts and licenses in Microsoft 365. Click on
the button below to open this review activity full screen.
LAUNCH ACTIVITY1

1 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M01_L01_cw_AcctsLicensestu-
torial.html
MCT USE ONLY. STUDENT USE PROHIBITED 8  Module 1 Managing User Security Groups and Licenses

Admin Roles and Security Groups in Microsoft

365
Lesson Introduction
After you create your users for the Microsoft 365 tenant, you can optionally create groups for distributing
email to multiple users with Exchange Online. You can also use admin roles in Microsoft 365 to enable
some users to act as administrators.
For example, because not all admin roles and security groups tie into SharePoint Online, individuals can
be selected to act as administrators and configure custom settings to manage SharePoint Online. These
administrators can configure security permissions with SharePoint Online so that users can collaborate
and share documents with each other. They configure permissions by assigning rights and access to
SharePoint sites and documents according to their organization’s security policies.
In this lesson, you will learn what group types are available in Microsoft 365 and how to create and
manage groups.
After this lesson, you will be able to:
●● Understand and use Microsoft 365 admin roles.
●● Describe the various types of group available in Microsoft 365.
●● Create and manage groups from Microsoft 365 admin center and using Windows PowerShell.

Using Admin Roles In Microsoft 365

In Microsoft 365 you use administrator roles to assign specific administrative functions to users. Each
admin role maps to common business functions and gives people in your organization permissions to do
specific tasks in the Microsoft 365 admin center. You can manage admin roles in Microsoft 365 using the
Microsoft 365 admin center or Windows PowerShell.
The following table describes all the admin roles that are available in the Microsoft 365 admin center and
provides scenarios as to when these roles should be assigned to users.

Admin role Description When to use

Global administrator This role is the ultimate adminis- It is recommended to only have
trator and includes access to all a limited number of global
administrative features in administrators to reduce the risk
Microsoft 365. It is also the only to your business.
admin role who can assign other
By default, the person who signs
admin roles.
up to buy Microsoft 365 be-
comes a global admin.
You should consider enabling
Multi-factor authentication
(MFA) for improved login
security.
Billing administrator Makes purchases, manages Ideal for users of your purchas-
subscriptions, manages support ing department that manage
tickets, and monitors service Microsoft 365 licenses.
health.
 MCT USE ONLY. STUDENT USE PROHIBITED
Admin Roles and Security Groups in Microsoft 365  9

Dynamics 365 service adminis- This role can manage instances Used if you need to configure
trator in the Dynamics 365 admin and manage Dynamics 365.
center and is able to assign users
to manage Dynamics 365 at the
tenant level.
Exchange administrator Manages mailboxes and an- Used if you need to manage
ti-spam policies for your busi- mailbox related settings and
ness, using the Exchange admin attributes such as mailbox size or
center. Can view all the activity mail flow connectors.
reports in the Microsoft 365
admin center.
Password administrator Resets passwords, manages For administrators that need to
service requests, and monitors reset passwords or manage
service health. Password admins service requests.
are limited to resetting pass-
words for users.
Skype for Business administra- Configures Skype for Business For administrators that need to
tor for your organization and can manage Skype for Business.
view all the activity reports in the
Microsoft 365 admin center.
Power BI administrator The Power BI admin role will For administrators that want to
have access to Microsoft 365 manage Power BI.
Power BI usage metrics. They'll
also be able to control your
organization's usage of Power BI
features.
Service administrator Can open support requests with This role is ideal for your first or
Microsoft and views the service second level support staff that
dashboard and message center. manages Microsoft 365 prob-
lems and incidents.
They have “view only” permis-
sions except for opening support
tickets and reading them.
SharePoint administrator Manages the document storage For administrators that need to
for your business on SharePoint manage SharePoint Online.
Online. They do this in the
SharePoint admin center. They
can also assign other people to
be Site Collection administrators
and Term Store administrators.
People in this role can also view
all the activity reports in the
Microsoft 365 admin center.
MCT USE ONLY. STUDENT USE PROHIBITED 10  Module 1 Managing User Security Groups and Licenses

User management administra- Resets passwords, monitors Good for your user helpdesk that
tor service health, adds and deletes manage user related issues.
user accounts, and manages
service requests. The user
management admin can’t delete
a global admin, create other
admin roles, or reset passwords
for global, billing, Exchange,
SharePoint, Compliance, and
Skype for Business admins.
Additional admin roles such as Compliance Administrator and Company Administrator are available but
are managed using either the Security & Compliance admin center or Windows PowerShell. A list of all
available admin roles is available by running the Get-MsolRole cmdlet in Windows PowerShell.
All admin roles are not mutually exclusive, but they can be combined. You can assign one or more admin
roles to a user, such as the Exchange admin, SharePoint admin, and User Management administrator
roles.

Assign admin roles in Microsoft 365

Admin roles are based on groups held in Azure Active Directory (AAD). Even though you can’t see these
groups through the AAD console, you can assign admin roles either in the Microsoft 365 admin center or
using Windows PowerShell.
To assign admin roles in Microsoft 365 admin center, you need to login using a Global admin account
and follow these steps:
1. In the Admin center, select Users, and then click Active Users.
2. On the Active users page, choose the user whose administrator role you want to change. The
Properties page for the user opens.
3. Next to Roles, click Edit.
4. On the Edit user roles page, you can choose the following options:
●● User (no administrator access)
●● Global administrator
●● Customized administrator (to see a list of admin roles)
5. In the Alternative email address field, you can type an email address that is not connected to Office
365. This email address is used for important notifications, including resetting your admin password.
6. To close the Edit user roles page, click Save.
If you want to use Windows PowerShell to assign admin roles to your users, you need to use the
Get-MsolRolecmdlet to find out what is the admin role name you want to assign, and then use the
Add-MsolRoleMember cmdlet to assign the role to a user. For example, the following cmdlet adds the
user Stella Carrillo to the Exchange administrator role:
Add-MsolRoleMember -RoleName "Exchange Service Administrator" -RoleMemberE-
mailAddress "[email protected]”
 MCT USE ONLY. STUDENT USE PROHIBITED
Admin Roles and Security Groups in Microsoft 365  11

Overview of Groups in Microsoft 365

You can use groups to manage sets of users at the same time. For example, if you create a group that
includes your team, you can use this group to apply permissions on a SharePoint team site or distribute
messages to everyone who is member or the group. The following table provides an overview of all
group types, and where you create it in Microsoft 365.

Group Type Description When to use? Where to create it?

Office 365 group Similar to distribution When you want to Microsoft 365 admin
groups. Has its own provide distribution list center, Microsoft 365
mailbox and its mem- capabilities and addi- admin app, Groups app,
bers receive email tional collaboration Exchange admin center,
messages that are sent features. The best and Outlook
to the group. It provides option for team work.
a shared workspace for
email, conversations,
files, and calendar
events.
Distribution list Can only be used for When you want to Microsoft 365 admin
sending email. An email distribute messages center, Microsoft 365
sent to a distribution list using the group only. admin app, or Exchange
is sent to all members admin center
of the group.
In Exchange, this group
type is called distribu-
tion group.
Mail-enabled security Can be used for sending When you want to use Microsoft 365 admin
group email. However, you can the group for both center, Microsoft 365
also assign group permissions and mail admin app, or Exchange
permissions; for exam- distribution. admin center
ple, to Exchange Public
Folders or OneDrive.
Security group Can be used to grant When you only require Microsoft 365 admin
access permissions to a group to grant center or Microsoft 365
resources such as permissions. admin app
OneDrive.
Dynamic distribution Can use recipient filters When you want to have Exchange admin center
group  (Exchange and conditions that you a flexible distribution list
only) define to dynamically that changes member-
determine membership. ship automatically.
These groups do not
have a predefined
member list.

SharePoint Online groups

SharePoint Online groups are collections of users who have the same permission level, allowing you to
grant access to your SharePoint Online sites to multiple users. SharePoint Online groups greatly enhance
and simplify the permissions-management process for administrators. Although SharePoint Online
groups can contain individual users, it is easier to manage them with security groups from Microsoft 365.
MCT USE ONLY. STUDENT USE PROHIBITED 12  Module 1 Managing User Security Groups and Licenses

Several built-in groups are created when you create a site collection in SharePoint Online. These are
referred to as default SharePoint Online groups. Which default SharePoint Online groups are created
depends on the site template that is used to create the site. For example, the Team Site template contains
the following default SharePoint Online groups: Team Site Visitors, Team Site Members, and Team Site
Owners.

Creating and Managing Groups

You can use the Microsoft 365 admin center to organize users into logical groupings to which you can
assign permissions. For example, you could create a security group with all users from the Marketing
department to allow them Full Control access to a marketing SharePoint site collection.
To ensure that you create and manage your groups correctly, you should consider the following best
practices:
●● Keep your group naming convention simple but clear.
●● Create policies and procedures for ongoing group maintenance.
●● Add users to security groups and then add those security groups to default groups rather than adding
individual users to the groups.
●● Maintain a consistent and well-defined account provisioning process.
To create a security group in the Microsoft 365 admin center:
1. In the Microsoft 365 admin center, on the left navigation pane, click Groups.
2. Click Add a group, and on the Add a group page, select Security group, provide a group name and
description for the group, and then click Add.
3. On the group property page, add the users that you want to add to the security group.
The following screen shot displays the Microsoft 365 admin center, where you can decide what group
type you want to create and then create it.
 MCT USE ONLY. STUDENT USE PROHIBITED
Admin Roles and Security Groups in Microsoft 365  13

You can also use Windows PowerShell to create security groups for Microsoft 365 by using the
New-MsolGroup cmdlet.
Important: You cannot use the Microsoft 365 admin center to edit security groups if they are synchro-
nized with your on-premises Active Directory. You must use local Active Directory management tools for
this purpose.

Determining group types

You can determine the different types of groups by using the Microsoft 365 admin center. When you view
groups in the Microsoft 365 admin center, the Type column displays the group type for your reference.
You can also use the Get-MsolGroup | Select DisplayName, GroupType command in the Azure AD
module for Windows PowerShell to display group type information.

Nesting security groups

You can nest security groups by adding one security group to another. To do this, when adding group
members in the Microsoft 365 admin center, select the appropriate group instead of a user. You also can
use Windows PowerShell to nest security groups.
MCT USE ONLY. STUDENT USE PROHIBITED 14  Module 1 Managing User Security Groups and Licenses

Editing security groups

You can edit the name, description, and members of an existing security group.

Deleting security groups

When you no longer need a security group, you can use the Microsoft 365 admin center or Windows
PowerShell to delete it. Unlike user accounts, when you delete a security group, it is permanently deleted,
and you cannot restore it. User accounts that were members of the deleted security group remain intact.
To delete a security group in the Microsoft 365 admin center:
1. In the Microsoft 365 admin center, on the Groups menu, click Groups.
2. Select the security group that you want to delete.
3. In the details pane on the right, click Delete group.
4. Confirm that you want to delete the group.
You can also use Windows PowerShell to delete security groups for Microsoft 365 by using the Re-
move-MsolGroup cmdlet.

Azure AD Prvilieged Identity Management

Azure AD Privileged Identity Management enables you to manage, control, and monitor access within
your organization. This includes access to resources in Azure AD, Azure Resources, and other Microsoft
Online Services like Microsoft 365 and Microsoft Intune.
Azure AD Privileged Identity Management helps your organization:
●● See which users are assigned privileged roles to manage Azure resources, as well as which users are
assigned administrative roles in Azure AD
●● Enable on-demand, “just in time” administrative access to Microsoft Online Services like Microsoft 365
and Intune, and to Azure resources of subscriptions, resource groups, and individual resources such as
Virtual Machines
●● See a history of administrator activation, including what changes administrators made to Azure
resources
●● Get alerts about changes in administrator assignments
●● Require approval to activate Azure AD privileged admin roles
●● Review membership of administrative roles and require users to provide a justification for continued
membership

Just in time administrator access

Historically, you could assign a user to an admin role through the Azure portal, other Microsoft Online
Services portals, or the Azure AD cmdlets in Windows PowerShell. As a result, that user becomes a
permanent admin, always active in the assigned role. In addition to permanent admins, the Azure AD
Privileged Identity Management PIM service introduces the concept of an eligible admin.
Eligible admins are users that need privileged access periodically, but not all-day, every day. The role is
inactive until the user needs access, then he or she completes an activation process and becomes an
active admin for a predetermined amount of time. More and more organizations are choosing to use this
approach to reduce or eliminate “standing admin access” to privileged roles.
 MCT USE ONLY. STUDENT USE PROHIBITED
Admin Roles and Security Groups in Microsoft 365  15

Enable Privileged Identity Management for your directory

You should perform the following steps to enable Privileged Identity Management for your directory:
1. Sign in to the Azure portal2 as a global administrator of your directory.
2. If your organization has more than one directory, select your username in the upper right-hand corner
of the Azure portal. Select the directory where you will use Azure AD Privileged Identity Management.
3. Select All services and use the Filter text box to search for Azure AD Privileged Identity Management.
4. Select Pin to dashboard and then click Create. The Privileged Identity Management application
opens.
Additional reading. For more information, see the following article on how to Assign directory roles to
users using Azure AD PIM3.

Role activation
To activate a role, an eligible admin requests a time-bound “activation” for the role. The activation can be
requested using the Activate my role option in Azure AD Privileged Identity Management. An admin who
wants to activate a role needs to initialize Azure AD Privileged Identity Management in the Azure portal.
Role activation is also customizable. In the Privileged Identity Management settings, you can determine
the length of the activation and what information the admin needs to provide to activate the role.
Additional reading. For more information, see the following article on How to activate or deactivate
roles in Azure AD Privileged Identity Management4.

2 https://portal.azure.com/
3 https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-add-role-to-user
4 https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-activate-role
MCT USE ONLY. STUDENT USE PROHIBITED 16  Module 1 Managing User Security Groups and Licenses

Review Activity - Admin Roles and Security

Groups

Let's play a quick game to test your knowledge of administrator roles and security groups in Microsoft
365. Click on the button below to open this review activity full screen.
LAUNCH ACTIVITY5

5 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M01_L02_match_AdminRoles-
tutorial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Password Management in Microsoft 365  17

Password Management in Microsoft 365

Lesson Introduction
Organizations must ensure that access to their company data on Microsoft365 is always secure for their
employees, and that data is protected from unauthorized access. One of the most important actions
when securing access to Microsoft 365 is to configure secure password policies. Password policies require
users to perform actions that increase password protection, such as changing passwords at specified
intervals, creating complex passwords, resetting their own passwords, and signing in with multi-factor
authentication.
In this lesson, you will learn various password related tasks for a user account including creating and
configuring password policies, configuring self-service password management, and configuring multi-fac-
tor authentication.
After this lesson, you will be able to:
●● Plan for password policies and authentication
●● Implement Multi-factor authentication in your Office 365 tenant
●● Plan and implement Self-service password management

Planning Password Policies and Authentication

Microsoft 365 helps provide secure access by requiring users to sign in with a password. You need to
perform various tasks to manage passwords for your organization’s users. These tasks can include
changing passwords, setting password expiration, and resetting passwords.

Setting password expiration

In Microsoft 365, users’ passwords expire by default after 90 days, and users receive notification of
impending password expiration 14 days before it occurs.
You can use the Microsoft 365 admin center to change this setting for your organization. To change the
password expiration policy, perform the following steps:
1. In the Microsoft 365 admin center, on the Settings menu, click Security & privacy.
2. In the Password policy section, click Edit.
3. Specify the number of days between 14 and 730 for password expiration.
4. Specify the number of days between 1 and 30 for the notification warning of password expiration.
5. Save your settings.
MCT USE ONLY. STUDENT USE PROHIBITED 18  Module 1 Managing User Security Groups and Licenses

If a user does not change his or her password before the expiration time has elapsed, they can still
change it by using the Password update page that appears the next time they sign in. Alternatively, you
can reset their password for them.
You also have the option on the Password update page to set user passwords to never expire. This
disables password expiration for all users. However, disabling password expiration for all your users is not
recommended because of the potential that a password will be hacked or leaked over time.
To disable password expiration for single users using PowerShell, you need to use the Set-MsolUser
cmdlet with the -PasswordNeverExpires parameter.

Resetting user passwords

If necessary, you can reset a password for one or more users on the Active users page. You can assign a
new, randomly-generated password or a password of your choice. You can also select whether users need
to change their password at their next sign in.
 MCT USE ONLY. STUDENT USE PROHIBITED
Password Management in Microsoft 365  19

Resetting admin passwords

If you forget your own administrator password, the two available options are:
●● Ask another administrator to reset it for you. In this case, the other administrator must be a global
admin, a user management admin, or a password admin. However, if your account is a global admin
account, you must get another administrator with a global admin account to reset it for you.
●● Reset the password yourself. On the sign-in page for Microsoft 365, you can use the Can’t access
your account? link to reset your password. When you follow the instructions provided by the link, you
are sent an email with a link that allows you to reset your password.
You must have already supplied an alternative email address in your account settings for this to work; this
must not be your Microsoft 365 email address. Additionally, if you use a custom domain name or you are
using directory synchronization, you must have also supplied a phone number in your account details
that can receive text notifications. In this case, a code will generate automatically and be sent as a text
message to your mobile phone, and you will need to enter this code on the mobile phone verification
page.
Important: If resetting the password for yourself, you must complete the entire admin password reset
process within 10 minutes; otherwise, you will need to start the process over.

Implementing Multi-Factor Authentication

Multi-factor Authentication (MFA) in Microsoft 365 helps increase security by requesting users to provide
a user name and a password while signing in and then use a second authentication method. The second
authentication method might be acknowledging a phone call, text message, or an app notification on
their smartphone. If the user names, passwords, and second authentication method are verified, the users
MCT USE ONLY. STUDENT USE PROHIBITED 20  Module 1 Managing User Security Groups and Licenses

can sign in to Microsoft 365. You can also enable users who authenticate from a federated, on-premises
directory for multi-factor authentication.
The tenant administrator enables MFA in the Microsoft 365 admin center by performing the following
steps:
1. In the Microsoft 365 admin center, on the Settings menu, click Services & add-ins.
2. On the Services & add-ins page, click Azure multi-factor authentication.
3. On the Azure multi-factor authentication page, click Manage multi-factor authentication.
4. On the multi-factor authentication page, select the users that you need to enable for multi-factor
authentication, and then click Enable.
You can also use Windows PowerShell to enable MFA for a user. This is done by using the Set-MsolUser
cmdlet and the -StrongAuthenticationRequriement parameter, as seen in the following example:
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenti-
cationRequirement$st.RelyingParty = "*"$st.State = “Enabled”$sta = @($st)
Set-MsolUser -UserPrincipalName [email protected] -StrongAu-
thenticationRequirements $sta

After the administrator enables users for multi-factor authentication, they must configure their second
authentication factor at their next sign-in. You can use the following options as the second authentication
factor:
●● Call to phone. Users receive a phone call with instructions for the users to press the pound key. After
they press the pound key, users are signed in.
●● Text message to phone. Users receive a text message containing a six-digit code that they must
enter into the Office 365 portal.
●● Notification through mobile app. Users configure a smartphone app that receives a notification that
users need to confirm to sign in to Microsoft 365. Smartphone apps are available for Windows phone,
iPhone, and Android devices.
●● Verification code from mobile app. Users configure a smartphone app and enter the six-digit code
from the app into the portal.
The multi-factor authentication methods can be configured in the service settings of the Microsoft 365
admin center as the following screen shot indicates.
 MCT USE ONLY. STUDENT USE PROHIBITED
Password Management in Microsoft 365  21

Additional reading. For more information, see the following article on how to Deploy cloud-based
Azure Multi-Factor Authentication6.

Plan and Implement Self-Service Password Man-

agement
Self-service password reset (SSPR) allows users to reset their own password without requiring interven-
tion by an administrator. SSPR is not enabled by default; the Microsoft 365 Enterprise Administrator
needs to enable SSPR for all users or for specific groups.
To reset a password, users must authenticate their identity first. The following verification methods are
available:
●● Send email to alternate email address
●● Call office phone

6 https://go.microsoft.com/fwlink/?LinkId=627442
MCT USE ONLY. STUDENT USE PROHIBITED 22  Module 1 Managing User Security Groups and Licenses

●● Call mobile phone

●● Text mobile phone
●● Answer security questions
If users forget their passwords, they can reset them by clicking the can’t access your account? link on the
Microsoft 365 Sign in page. However, if the users have not entered their alternate personal information,
they will not be able to reset their password, and they will have to contact the tenant administrator to
reset their password. Microsoft Support cannot reset forgotten passwords.
If an administrator wants to use SSPR, they must use two verification methods, and they are not able to
use security questions.
Self-service password reset is available only for Microsoft 365 users with cloud identities where a pass-
word is not linked to the on-premises AD DS. This is because a password from Microsoft 365 cannot be
synchronized back to on-premises AD DS without additional services.

Password writeback
Paid subscriptions for Microsoft 365 store user information in Azure AD Basic. Azure AD Basic is unable to
write back a password change from Azure AD to on-premises AD DS. If you purchase Azure AD Premium,
it includes the ability to write back passwords. This enables you to implement self-service password reset
for synchronized identities and federated identities. This also enhances AD DS by providing a portal for
password reset.
Additional reading. For more information about SSPR, see the following article on resetting your work
or school password7.

Manage Access Review

Azure Active Directory (Azure AD) access reviews enable organizations to efficiently manage group
memberships, access to enterprise applications, and privileged role assignments. With access reviews,
Microsoft 365 Global admins and User Account admins can perform the following tasks:
●● You can evaluate guest user access by reviewing their access to applications and memberships of
groups. Reviewers can use the insights that are provided to efficiently decide whether guests should
have continued access.
●● You can evaluate employee access to applications and group memberships with access reviews.
●● You can collect access review controls into programs that are relevant for your organization to track
reviews for compliance or risk-sensitive applications.
●● You can evaluate the role assignment of administrative users who are assigned to Azure AD roles such
as Global Administrator or Azure subscription roles. This capability is included in Azure AD Privileged
Identity Management.

Prerequisites
Access reviews are available with the Premium P2 edition of Azure AD, which is included in Microsoft
Enterprise Mobility + Security, E5.
Additional reading. For more information, see Azure Active Directory editions8.

7 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords
8 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-editions
 MCT USE ONLY. STUDENT USE PROHIBITED
Password Management in Microsoft 365  23

Create an access review

Global admins and User Account admins can create an access review by performing the following steps:
1. In the Microsoft Azure dashboard, sign in to your tenant, then go to the access reviews page9 and
select Programs.
2. Select the program that holds the access review control you want to create. Default Program is
always present, or you can create a different program. For example, you can choose to have one
program for each compliance initiative or business goal.
3. Within the program, select Controls, and then select Add to add a control.
4. Enter a name for the access review and an optional description. The name and description are shown
to the reviewers.
5. Set the start date. By default, an access review occurs once, starts the same time it's created, and it
ends in one month. You can change the start and end dates to have an access review start date in the
future, and you can set it to last however many days you want.
6. To make the access review recurring, change the frequency from One time to Weekly, Monthly,
Quarterly, or Annually, and use the slider or text box to define how many days each review of the
recurring series will be open for input from reviewers. For example, the maximum duration for you can
set for a monthly review is 27 days, to avoid overlapping reviews.
7. The recurring access review series can end in 3 ways: it runs continuously to start reviews indefinitely,
until a specific date, or after a defined number of occurrences has been completed. Either you, or
another user account administrator, or another global administrator can stop the series after creation
by changing the date in Settings, so that it ends on that date.
8. Access reviews can be for the members of a group or for users who were assigned to an application.
You can further scope the access review to review only the guest users who are members (or assigned
to the app), rather than reviewing all the users who are members or who have access to the applica-
tion.
9. Select either one or more people to review all the users in scope, or you can select to have the
members review their own access. If the resource is a group, you can ask the group owners to review.
You also can require that the reviewers supply a reason when they approve access.
10. If you wish to manually apply the results when the review completes, click Start. Otherwise, the next
section explains how to configure the review to automatically apply the results.

Create and perform an access review

You can have one or more users as reviewers in an access review.
1. Select a group in Azure AD that has one or more members, or select an application connected to
Azure AD that has one or more users assigned to it.
2. Decide whether to have each user review his or her own access or to have one or more users review
everyone's access.
3. Enable access reviews to appear on the reviewers' access panels. As a global administrator or user
account administrator, go to the access reviews page10.
4. Start the access review. For more information, see Create an access review11.

9 https://portal.azure.com/
10 https://portal.azure.com/
11 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-create-access-review
MCT USE ONLY. STUDENT USE PROHIBITED 24  Module 1 Managing User Security Groups and Licenses

5. Ask the reviewers to give input. By default, they each receive an email from Azure AD with a link to the
access panel, where they perform their access review12.
6. If the reviewers haven't given input, you can ask Azure AD to send them a reminder. By default, Azure
AD automatically sends a reminder halfway to the end date to reviewers who haven't yet responded.
7. After the reviewers give input, stop the access review and apply the changes. For more information,
see Complete an access review13.

Configuring an access review with auto-apply

1. Expand the menu for Upon completion settings and then enable Auto apply results to resource.
2. In cases where users were not reviewed by the reviewer within the review period, you can have the
access review either take the system's recommendation (if enabled) on denying/approving the user's
continued access, leave their access unchanged, or remove their access. This will not impact users who
have been reviewed by the reviewers manually –if the final reviewer’s decision is Deny, then the user’s
access will be removed.
3. To enable the option to take recommendations should reviewers not respond, expand Advanced
settings and enable Show recommendations.
4. Finally, click Start.
Based on your selections in Upon completion settings, auto-apply will be executed after the review's end
date or when you manually stop the review. The status of the review will change from Completed through
intermediate states such as Applying and finally to state Applied. You should expect to see denied users,
if any, being removed from the group membership or app assignment in a few minutes.

Manage the access review

By default, Azure AD sends an email to reviewers shortly after the review starts. If you choose not to have
Azure AD send the email, be sure to inform the reviewers that an access review is waiting for them to
complete. You can show them the instructions for how to review access14. If your review is for guests to
review their own access, show them the instructions for how to review your own access15.
If some of the reviewers are guests, guests are notified via email only if they've already accepted their
invitation.
To manage a series of access reviews, navigate to the access review from Controls, and you will find
upcoming occurrences in Scheduled reviews, and edit the end date or add/remove reviewers accordingly.
You can track the progress as the reviewers complete their reviews in the Azure AD dashboard in the
Access Reviews section. No access rights are changed in the directory until the review is completed16.

12 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-perform-access-review
13 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-complete-access-review
14 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-perform-access-review
15 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-perform-access-review
16 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-complete-access-review
 MCT USE ONLY. STUDENT USE PROHIBITED
Password Management in Microsoft 365  25

Review Activity - Password Management in Mi-

crosoft 365

Let's play a quick game to test your knowledge of password management in Microsoft 365. Click on the
button below to open this review activity full screen.
LAUNCH ACTIVITY17

17 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M01_L03_fill_Passwordtutorial.
html
MCT USE ONLY. STUDENT USE PROHIBITED 26  Module 1 Managing User Security Groups and Licenses

Non-Graded Practice Lab 1

Non-Graded Practice Lab 1 - Managing Micro-
soft 365 Identities

Non-Graded Practice Lab 1: Managing Microsoft 365 Iden-

tities
To perform the Managing Microsoft 365 Identities practice labs, you must first download the MS100.3x
Student Lab Manual. This manual provides the instructions that are required to complete the exercises for
this practice lab. If you did not download the Microsoft Virtual Machine User Guide and the
MS100.3x Student Lab Manual from the Course Handouts section of the Home page18 during the
Course Introduction, then please do so now.
In this lab, you should only perform Lab 1 in the Student Lab Manual (you will perform Lab 2 after
completing Module 2). In Lab 1, you will:
●● Create a Microsoft 365 tenant account
●● Manage your Microsoft 365 identity environment using the Microsoft 365 admin center
●● Manage your Microsoft 365 identity environment using Windows PowerShell
Once you are ready, please complete these practice lab exercises by performing the following steps:
1. Download the Microsoft Virtual Machine User Guide from the Course Updates page if you haven't
done so already. Study this guide to learn how to work your way through the virtual lab environment.
2. Download the MS100.3x Student Lab Manual from the Course Updates page if you haven't done so
already. This manual contains the lab instructions that you must follow to complete this practice lab.
3. Click the Launch Lab button below. This will open the Microsoft Labs Online web site and the virtual
machine that is used for this lab.
4. Complete the Lab 1 practice lab by following the steps in the MS100.3x Student Lab Manual.

18 https://openedx.microsoft.com/courses/course-v1:Microsoft+MS-100.3+2018_T3/info
 MCT USE ONLY. STUDENT USE PROHIBITED
Non-Graded Practice Lab 1  27

5. NOTE: Do not perform Lab 2 at this point. You will perform Lab 2 at the end of Module 2.
 MCT USE ONLY. STUDENT USE PROHIBITED
Module 2 Planning and Implementing Identity
Synchronization

Introduction to Identity Synchronization

Lesson Introduction
If you have an existing on-premises directory, such as Active Directory, you can integrate it with Azure AD
by synchronizing your identities from the on-premises directory to Microsoft 365 using a synchronization
tool such as Azure AD Connect. In this model, you continue to use your on-premises management tools
to administer the identities in the on-premises directory. Then new accounts and changes are automati-
cally synchronized to Azure AD, and thus Microsoft 365.
In this lesson, you will learn about identity synchronization using Azure AD Connect.
After this lesson, you will be able to:
●● Describe the Microsoft 365 authentication options
●● Explain directory synchronization
●● Provide an overview of Azure AD Connect

Microsoft 365 Authentication Options

MCT USE ONLY. STUDENT USE PROHIBITED 30  Module 2 Planning and Implementing Identity Synchronization

Microsoft 365 Provisioning Options

Directory Synchronization Overview

Directory synchronization is the synchronization of directory identities or objects (users, groups, contacts,
and computers) between two different directories, such as your on-premises Active Directory environ-
ment and Azure AD which supports online services like Microsoft 365. However, directory synchronization
is not limited to any one specific directory, and in fact, might include other directories such as HR
databases and an LDAP directory, as seen in the following diagram.

In Microsoft 365, directory synchronization is commonly used to synchronize in one direction (from
on-premises to Azure AD). However, some features in Azure AD Connect allow it to write-back specific
objects and attributes to the on-premises directory; therefore, creating some sort of two-way synchroni-
zation. In addition to directory objects, directory synchronization can provide two-way synchronization of
 MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Identity Synchronization  31

user passwords as well. Directory synchronization tools that perform this synchronization, such as Azure
AD Connect, should be installed on a dedicated computer in your on-premises environment.
Integrating your on-premises directories with Azure AD allows your users to improve productivity by
reducing the amount of time spent typing in passwords for accessing both cloud and on-premises
resources.
With this integration, users and organizations can take advantage of the following:
●● Hybrid identity. Organizations can provide users with a common hybrid identity across on-premises
or cloud-based services, including consistent group membership, by leveraging Active Directory and
then connecting to Azure AD.
●● AD Policies. Administrators can use policies set through Active Directory to provide conditional
access based on application resource, device and user identity, network location, and multi-factor
authentication without having to perform additional tasks in the cloud.
●● Leverage identity. Users can leverage their common identity through accounts in Azure AD to Office
365, Intune, SaaS apps, and non-Microsoft applications.
●● Single-sign-on (SSO). Security will have confidence in knowing that user identities and information
are protected because all the servers and services used in SSO are mastered and controlled on-prem-
ises.
●● Multi-factor authentication (MFA). Security will have greater confidence when they have the option
to use strong authentication, also called multi-factor authentication (MFA), with the cloud service.
●● Common identity model. Developers can build applications that leverage the common identity
model, integrating applications into on-premises Active Directory when leveraging (such as Azure AD
App Proxy or Azure for cloud-based applications).
Additional reading. For more information, see the following article titled Get started with conditional
access in Azure Active Directory1.

Azure AD Connect Overview

The Azure Active Directory Connect (Azure AD Connect) tool, formerly known as Windows Azure Active
Directory Synchronization or DirSync, is the officially recommended directory synchronization tool for
Microsoft 365. Azure AD Connect is designed to operate as a software-based tool that you configure
once, and it automatically runs in the background without user interaction. For Microsoft 365, the
purpose of the tool is to enable coexistence between your on-premises Active Directory environment and
Microsoft 365 in the cloud.
Azure AD Connect is made up of three parts - the synchronization services, the optional Active Directory
Federation Services piece, and the monitoring piece, which is done using Azure AD Connect Health.

Using Azure AD Connect for Directory Synchronization

Azure AD Connect provides synchronization of objects between Active Directory and Azure AD, the
directory for Microsoft 365.
When using Azure AD Connect for directory synchronization:
●● New user, group, and contact objects in on-premises Active Directory are added to Microsoft 365;
however, Microsoft 365 licenses are not automatically assigned to these objects.

1 https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal-get-started
MCT USE ONLY. STUDENT USE PROHIBITED 32  Module 2 Planning and Implementing Identity Synchronization

●● Attributes of existing user, group, and contact objects that are modified in on-premises Active
Directory are modified in Microsoft 365; however, not all on-premises Active Directory attributes are
synchronized to Microsoft 365.
●● Existing user, group, and contact objects that are deleted from on-premises Active Directory are
subsequently deleted from Microsoft 365.
●● Existing user objects that are disabled on-premises are subsequently disabled in Microsoft 365;
however, licenses are not automatically unassigned.
Additionally, Azure AD Connect supports the following scenarios:
●● Multiple Active Directory forest environments.
●● Multiple Exchange organizations to one Microsoft 365 tenant.
Azure AD requires a single source of authority for every object. Therefore, in the scenario in which you
have deployed Azure AD Connect for Active Directory synchronization, there are two things that are
important to understand:
●● The source of authority is the on-premises Active Directory.
●● You are mastering objects from within your on-premises Active Directory by using whatever manage-
ment tools you are using today, such as Active Directory Users and Computers or Windows Power-
Shell.
In this scenario, after the first synchronization cycle has completed, the source of authority is transferred
from the cloud to the on-premises Active Directory. All subsequent changes to cloud objects (except for
licensing) are mastered from the on-premises Active Directory tools. The corresponding cloud objects are
read-only, and Microsoft 365 administrators cannot edit cloud objects if the source of authority is
on-premises.

Additional Azure AD Connect features

Azure AD Connect comes with several features you can optionally turn on or are enabled by default:
●● Exchange hybrid deployment. Used to implement an Exchange hybrid deployment with one or
multiple on-premises Exchange organizations.
●● Exchange Mail Public Folders. Synchronize Mail-Enabled Public Folder objects from on-premises
Active Directory to Azure AD. This is required to include Public Folder addresses in Directory Based
Edge Blocking. This option does not create the public folder objects in Exchange Online, as this
requires an additional Windows PowerShell script.
●● Azure AD app and Object filtering. Is used when you want to limit which objects are synchronized
to Azure AD. By default, all users, contacts, groups, and Windows 10 computers are synchronized. You
can change the filtering based on domains, OUs, or attributes.
●● Password hash synchronization. Synchronizes the password hash in Active Directory to Azure AD.
The end-user can use the same password on-premises and in the cloud but only manage it in one
location by default. Since it uses your on-premises Active Directory as the authority, you can also use
your own password policy (Note: You can enable self-service password reset through the Azure
console).
●● Password passthrough authentication. This configuration validates users’ passwords directly against
your on-premises Active Directory using an encrypted public key between Azure and the on-premises
 MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Identity Synchronization  33

Active Directory environment without sending password hashes to Microsoft 365. For more informa-
tion, see the following article on Azure Active Directory Passthrough Authentication2.
●● Password writeback. Will allow your users to change and reset their passwords in the cloud and have
your on-premises password policy applied.
●● Group writeback. Allows all Microsoft 365 groups to be synchronized to your Active Directory.
●● Device writeback. Will allow a device registered in Azure AD to be written back to on-premises
Active Directory so it can be used for conditional access.
●● Directory extension attribute sync. Directory extensions allows you to extend the schema in Azure
AD with your own attributes from on-premises Active Directory.
●● Prevent accidental deletes. Is turned on by default and protects your cloud directory from numerous
deletes at the same time. By default, it allows 500 deletes per run. You can change this setting de-
pending on your organization size.
●● Automatic upgrade. Is enabled by default for express settings installations and ensures your Azure
AD Connect is always up to date with the latest release.
●● SSO using AD FS. Configures an Active Directory Federated Services environment to support sin-
gle-sign on (SSO) in Office 365.
●● Seamless single sign-on (SSO) using Pass-through authentication (PTA). Allows sign in to Azure
AD by directly validating the users’ passwords directly against on-premises Active Directory.
Note: As Azure AD Connect features continuously improve and change, it is important to regularly visit
the Azure AD Connect: Version release history3 site for information on recent changes.

2 https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-how-it-works
3 https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history
MCT USE ONLY. STUDENT USE PROHIBITED 34  Module 2 Planning and Implementing Identity Synchronization

Review Activity - Identity Synchronization

Let's play a quick game to test your knowledge of identity synchronization. Click on the button below to
open this review activity full screen.
LAUNCH ACTIVITY4

4 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M02_L01_flip_IdentitySychtu-
torial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Azure AD Connect  35

Planning for Azure AD Connect

Lesson Introduction
To plan your directory synchronization with Microsoft 365, you need to understand the source directory,
such as Active Directory, as well as other connected directories. The planning task is crucial for a success-
ful implementation.
In this lesson, you will learn all the planning aspects that need to be considered when implementing
directory synchronization with Microsoft 365.
After this lesson, you will be able to:
●● Plan directory synchronization
●● Describe and plan Azure AD Connect
●● Consider Azure AD Connect for multi-forest scenarios
●● Describe Azure AD Connect pass-through authentication

Planning Directory Synchronization

Planning for Azure AD Connect

MCT USE ONLY. STUDENT USE PROHIBITED 36  Module 2 Planning and Implementing Identity Synchronization

Planning Azure AD Connect for Multi-Forest

Scenarios

Planning Azure AD Connect Pass-thorugh Au-

thentication
It is very beneficial for users to use the same set of credentials to authenticate against both cloud and
on-premises resources. Usually, this is achieved by using Azure AD Connect synchronization with a
password hash synchronization. In scenarios where organizations want to perform all authentication
on-premises, you should deploy an AD FS service and configure your Azure AD tenant in federated mode.
In this scenario, each authentication request for resources on-premises or in a cloud, is always directed to
the AD FS server deployed locally. However, deployment and management of the locally deployed AD FS
infrastructure might be too demanding and too complex for some organizations. A recent update to
Azure AD Connect provided a new option to address this scenario. This new feature is called Azure AD
pass-through authentication.
Azure AD pass-through authentication (PTA) helps ensure that password validation for services that rely
on Azure AD is always performed against an on-premises Active Directory. If PTA fails, automatic failover
to password hash synchronization is performed if it’s enabled. Unlike the AD FS solution, PTA is easy to
implement and maintain.
Azure AD pass-through authentication is configured by using Azure AD Connect, and it works by using
an on-premises agent that listens for external password validation requests. You can deploy this agent to
one or more servers to provide high availability. There is no need to deploy this server to the perimeter
network, as all communication is outbound only. A server that runs the agent for pass-through authenti-
cation should be joined to the Active Directory domain where users are located.
Additional reading. For more information, see the following article on User sign-in with Azure Active
Directory Pass-through Authentication5.

5 https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-how-it-works
 MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Azure AD Connect  37

When a user accesses a cloud service that relies on Azure AD, he or she is presented with an Azure AD
login page. After a user enters his or her credentials into the Azure AD login page, the Azure AD service
checks if the connector for pass-through authentication is configured for the user’s domain. If it is,
credentials are placed on the connector queue for validation. A connector agent deployed on-premises
then retrieves user credentials and performs authentication against the locally deployed Active Directory.
Response from Active Directory is returned to the connector and the connector provides this response to
Azure AD. To enable Azure AD pass-through authentication:
●● Run the Azure AD Connect Setup Wizard
●● On the User Sign-in page, you should select the Pass-through authentication option
The first connector for pass-through authentication is deployed on the same server where Azure AD
Connect runs. However, it is recommended that you deploy an additional connector on at least one more
server to achieve load balancing between the set of available connectors for both high availability and
redundancy. For other servers, you can download the Azure AD Application Proxy Connector as a sepa-
rate installation.
In addition, you should ensure that all ports required for Azure AD pass-through authentication are
available, as listed in the table below.

Port Description
80 Enables outbound HTTP traffic for security
validation such as SSL certificate revocation lists.
443 Enables user authentication against Azure AD.
8080/443 Enables the Connector bootstrap sequence and
Connector automatic update.
9090 Enables Connector registration (required only for
the Connector registration process).
9091 Enables Connector trust certificate automatic
renewal.
9352, 5671 Enables communication between the Connector
and the Azure AD service for incoming requests.
9350 [Optional] Enables better performance for incom-
ing requests.
10100–10120 Enables responses from the connector back to
Azure AD.
MCT USE ONLY. STUDENT USE PROHIBITED 38  Module 2 Planning and Implementing Identity Synchronization

Additional reading. For more information, see User sign-in with Azure AD Pass-through Authentica-
tion6.

Review Activity - Planning for Azure AD Connect

Let's play a quick game to test your knowledge of planning for Azure AD Connect. Click on the button
below to open this review activity full screen.
LAUNCH ACTIVITY7

6 https://aka.ms/lusqtt
7 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M02_L02_flash_PlanADcon-
necttutorial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing Azure AD Connect  39

Implementing Azure AD Connect

Lesson Introduction
Once you finished planning for your directory synchronization implementation, you are ready to deploy
Azure AD Connect to your environment.
In this lesson, you will examine the Azure AD Connect installation requirements, the options for installing
and configuring the tool, and how to monitor your Azure AD Connect health.
After this lesson, you will be able to:
●● Configure Azure AD Connect Prerequisites
●● Set up Azure AD Connect
●● Describe Azure AD Connect Health

Configuring Azure AD Connect Pre-requisites

Set Up Azure AD Connect

MCT USE ONLY. STUDENT USE PROHIBITED 40  Module 2 Planning and Implementing Identity Synchronization

Azure AD Connect Health

Review Activity - Implementing Azure AD Con-

nect

Let's play a quick game to test your knowledge of implementing Azure AD Connect. Click on the button
below to open this review activity full screen.
LAUNCH ACTIVITY8

8 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M02_L03_tile_ImpADconnect-
tutorial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Managing Synchronized Identities  41

Managing Synchronized Identities

Lesson Introduction
Once you implement Azure AD Connect, it’s important to remember that you can no longer manage
objects using the Microsoft 365 admin center from that point forward.
In this lesson, you will learn about managing user identities when Azure AD Connect is configured. You
will also examine how to manage users and groups in Microsoft 365 with Azure AD Connect and how to
maintain directory synchronization.
After this lesson, you will be able to:
●● Manage users with directory synchronization
●● Manage groups with directory synchronization
●● Using Azure AD Connect Sync Security Groups
●● Troubleshooting directory synchronization

Managing Users with Directory Synchronization

Managing Groups with Directory Synchroniza-

tion
Once you implement directory synchronization using Azure AD Connect between your Active Directory
and Azure AD, you need to manage all group membership in your Active Directory.
However, there is some functionality that you should consider which allows you to write back any created
Microsoft 365 groups.
Like the directory synchronization of users from on-premises Active Directory to Azure AD, groups (as
well as their membership) in Active Directory also synchronize from on-premises Active Directory to
Azure AD. And similar to the user writeback feature, the group writeback feature also writes Microsoft
365 groups from Azure AD to on-premises Active Directory. This feature is included as an optional feature
in Azure AD Connect.
To enable group writeback, you need to consider these requirements:
●● You must run Exchange 2013 CU8 or later, or Exchange 2016 to recognize this new group type.
●● You must create the OU and appropriate permissions required for group writeback in Active Directory.
To complete this task, Azure AD Connect has a built-in cmdlet, Initialize-ADSyncGroupWriteBack,
which prepares Active Directory automatically.
MCT USE ONLY. STUDENT USE PROHIBITED 42  Module 2 Planning and Implementing Identity Synchronization

After the synchronization completes, Microsoft 365 groups will appear in the on-premises container that
you selected during the configuration, and they will be represented as distribution groups in on-premises
Active Directory.
Note: The Group writeback feature does not involve security groups or distribution groups.
The synchronized groups will not show up in your on-premises Exchange Global Address List immediate-
ly, but you can use either of the following cmdlets to make them available quickly:
●● Run the Update-Recipient cmdlet
●● Run either the Update-AddressList or Update-GlobalAddressList cmdlet to force the synchronized
groups to appear; however, these cmdlets will require more cycles on the servers running Exchange
Server.
Synchronized groups from Azure AD to on-premises Active Directory also includes group membership if
the user accounts are created in your Active Directory. User accounts created in Azure AD are not
included. The name attribute of the synchronized groups is filled with the ObjectGUID attribute instead of
a humanly-readable name.
Additional reading. For more information, see the following article on how to enable group writeback
in Azure AD Connect9.

Using Azure Ad Connect Sync Security Groups

During setup, Azure AD Connect automatically creates Azure AD Connect Sync Security Groups. A
Microsoft 365 Enterprise Administrator can use these groups to delegate control in Azure AD Connect to
other users. You can also use these groups to assign a user temporary permission to run a manual
synchronization or to use Azure AD Connect to troubleshoot directory synchronization issues.

Group Name Description

ADSyncAdmins Administrators Group: Members of this group
have Full Access to do anything in the Azure AD
Connect Sync Service Manager.
ADSyncOperators Operators Group: Members of this group have
access to the operations of the Azure AD Connect
Sync Service Manager, including:
●● Execution of Management Agents
●● View of Synchronization Statistics for
each run
●● Ability to save the Run History
(Operations Tab) to a file
Members of this group must be a member of the
ADSyncBrowse Group.
ADSyncBrowse Browse Group: Members of this group have
permission to gather information about a user’s
lineage when resetting passwords.

9 https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx
 MCT USE ONLY. STUDENT USE PROHIBITED
Managing Synchronized Identities  43

ADSyncPasswordSet Password Reset Group: Members of this group

have permission to perform all operations by
using the password management interface.
Members of this group must be a member of the
ADSyncBrowse Group.
The groups are created as local groups on domain-joined servers, or as Active Directory domain groups
when you install Azure AD Connect on a domain controller. If you want to create domain groups on
member servers, you need to select the Specify Custom Sync Groups option during setup and specify
the groups by Domain\Group Name.

Troubleshooting Directory Synchronization

Review Activity - Managing Synchronized Identi-

ties

Let's play a quick game to test your knowledge of managing synchronized identities. Click on the button
below to open this review activity full screen.
MCT USE ONLY. STUDENT USE PROHIBITED 44  Module 2 Planning and Implementing Identity Synchronization

LAUNCH ACTIVITY10

10 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M02_L04_cw_SynchIdentities-
tutorial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Non-Graded Practice Lab 2  45

Non-Graded Practice Lab 2

Non-Graded Practice Lab 2 - Managing Micro-
soft 365 Identities

Non-Graded Practice Lab 2: Managing Microsoft 365 Iden-

tities
To perform the Managing Microsoft 365 Identities practice labs, you must first download the MS100.3x
Student Lab Manual. This manual provides the instructions that are required to complete the exercises for
this practice lab. If you did not download the Microsoft Virtual Machine User Guide and the
MS100.3x Student Lab Manual from the Course Handouts section of the Home page11 during the
Course Introduction, then please do so now.
In this lab, you should only perform Lab 2 in the Student Lab Manual (you should have completed Lab 1
when you finished Module 1). In Lab 2, you will:
●● Set up your organization for identity synchronization
●● Implement Identity Synchronization
Once you are ready, please complete these practice lab exercises by performing the following steps:
1. Download the Microsoft Virtual Machine User Guide from the Course Updates page if you haven't
done so already. Study this guide to learn how to work your way through the virtual lab environment.
2. Download the MS100.3x Student Lab Manual from the Course Updates page if you haven't done so
already. This manual contains the lab instructions that you must follow to complete this practice lab.
3. Click the Launch Lab button below. This will open the Microsoft Labs Online web site and the virtual
machine that is used for this lab.
4. Complete the Lab 2 practice lab by following the steps in the MS100.3x Student Lab Manual.

11 https://openedx.microsoft.com/courses/course-v1:Microsoft+MS-100.3+2018_T3/info
 MCT USE ONLY. STUDENT USE PROHIBITED
Module 3 Planning and Implementing Feder-
ated Identities

Introduction to Federated Identities

Lesson Introduction
Some organizations want authentication to take place in their local Active Directory, and they do not
want to synchronize passwords to Azure AD for security and compliance reasons within the organization.
While this task can be accomplished, it does require a federation with Azure AD.
In this lesson, you will be introduced to Active Directory Federation Services (AD FS). This includes an
overview of AD FS, its functionality, and a comparison of AD FS against password hash synchronization
and Azure AD Connect. Furthermore, you will gain information about claims-based authentication and
federation trusts related to AD FS and single sign-on (SSO) options for Microsoft 365.
After this lesson, you will be able to:
●● Describe claims-based authentication and federation trusts
●● Describe how AD FS works
●● Explain the differences between AD FS and Azure AD Connect password hash synchronization
●● Identify single-sign on (SSO) options for Microsoft 365
●● Understand the authentication flows with AD FS

Claims-Based Authentication and Federated

Trusts
The underlying principles behind AD FS and Single Sign-On (SSO) are the use of claims-based authenti-
cation and federated trusts to establish a mechanism by which one environment, for example your
on-premises Active Directory, can securely transmit a token of authentication to another environment,
such as Microsoft Azure Active Directory.
MCT USE ONLY. STUDENT USE PROHIBITED 48  Module 3 Planning and Implementing Federated Identities

Let’s examine Claims-based authentication and Federated Trusts for a more in-depth understanding of
how these principles provide the basis for AD FS and SSO.

Claims-based authentication
When you consider identities such as Integrated Windows authentication, Kerberos authentication, or NT
LAN Manager (NTLM), you most likely think about Microsoft Windows user accounts and groups. When
you regard identities in Active Server Pages (ASP), such as the ASP.NET membership and roles provider,
you probably think about user names, passwords, and roles. When you determine what the different
authentication mechanisms have in common, you can abstract the individual elements of identity and
access control into two parts:
●● a single, general notion of claims
●● the concept of an issuer or an authority
A claim is a statement that one subject makes about itself or another subject. For example, the statement
can be about a name, identity, key, group, privilege, or capability. Claims are issued by a provider, are
given one or more values, and then packaged in security tokens that are issued by an issuer, commonly
known as a security token service (STS). You can think of a security token as an envelope that contains
claims about a user.

Thinking in terms of claims and issuers is a powerful abstraction that supports several unique ways of
securing your applications. Because claims involve an explicit trust relationship with an issuer, your
application trusts a claim about the current user only if it trusts the entity that issued the claim. Trust is
explicit in the claims-based approach—not implicit as in other authentication and authorization ap-
proaches with which you might be familiar. The following table shows the relationships between security
tokens, claims, and issuers.

Security token Claims Issuer

Windows token (e.g., a security Username and groups Active Directory
identifier, or SID)
 MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Federated Identities  49

Security token Claims Issuer

Username token Username Application, like a browser-based
access to a shared external
SharePoint Online document
library.
Certificate A certificate thumbprint, a Certification authorities (for
subject, or a distinguished name. example, the root authority, and
all authorities in the chain to the
root)

The claims-based approach to identity makes it easier for users to sign in using Kerberos authentication
where it makes sense. However, it is just as easy for users to use one or more (perhaps more Inter-
net-friendly) authentication techniques without you having to recode, recompile, or even reconfigure
your applications. You can support almost any authentication method. Some of the more popular
authentication techniques are Kerberos authentication, forms authentication, X.509 certificates, smart
cards, and other information-type cards.

Here are a few situations in which claims-based identity might be the right choice for you.
●● You have web-facing applications that are used by people who do not have accounts in your Active
Directory domain.
●● Your company has merged with another company and you are having trouble authenticating across
two AD DS forests that do not have a trust relationship.
●● You have an application that needs to send email to the authenticating user or an email to their
manager.
Claims-based identity allows you to factor out the authentication logic from individual applications.
Instead of the application determining who the user is, it receives claims that identify the user. Not all
applications support claims, especially older applications. The support for claims-based authentication is
not solely with AD FS, but also with the application to consume the claim.

Federated trusts
At this point, you have learned about claims-based identity where the issuer directly authenticates users
to a claims-based application. However, you can take this one step further. You can expand your issuer’s
capabilities to accept a security token from another issuer, instead of requiring the user to authenticate
directly. Your issuer would issue security tokens and accept security tokens from other issuers that it
trusts. This enables you to federate identity with other realms, which are separate security domains. In
other words, a federation trust is the embodiment of a business-level agreement of partnership between
two organizations.

Benefits of federated trusts

Maintaining an identity database for users can require a lot of support. Imagine the complexity of doing
this for hundreds or even thousands of remote users. Users might forget their passwords on a regular
basis, and your company’s security policies might not allow you to email forgotten passwords to them.
The federated partner’s Identity Provider (IdP) - that is, Azure Active Directory and Active Directory
Federation Services - sends claims that reflect its users’ identity, groups, and attribute data. Therefore,
your organization no longer needs to revoke, change, or reset the credentials for the partner’s users,
MCT USE ONLY. STUDENT USE PROHIBITED 50  Module 3 Planning and Implementing Federated Identities

since the credentials are managed by the partner organization. You reconfigure one issuer and many
downstream applications become accessible to many new users. Additionally, if a partnership needs to be
terminated, it can be performed with a single trust policy change. Without AD FS, individual accounts for
each partner user would need to be deactivated.
Another feature of claims-based identity is that it enables you to decentralize authentication. Instead of
having your issuer authenticate remote users directly, you can set up a trust relationship with an issuer
from a separate company. Therefore, they would continue using the same SSO mechanism they have
always used in their company. In addition, your application still works because it continues to receive the
same security token it needs.

How federated identity works

Federating identity across realms is like the previous authentication techniques, with the addition of an
initial handshake in the partner’s realm.
You can establish a federation trust relationship between two partner organizations when both organiza-
tions deploy at least one AD FS federation server. The one-way arrow in the following diagram signifies
the direction of the trust, which – like the direction of Windows trusts – always points to the account side
of the forest. This means that authentication flows from the account partner organization to the resource
partner organization.
Federation trusts do not require a constantly connected secure channel between two or more domains to
function because no direct communication occurs over the network between the account Federation
Service and the resource Federation Service when you establish the federation trust.
This is depicted in the following diagram, where:
●● On the user account side, the Account organization’s federation server authenticates the user as
normal using AD DS and then issues a token containing multiple claims about the user.
●● On the resource side, the Resource organization’s federation server validates the token that was
issued by the Account federation server. If the token is validated, the Resource federation server issues
another token for its local servers to accept the claimed identity.
Through this process, the Resource organization can allow a user from another domain to access its
resources or applications without requiring the user to authenticate directly to the Resource domain;
therefore, the two organizations do not have to share a database of user identities or passwords.

In summary, because of the federation trust, an application in the resource organization only accepts
security tokens that are signed by an issuer the resource federation server trusts. Remote users cannot
receive access if they try to send a token from their local issuer directly to the resource application.
 MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Federated Identities  51

Additional reading. For more information, see the following article on Understanding Federation
Trusts1.

Overview of AD FS
Active Directory Federation Services (AD FS) provides the infrastructure that enables your users to
authenticate to multiple, related Web applications over the life of a single online session. With Microsoft
365 and Azure AD Connect installed, AD FS enables users to authenticate through their well-known
on-premises credentials in Active Directory, and then use an account in Microsoft 365 without requiring
any further authentication prompts, which is known as single-sign on (SSO).
When you implement AD FS, all password management and password policies are maintained by your
on-premises Active Directory Domain Services.

How Active Directory Federation Services works

AD FS is an example of a Security Token Service (STS). AD FS works seamlessly with Active Directory to
create tokens containing claims about users in an on-premises directory service and send those tokens
securely to a relying party. This process of token exchange enables the user to log on to a Microsoft
Azure resource using his or her Active Directory credentials.
Upon deployment of AD FS, an implicit claims provider trust is enabled for the Active Directory domain in
which the AD FS server resides.
The process of authenticating a user through AD FS is outlined in the following steps and displayed in the
following graphic:
1. A user wants to access a claim-aware application, such as Outlook web app or the Office 365 user
portal, in a browser like Microsoft Edge.
2. The application needs authentication and derives the supported authentication methods from its
configuration. If a federated-based authentication method is configured, the claim-aware application
redirects the user to authenticate against the federation service.
3. The Federation Service cannot authenticate user on its own; moreover, it uses one of the authentica-
tion providers. For Active Directory Federation Service this is your Active Directory by default, but it
can be any supported AD FS Identity Provider (IdP). Once the client is redirected to the Federation
Service, the AD FS server asks the client for authentication, usually by using form-based authentica-
tion.
4. The client requests the Kerberos session ticket from Active Directory and presents the ticket to AD FS.
Then, the STS component of AD FS issues a security token.
5. The security token is provided back to the user.
6. The user uses the recent issued security token to access resources, such as SharePoint Online, from
the claim-aware application. On the resource side, the server validates the token and issues an
authentication token to accept the claimed identity. This token is valid until a specified lifetime and, if
used frequently, the security token will be kept active by the refresh token.

1 https://technet.microsoft.com/en-us/library/cc770993(v=ws.11).aspx
MCT USE ONLY. STUDENT USE PROHIBITED 52  Module 3 Planning and Implementing Federated Identities

The security token contains claims about the user, such as user name, group membership, user principal
name (UPN), email address, manager details, and phone number. The configuration of the federation
trust decides how to use these claims and how to make appropriate authorization decisions. The applica-
tion does not make authentication decisions, as these are made by your local Active Directory.
The trust between the parties is managed through certificates. While the certificates used for security
token signing and encryption can be self-signed by the AD FS server, typically HTTPS communications
between the issuer and the consuming application or service requires a public key infrastructure (PKI). A
primary example of this is AD FS as the issuer and Office 365 as the consuming application or service.

AD FS and Windows Server 2016

AD FS, which is included in Windows Server 2016, includes options for sign on without passwords
(including multi-factor authentication), thus enabling organizations to get more new and secure authenti-
cation methods. The following list identifies some improvements which were introduced to AD FS in
Windows Server 2016 compared to previous Windows Server versions:
●● Enable sign on with non-AD LDAP directories.
●● You can now not only customize the messages, but images, logo and web theme per application.
Additionally, you can create new, custom web themes and apply these per relying party.
●● Auditing has become more streamlined and less verbose.
●● You can send password expiry claims to the relying party trusts, like Microsoft 365 to Exchange and
Outlook, to notify federated users of their soon-to-be-expired passwords.
●● The upgrade AD FS from Windows Server 2012 R2 to Windows Server 2016 is easier.
 MCT USE ONLY. STUDENT USE PROHIBITED
Introduction to Federated Identities  53

ADFS vs Azure AD Connect Password Hash Syn-

chronization

SSO Options for Microsoft 365

Understanding the Authentication Flows with

AD FS
MCT USE ONLY. STUDENT USE PROHIBITED 54  Module 3 Planning and Implementing Federated Identities

Review Activity - Federated Identities

Let's play a quick game to test your knowledge of federated identities. Click on the button below to open
this review activity full screen.
LAUNCH ACTIVITY2

2 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M03_L01_match_FedIdentiti-
estutorial.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Planning an AD FS Deployment  55

Planning an AD FS Deployment
Lesson Introduction
Since Active Directory Federation Services (AD FS) requires some detailed configuration settings, network
connections, and server hardware, it is important that you plan the implementation carefully.
In this lesson, you will learn the key questions you need to ask to plan a successful AD FS implementation
for your organization.
After this lesson, you will be able to:
●● Plan an AD FS environment including best practices, high availability, and capacity planning.
●● Plan Active Directory Federation Services in Microsoft Azure
●● Identify requirements for an AD FS deployment.

Planning an AD FS deployment

Planning ADFS in Microsoft Azure

MCT USE ONLY. STUDENT USE PROHIBITED 56  Module 3 Planning and Implementing Federated Identities

ADFS Requirements

Review Activity - Planning an AD FS Deployment

Let's play a quick game to test your knowledge of planning an AD FS deployment. Click on the button
below to open this review activity full screen.
LAUNCH ACTIVITY3

3 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M03_L02_fill_PlanADFStutorial.
html
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing AD FS  57

Implementing AD FS
Lesson Introduction
As an administrator in your organization, you need to manage federation services as well as identity
management. This includes properly installing and configuring the AD FS environment.
In this lesson, you will examine various administrative tasks that must be performed to successfully
deploy AD FS, including installing and configuring AD FS, Web Application Proxy (WAP) for AD FS, and
Azure AD Connect for Microsoft 365. Additionally, it is important that you know how to troubleshoot
your AD FS environment.
After this lesson, you will be able to:
●● Install and configure an AD FS environment
●● Install and configure a Web Application Proxy for AD FS
●● Configure AD FS by using Azure AD Connect
●● Switch between federated authentication and password sync
●● Troubleshoot your AD FS environment

Installing and Configuring AD FS

Installing and Configuring Web Application

Proxy for AD FS
Web Application Proxy (WAP) provides reverse proxy functionality for web applications to allow users on
any device to access them from outside the corporate network. Web Application Proxy pre-authenticates
access to web applications using Active Directory Federation Services (AD FS), and it functions as an AD
FS proxy.
Note: Web Application Proxy can also use pass-through authentication (PTA), but a WAP should not be
mixed with PTA in Azure AD.
In general, proxy servers are used to configure extranet access by redirecting client authentication
requests coming from outside your corporate network to the federation server farm. If an organization
does not want to use Microsoft’s Web Application Proxy, it can instead use a third-party proxy along with
AD FS; however, the provider must ensure that it supports the MS-ADFSPIP protocol used by AD FS.
The Web Application Proxy is a service added in Windows Server 2012 R2 and replaces the old AD FS
proxy servers. These servers should be deployed in a perimeter network and are usually not domain
joined, except you must have an Active Directory domain in your network perimeter.
MCT USE ONLY. STUDENT USE PROHIBITED 58  Module 3 Planning and Implementing Federated Identities

Installing Web Application Proxy

In Windows Server 2016, WAP is installed from the Server Manager as a role service, using the same
Server Manager Configuration wizard pages that were used to install AD FS servers. The Server Manger
Configuration Wizard performs validation checks and automatically installs all the services required by
WAP. The WAP role includes Windows PowerShell cmdlets that can be used to perform a Windows
PowerShell-based deployment of WAP servers using the following steps:
1. To install the WAP role, use the Add Roles and Features Wizard in Server Manager, and then select
Remote Access role.
2. On the Select role services page, choose Web Application Proxy and agree with the other feature
required for WAP, including the Remote Access Management Console by confirming Add Features.
3. Click Next and then Install to install WAP with all requirements.
Alternatively, you can install the WAP role service with the Install-WindowsFeature Web-Applica-
tion-Proxy Windows PowerShell cmdlet.

Configuring Web Application Proxy

After the Web Application Proxy role service is installed, launch the Remote Access Management Console
to configure Web Application Proxy for publishing AD FS. You can initiate the Remote Access Manage-
ment Console from the Tools menu in Server Manager or from the Start screen.
Verify in the wizard that the correct federation service name is displayed, such as sts.adatum.com. You can
test the connection in the wizard screen to verify that a connection to the Federation Service can be
established. Keep in mind that you must enter the credentials for the AD FS service account to establish a
trust between this WAP role service and the Federation Service. By default, only the service account used
by the Federation Service or a member of the local BUILTIN\Administrators group can authorize a WAP.
You can use other products as a replacement for a WAP role service; for example, a non-Microsoft
product proxy. The next lesson will cover more details about WAP and other third-party proxy products.
Alternatively, you can use the Windows PowerShell cmdlet Install-WebApplicationProxy to configure
Web Application Proxy for publishing AD FS.

Configuring AD FS by using Azure AD Connect

AD FS with Azure AD Connect allows your users to single sign-on to Microsoft cloud services, such as
Microsoft 365, with their on-premises credentials. Prior to Azure AD Connect, you were required to
deploy AD FS and directory synchronization separately. Although the recommended order of deployment
is well documented—for example, that AD FS should be deployed prior to directory synchronization—or-
ganizations still ran into deployment issues because of poor planning.
To mitigate some of the issues during deployment, Azure AD Connect employs strategic questions to
provide an easier deployment experience for synchronization and for sign-in. While you can choose to
deploy the tools separately, you also can use a customized part of Azure AD Connect to set up an
on-premises AD FS infrastructure. This customized installation is designed to address complex deploy-
ments that include such things as smart card authentication or non-Microsoft MFA techniques which
cannot be covered by Azure AD Connect Password Hash Synchronization and Azure AD Connect Pass-
Through Authentication.
It is recommended that you use Azure AD Connect to install and configure sign-in options to Microsoft
365. Azure AD Connect is the best choice for every organization today, regardless of complexity and
identity landscape.
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing AD FS  59

Configuring Active Directory Federation Services by using

Azure Active Directory Connect
The installation of Azure AD Connect with all prerequisites is a straight-forward process.
1. On the Welcome screen, agree to the license terms and privacy notice and click Continue.
2. It is very important that you choose the Customize button on the Express Settings page. With
Express Settings, only password hash synchronization is available. If you want to change to the custom
configuration, you must re-install Azure AD Connect.
3. You can choose some optional settings, such as installation path, and you can use an existing service
account on the Install required components page.
4. Click Install and the installation with all prerequisites will begin.
5. After installation, the User sign-in page is displayed. Choose the Federation with AD FS radio button
and the screen displays the prerequisites for your AD FS deployment at the bottom of the page.
6. Click Next.

The Azure AD Connect wizard guides you through the next steps for directory synchronization, which you
already covered in the prior module. We will skip these steps in this topic.
Back at the Azure AD Connect Configuration for Federation Services, you can see the AD FS farm screen
in the wizard. You should then perform the following steps:
1. Choose between Configure a new AD FS farm and Use an existing AD FS farm. if this is your first
AD FS farm, select Configure a new AD FS farm. If you choose Use an existing AD FS farm, you are
taken directly to the Configuring the trust relationship between AD FS and Azure AD page.
MCT USE ONLY. STUDENT USE PROHIBITED 60  Module 3 Planning and Implementing Federated Identities

2. Specify your SSL certificate to secure the communication between clients and AD FS. To do this, there
are two options available:
●● Provide a password-protected PFX certificate file. Choose this option if Azure AD Connect
should store the PFX file locally. Ensure that a strong password has been used to protect the
certificate.
●● Use a certificate installed on the federation servers. Select this option if your SSL certificate
with the private key is present on each AD FS and AD FS proxy server selected for configuration.
3. If password authentication is not a strong enough security measure for your organization, you should
consider the second option (use a certificate installed on the federation servers) for your productive
AD FS deployment.
4. At the AD FS servers screen, type a server name or IP address to add your AD FS servers to your
configuration.
5. The next page lets you add the Web Application Proxy servers. Proceed as in the last step and select
your WAP servers.
6. Enter your Domain Administrator credentials to enable Azure AD Connect to perform the configu-
ration of federation services, such as adding a SPN record, and other configurations.
7. In the AD FS service account step, you have three options that control how to configure the AD FS
service account:
●● Create a group Managed Service Account. Specify your enterprise admin credentials to create
the necessary KDS root key.
●● Use an existing group Managed Service Account. Type in your existing gMSA account name,
such as ADATUM\adfs_gmsa$.
●● Use a domain user account. Type in your existing domain user account and password.
8. Select your Azure AD Domain to federate with your on-premises directory from the drop-down
menu. Azure AD Connect provides you with the necessary information to verify an unverified domain.
This step is required to ensure that your organization owns the custom domain name. Sign in to your
domain name registrar to update the DNS zone file for the domain by adding the DNS entry provided
to you by Azure AD Connect. If you do not have access to update the DNS entry, ask the person or
team who has this access to complete the verification step. The domain will be converted from a
managed domain into a federated domain, and user logons will be disrupted during this operation.
This page only allows you to configure a single domain in the initial installation. You can configure
more domains later by running Azure AD Connect again.
9. Click Next.
10. The Ready to configure wizard displays information about the detailed steps that will be performed
if you click Install.
11. The Installation complete page lets you verify the configuration. For this task, you must create both
intranet and extranet DNS records to resolve your federation service, such as sts.adatum.com. Click
Verify and you can see if your configuration was successful.
Note: Please keep in mind that the previous planning aspects and high availability considerations are the
same, even if you are using Azure AD Connect to install and configure your AD FS farm within your
organization.
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing AD FS  61

Troubleshooting AD FS

Switch Between Federated Authentication and

Password Sync
Deployment is a critical component when an organization deploys AD FS to establish SSO for Microsoft
365, their local Active Directory, as well as AD FS. Because all authentication requests from Microsoft 365,
or more precisely Azure AD, are redirected to AD FS, your locally deployed directory infrastructure must
be available so that you can sign in to cloud services. For example, if a local Internet link is not working,
users cannot sign in to Microsoft 365 from their home computers even though Microsoft 365 services are
available. This is because Microsoft 365, when deployed in a federated scenario, expects your local Active
Directory to authenticate the user.
Since Microsoft 365 requires your local Active Directory to authenticate the user, it is important to have a
highly available AD FS environment. However, you can also use password hash synchronization, a feature
of Azure AD Connect, as a fall back mechanism if your local authentication infrastructure fails. To accom-
plish this, simply configure Azure AD Connect and enable the password hash synchronization option
when prompted during installation and configuration.
If your AD FS environment is not reachable or you have to temporarily switch from AD FS to password
hash synchronization, you should:
1. Re-run the Azure AD Connect Wizard and enable password synchronization again.
2. Then run the following cmdlet in Windows PowerShell:
Set-MsolDomainAuthentication -DomainName <domain> -Authentication Managed`

For example, if you want to switch the domain adatum.com from federated to managed, you should run
the following cmdlet:
Set-MsolDomainAuthentication -DomainName adatum.com -Authentication Managed

Note: The authentication change from federated to managed and vice versa can take up to two hours to
complete; however, once done, your users can login using their on-premises credentials.
After the issues in your AD FS environment are fixed, you can switch back from password hash synchroni-
zation to federation by running the following cmdlet:
Set-MsolDomainAuthentication -DomainName <domain> -Authentication
Federated
MCT USE ONLY. STUDENT USE PROHIBITED 62  Module 3 Planning and Implementing Federated Identities

To permanently switch a domain from federated to managed with password hash synchronization, you
need to convert the domain in Azure AD. This can be done using the following cmdlet on your AD FS
server:
Convert-MsolDomainToStandard -DomainName <domain> ‎-SkipUserConversion
$false -PasswordFile <file> `

‎where:
●● SkipUserConversion $false. Converts your users in Azure AD from federated to managed. Keep in
mind that user conversion can take some time, depending on the number of users.
●● PasswordFile. Specifies the file where converted users’ user names and temporary passwords are
recorded.

Review Activity - Implementing AD FS

Let's play a quick game to test your knowledge of implementing AD FS. Click on the button below to
open this review activity full screen.
LAUNCH ACTIVITY4

4 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M03_L03_flip_ImpADFStutori-
al.html
 MCT USE ONLY. STUDENT USE PROHIBITED
Module 4 Implementing Application and Ex-
ternal Access

Implementing Applications in Azure AD

Lesson Introduction
As the Enterprise Administrator of your organization’s Microsoft 365 environment, you will be responsible
for implementing applications in Azure AD.
In this lesson, you will learn about various administrative tasks, including adding an application, updating
an application, configuring multi-tenant applications, and removing an application.
After this lesson, you will be able to:
●● Add an Application
●● Update an Application
●● Configure Multi-tenant applications
●● Remove an Application

Adding an Application
Enterprise developers and software-as-a-service (SaaS) providers can develop commercial cloud services
or line-of-business applications that can be integrated with Azure Active Directory (Azure AD) to provide
secure sign-in and authorization for their services. To integrate an application or service with Azure AD, a
developer must first register the application with Azure AD.
Note: Sometimes the meaning of the term “application” can be misunderstood when used in the context
of Azure AD. An application that has been integrated with Azure AD has implications that go beyond the
software aspect. "Application" is frequently used as a conceptual term, referring to not only the applica-
tion software, but also its Azure AD registration and its role in authentication/authorization “conversa-
MCT USE ONLY. STUDENT USE PROHIBITED 64  Module 4 Implementing Application and External Access

tions” at runtime. By definition, an application can function in a client1 role (consuming a resource), a
resource server2 role (exposing APIs to clients), or even both.
As previously mentioned, any application that wants to use the capabilities of Azure AD must first be
registered in an Azure AD tenant. This registration process involves giving Azure AD details about your
application, such as the URL where it’s located, the URL to send replies after a user is authenticated, the
URL that identifies the app, and so on.

To register a new application using the Azure portal

1. Sign in to the Azure portal3.
2. If your account gives you access to more than one Azure AD tenant, click your account in the top right
corner and set your portal session to the desired Azure AD tenant.
3. In the left-hand navigation pane, click the Azure Active Directory service, click App registrations,
and then click New application registration.

4.
5. When the Create page appears, enter your application's registration information:
●● Name: Enter a meaningful application name
●● Application type:
●● Select Native for client applications4 that are installed locally on a device. This setting is used
for OAuth public native clients5.
●● Select Web app / API for client applications6 and resource/API applications7 that are
installed on a secure server. This setting is used for OAuth confidential web clients8 and public

1 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
2 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
3 https://portal.azure.com/
4 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
5 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
6 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
7 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
8 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing Applications in Azure AD  65

user-agent-based clients9. The same application can also expose both a client and resource/
API.
●● Sign-On URL: For Web app / API applications, provide the base URL of your app. For example,
http://localhost:31544 might be the URL for a web app running on your local machine. Users
would use this URL to sign in to a web client application.
●● Redirect URL: For Native applications, provide the URL used by Azure AD to return token respons-
es. Enter a value specific to your application, such as http://MyFirstAADApp.

6.
7. Additional reading. For specific examples of web applications and native applications, see the Get
Started section of the Azure Active Directory for developers10 site.
8. When finished, click Create.
After clicking Create, Azure AD assigns a unique Application ID to your application, and you're taken to
your application's main registration page. Depending on whether your application is a web or native
application, different options are provided to add additional capabilities to your application. See the next
section for an overview of consent, and details on enabling additional configuration features in your
application registration (credentials, permissions, enable sign-in for users from other tenants.)

Updating an Application

Configuring Multi-Tenant applications

When registering an application in Azure AD, you may want your application to be accessed only by users
in your organization. Alternatively, you may also want your application to be accessible by users in
external organizations. These two application types are called single-tenant and multi-tenant applica-

9 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary
10 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-developers-guide
MCT USE ONLY. STUDENT USE PROHIBITED 66  Module 4 Implementing Application and External Access

tions. This section discusses how to modify the configuration of a single-tenant application to make it a
multi-tenant application.
It’s important to note the differences between a single-tenant and multi-tenant application:
●● A single-tenant application is intended for use in one organization. It's typically a line-of-business
(LoB) application written by an enterprise developer. A single-tenant application can only be accessed
by users with accounts in the same tenant as the application registration. As a result, it only needs to
be provisioned in one directory.
●● A multi-tenant application is intended for use in many organizations. Referred to as a software-
as-a-service (SaaS) web application, it's typically written by an independent software vendor (ISV).
Multi-tenant applications must be provisioned in each tenant where users need access. For tenants
other than the one where the application is registered, user or administrator consent is required to
register them. Note that native client applications are multi-tenant by default as they are installed on
the resource owner's device.
Making an application multi-tenant requires both application registration changes, as well as changes to
the web application itself. This information is covered in the following sections.

Changing the application registration to support mul-

ti-tenant
If you are writing an application that you want to make available to your customers or partners outside of
your organization, you need to update the application definition in the Azure portal.
Azure AD requires the App ID URL of multi-tenant applications to be globally unique. The App ID URL is
one of the ways an application is identified in protocol messages. For a single tenant application, it is
enough for the App ID URL to be unique within that tenant. For a multi-tenant application, it must be
globally unique so that Azure AD can find the application across all tenants. Global uniqueness is en-
forced by requiring the App ID URL to have a host name that matches a verified domain of the Azure AD
tenant. For example:
●● If the name of your tenant is contoso.onmicrosoft.com, then a valid App ID URL would be https://
contoso.onmicrosoft.com/myapp.
●● If your tenant has a verified domain of contoso.com, then a valid App ID URL would be https://
contoso.com/myapp.
If the App ID URL doesn’t follow this pattern, setting an application as multi-tenant fails.
To give external users the ability to access your application:
1. Sign in to the Azure portal11.
2. If your account gives you access to more than one Azure AD tenant, click your account in the top right
corner, and set your portal session to the desired Azure AD tenant.
3. In the left-hand navigation pane, click the Azure Active Directory service, click App registrations,
then find/click the application you want to configure. You are taken to the application's main registra-
tion page, which opens up the Settings page for the application.
4. From the Settings page, click Properties and change the Multi-tenanted switch to Yes.
After you have made the changes, users and administrators in other organizations are able to grant their
users the ability to sign in to your application, allowing your application to access resources secured by
their tenant.

11 https://portal.azure.com/
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing Applications in Azure AD  67

Supporting Multi-Tenant Applications with the Consent

Framework
Support for multi-tenant applications relies heavily on the Azure AD consent framework. Consent is the
mechanism that allows a user from another tenant to grant the application access to resources secured
by the user's tenant. This experience is referred to as “user consent.”
Your web application may also offer:
●● The ability for administrators to "sign up my company." This experience, referred to as “admin
consent”, gives an administrator the ability to grant consent on behalf all users in their organization.
Only a user that authenticates with an account that belongs to the Global Admin role can provide
admin consent; any other user who attempts to do this will receive an error.
●● A sign-up experience for users. It is expected that the user is provided a “sign-up” button that
redirects the browser to the Azure AD OAuth2.0 /authorize endpoint or an OpenID Connect /
userinfo endpoint. These endpoints allow the application to get information about the new user by
inspecting the id_token. Following the sign-up phase the user is presented with a consent prompt,
similar to the one shown in the Overview of the consent framework12 section.
Additional reading. For more information on the application changes required to support multi-tenant-
ed access and sign-in/sign-up experiences, see the following:
●● How to sign in any Azure Active Directory (AD) user using the multi-tenant application pat-
tern13
●● Multi-tenant code samples list14
●● Quickstart: Add company branding to your sign-in page in Azure AD15

Removing an Application
Now that we’ve examined how to register an application in Azure AD, let’s look at the flip-side and see
how to remove an application's registration from your Azure AD tenant.
Applications that your organization has registered appear under the My apps filter on your tenant's main
App registrations page. These applications are ones you registered manually through the Azure portal, or
programmatically through PowerShell or the Graph API. More specifically, they are represented by both
an Application and Service Principal object in your tenant.
Additional reading. For more information, see Application Objects and Service Principal Objects16.
Let’s take a moment now and see how to remove both single-tenant and multi-tenant applications.

To remove a single-tenant application from your directory

1. Sign in to the Azure portal17.
2. If your account gives you access to more than one Azure AD tenant, click your account in the top right
corner and set your portal session to the desired Azure AD tenant.

12 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications
13 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview
14 https://azure.microsoft.com/documentation/samples/?service=active-directory&term=multi-tenant
15 https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding
16 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-objects
17 https://portal.azure.com/
MCT USE ONLY. STUDENT USE PROHIBITED 68  Module 4 Implementing Application and External Access

3. In the left-hand navigation pane, click the Azure Active Directory service, click App registrations,
then find/click the application you want to configure. You are taken to the application's main registra-
tion page, which opens up the Settings page for the application.
4. From the application's main registration page, click Delete.
5. Click Yes in the confirmation message.

To remove a multi-tenant application from its home directo-

ry
1. Sign in to the Azure portal18.
2. If your account gives you access to more than one Azure AD tenant, click your account in the top right
corner and set your portal session to the desired Azure AD tenant.
3. In the left-hand navigation pane, click the Azure Active Directory service, click App registrations,
then find/click the application you want to configure. You are taken to the application's main registra-
tion page, which opens up the Settings page for the application.
4. From the Settings page, choose Properties and change the Multi-tenanted switch to No (to first
change your application to single-tenant), and then click Save. The application's service principal
objects remain in the tenants of all organizations that have already consented to it.
5. Click on the Delete button from the application's main registration page.
6. Click Yes in the confirmation message.

Removing a multi-tenant application authorized by anoth-

er organization
A subset of the applications that appear under the All apps filter (excluding the My apps registrations)
on your tenant's main App registrations page are multi-tenant applications.
In technical terms, these multi-tenant applications are from another tenant, and were registered into your
tenant during the consent process. More specifically, they are represented by only a service principal
object in your tenant, with no corresponding application object.
To remove a multi-tenant application’s access to your directory (after having granted consent), the
company administrator must remove its service principal. The administrator must have global admin
access and can remove it through the Azure portal or use the Azure AD PowerShell Cmdlets19.
Additional reading. For more information on the differences between application and service principal
objects, see Application and service principal objects in Azure AD20.

18 https://portal.azure.com/
19 http://go.microsoft.com/fwlink/?LinkId=294151
20 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-objects
 MCT USE ONLY. STUDENT USE PROHIBITED
Implementing Applications in Azure AD  69

Review Activity - Implementing Applications in

Azure AD

Let's play a quick game to test your knowledge of implementing applications in Azure AD. Click on the
button below to open this review activity full screen.
LAUNCH ACTIVITY21

21 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M04_L01_flash_ImplAppstuto-
rial.html
MCT USE ONLY. STUDENT USE PROHIBITED 70  Module 4 Implementing Application and External Access

Configuring Azure AD Application Proxy

Lesson Introduction
As the Enterprise Administrator of your organization’s Microsoft 365 environment, you will be responsible
for configuring Azure AD Application Proxy.
In this lesson, you will examine Azure AD Application Proxy and Connectors, including the Azure AD
Application Proxy Prerequisites, how to install and register a Connector, and how to publish an on-prem-
ises app for remote access.
After this lesson, you will be able to:
●● Explain Azure AD Application Proxy
●● Identify Azure AD Application Proxy Prerequisites
●● Install and Register a Connector
●● Publish an On-Premises App for Remote Access

Overview of an Azure AD Application Proxy

Azure AD Application Proxy Prerequisites

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

22 https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis
23 https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-single-sign-on-with-kcd
24 https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-connectors-with-proxy-servers
 MCT USE ONLY. STUDENT USE PROHIBITED
Configuring Azure AD Application Proxy  71

Open your ports

To prepare your environment for Azure AD Application Proxy, you first need to enable communication to
Azure data centers. If there is a firewall in the path, make sure that it's open so that the Connector can
make HTTPS (TCP) requests to the Application Proxy.
1. Open the following ports to outbound traffic:
●● Port 80. It’s used for downloading certificate revocation lists (CRLs) while validating the SSL
certificate.
●● Port 443. It’s used for all outbound communication with the Application Proxy service.
2. If your firewall enforces traffic according to originating users, open these ports for traffic from
Windows services that run as a Network Service.
3. These two ports reflect the port requirements for connector versions 1.5.132.0 and newer. If you still
have an older connector version, you must enable the following ports in addition to 80 and 443:
●● 5671
●● 8080
●● 9090-9091
●● 9350
●● 9352
●● 10100–10120
4. For information about updating your connectors to the newest version, see Understand Azure AD
Application Proxy connectors25.
5. If your firewall or proxy allows DNS whitelisting, you can whitelist connections to msappproxy.net and
servicebus.windows.net. If not, you need to allow access to the Azure DataCenter IP ranges26, which
are updated each week.
6. Microsoft uses four addresses to verify certificates. Allow access to the following URLs if you haven't
done so for other products:
●● mscrl.microsoft.com:80
●● crl.microsoft.com:80
●● ocsp.msocsp.com:80
●● www.microsoft.com:80
7. Your connector needs access to login.windows.net and login.microsoftonline.com for the registra-
tion process.

25 https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-connectors
26 https://www.microsoft.com/download/details.aspx?id=41653
MCT USE ONLY. STUDENT USE PROHIBITED 72  Module 4 Implementing Application and External Access

Installing and Registering a Connector

Publishing an On-Premises App for Remote Ac-

cess

Review Activity - Configuring Azure AD App

Proxy
 MCT USE ONLY. STUDENT USE PROHIBITED
Configuring Azure AD Application Proxy  73

Let's play a quick game to test your knowledge of configuring Azure AD App Proxy. Click on the button
below to open this review activity full screen.
LAUNCH ACTIVITY27

27 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M04_L02_tile_AppProxytutori-
al.html
MCT USE ONLY. STUDENT USE PROHIBITED 74  Module 4 Implementing Application and External Access

Designing Solutions for External Access

Lesson Introduction
As the Enterprise Administrator of your organization’s Microsoft 365 environment, you will be responsible
for designing solutions for external access.
In this lesson, you will learn about various administrative tasks, including managing External Access,
licensing guidance for Azure AD Business to Business (B2B) collaboration, creating a collaborative user,
and troubleshooting your B2B collaboration.
After this lesson, you will be able to:
●● Manage External Access
●● Explain Licensing Guidance for Azure AD B2B Collaboration
●● Create a Collaborative User
●● Troubleshoot your B2B Collaboration

Manage External Access

Azure Active Directory (Azure AD) business-to-business (B2B) collaboration capabilities enable any
organization using Azure AD to work safely and securely with users from any other organization, small or
large. Those organizations can be with or without Azure AD, and don't even need to have an IT depart-
ment. Organizations using Azure AD can provide access to documents, resources, and applications to
their partners, while maintaining complete control over their own corporate data.
External sharing in Microsoft 365 (OneDrive, SharePoint Online, Unified Groups, and so on) and Azure
Active Directory B2B collaboration are technically the same thing. All external sharing (except OneDrive/
SharePoint Online), including guests in Microsoft 365 Groups, already uses the Azure AD B2B collabora-
tion invitation APIs for sharing. Organizations using Azure AD can provide access to documents, resourc-
es, and applications to their partners, while maintaining complete control over their own corporate data.
Developers can use the Azure AD business-to-business APIs to write applications that bring two organi-
zations together more securely.

Differences between OneDrive for Business/SharePoint

Online and Azure AD B2B Collaboration
OneDrive for Business/SharePoint Online has a separate invitation manager. Support for external sharing
in OneDrive for Business/SharePoint Online started before Azure AD developed its support. Over time,
OneDrive for Business/SharePoint Online external sharing has accrued several features and many millions
of users who use the product's in-built sharing pattern.
That being said, there are some subtle differences in how external sharing works in OneDrive for Busi-
ness/SharePoint Online and Azure AD B2B collaboration, including:
●● OneDrive/SharePoint Online adds users to the directory after users have redeemed their invitations.
So, before redemption, you don't see the user in the Azure AD portal. In the meantime, if another site
invites a user, a new invitation is generated. However, when you use Azure AD B2B collaboration,
users are added immediately on invitation so that they show up everywhere.
●● The redemption experience in OneDrive/SharePoint Online looks different from the experience in
Azure AD B2B collaboration; however, after a user redeems an invitation, the experiences look alike.
 MCT USE ONLY. STUDENT USE PROHIBITED
Designing Solutions for External Access  75

●● Azure AD B2B collaboration-invited users can be picked from OneDrive/SharePoint Online sharing
dialog boxes. OneDrive/SharePoint Online-invited users also show up in Azure AD after they redeem
their invitations.
●● To manage external sharing in OneDrive/SharePoint Online with Azure AD B2B collaboration, set the
OneDrive/SharePoint Online external sharing setting to Only allow sharing with external users
already in the directory. Users can go to externally shared sites and pick from external collaborators
that the admin has added. The admin can add the external collaborators through the B2B collabora-
tion invitation APIs.

●●

Licensing Guidance for Azure AD B2B Collabora-

tion
You can use Azure AD B2B collaboration capabilities to invite guest users into your Azure AD tenant to
allow them to access Azure AD services and other resources in your organization. If you want to provide
MCT USE ONLY. STUDENT USE PROHIBITED 76  Module 4 Implementing Application and External Access

access to paid Azure AD features, B2B collaboration guest users must be licensed with appropriate Azure
AD licenses.
Specifically:
●● Azure AD Free capabilities are available for guest users without additional licensing.
●● If you want to provide B2B users with access to paid Azure AD features, you must have enough
licenses to support those B2B guest users.
●● An inviting tenant with an Azure AD paid license has B2B collaboration use rights to an additional five
B2B guest users invited to the tenant.
The customer who owns the inviting tenant must be the one to determine how many B2B collaboration
users need paid Azure AD capabilities. Depending on the paid Azure AD features you want for your guest
users, you must have enough Azure AD paid licenses to cover B2B collaboration users in the same 5:1
ratio.
A B2B collaboration guest user is added as a user from a partner company, not an employee of your
organization or an employee of a different business in your conglomerate. A B2B guest user can sign in
with external credentials or credentials owned by your organization.
In other words, B2B licensing is set not by how the user authenticates, but rather by the relationship of
the user to your organization. If these users are not partners, they are treated differently in licensing
terms. They are not considered to be a B2B collaboration user for licensing purposes even if their User-
Type is marked as “Guest.” They should be licensed normally, at one license per user. These users include:
●● Your employees
●● Staff who sign in using external identities
●● An employee of a different business in your conglomerate

Licensing examples

Example #1
A customer wants to invite 100 B2B collaboration users to its Azure AD tenant. The customer assigns
access management and provisioning for all users, but 50 users also require multi-factor authentication
(MFA) and conditional access. This customer must purchase 10 Azure AD Basic licenses and 10 Azure AD
Premium P1 licenses to cover these B2B users correctly. If the customer plans to use Identity Protection
features with B2B users, they must have Azure AD Premium P2 licenses to cover the invited users in the
same 5:1 ratio.

Example #2
A customer has 10 employees who are all currently licensed with Azure AD Premium P1. They now want
to invite 60 B2B users who all require MFA. Under the 5:1 licensing rule, the customer must have at least
12 Azure AD Premium P1 licenses to cover all 60 B2B collaboration users. Because they already have 10
Premium P1 licenses for their 10 employees, they have rights to invite 50 B2B users with Premium P1
features like MFA. In this example, they must then purchase 2 additional Premium P1 licenses to cover the
remaining 10 B2B collaboration users.
The customer who owns the inviting tenant must be the one to determine how many B2B collaboration
users need paid Azure AD capabilities. Depending on which paid Azure AD features you want for your
 MCT USE ONLY. STUDENT USE PROHIBITED
Designing Solutions for External Access  77

guest users, you must have enough Azure AD paid licenses to cover B2B collaboration users in the 5:1
ratio.

Additional licensing details

Additional licensing guidelines that organizations should consider include:
●● There is no need to assign licenses to B2B user accounts. Based on the 5:1 ratio, licensing is automati-
cally calculated and reported.
●● If no paid Azure AD license exists in the tenant, every invited user gets the rights that the Azure AD
Free edition offers.
●● If a B2B collaboration user already has a paid Azure AD license from their organization, they do not
consume one of the B2B collaboration licenses of the inviting tenant.

Current Limitations
Azure Active Directory B2B collaboration is currently subject to the following limitations:
●● Possible double multi-factor authentication. With Azure AD B2B, you can enforce multi-factor
authentication at the resource organization (the inviting organization). The reasons for this approach
are detailed in Conditional access for B2B collaboration users28. If a partner already has multi-factor
authentication set up and enforced, their users might have to perform the authentication once in their
home organization and then again in yours.
●● Instant-on. In the B2B collaboration flows, users are added to the directory and dynamically update
them during invitation redemption, app assignment, and so on. The updates and writes ordinarily
happen in one directory instance and must be replicated across all instances. Replication is completed
once all instances are updated. Sometimes when the object is written or updated in one instance and
the call to retrieve this object is to another instance, replication latencies can occur. If that happens,
click refresh or retry to help. If you are writing an app using Microsoft’s API, then retries with some
back-off is a good, defensive practice to alleviate this issue.

Creating a Collaborative User

28 https://docs.microsoft.com/en-us/azure/active-directory/b2b/conditional-access
MCT USE ONLY. STUDENT USE PROHIBITED 78  Module 4 Implementing Application and External Access

Troubleshooting your B2B Collaboration

The following is a list of some common issues that organizations experience with Azure Active Directory
(Azure AD) B2B collaboration, including suggested remedies:
●● You added some external users but do not see them in your Global Address Book or in the people
picker. In cases where external users are not populated in the list, the object might take a few minutes
to replicate.
●● A B2B guest user is not showing up in SharePoint Online/OneDrive people picker. The ability to search
for existing guest users in the SharePoint Online (SPO) people picker is turned OFF by default to
match legacy behavior. You can enable this feature by using the setting ShowPeoplePickerSugges-
tionsForGuestUsers at the tenant and site collection level. You can set the feature using the Set-SPO-
Tenant and Set-SPOSite cmdlets, which allow members to search all existing guest users in the
directory. Changes in the tenant scope do not affect already provisioned SPO sites.
●● Invitations have been disabled for your directory, but you have not been notified that you no longer
have permissions to invite users. To correct this, verify that your user account is authorized to invite
external users under User Settings:

●●
●● If you have recently modified these settings or assigned the Guest Inviter role to a user, there might
be a 15 to 60 minute delay before the changes take effect.
●● One of the external users that you invited is receiving an error during redemption. Common errors
include:
●● Invitee’s Admin has disallowed EmailVerified Users from being created in their tenant. When
inviting users whose organization is using Azure Active Directory, but where the specific user’s
account does not exist (for example, the user does not exist in Azure AD contoso.com). The
administrator of contoso.com may have a policy in place preventing users from being created. The
user must check with his or her admin to determine if external users are allowed. The external
user’s admin may need to allow Email Verified users in their domain.
 MCT USE ONLY. STUDENT USE PROHIBITED
Designing Solutions for External Access  79

●●
●● External user does not exist already in a federated domain. If you are using federation authen-
tication and the user does not already exist in Azure Active Directory, the user cannot be invited.
To resolve this issue, the external user’s admin must synchronize the user’s account to Azure Active
Directory.

Review Activity - Designing Solutions for Exter-

nal Access
MCT USE ONLY. STUDENT USE PROHIBITED 80  Module 4 Implementing Application and External Access

Let's play a quick game to test your knowledge of designing solutions for external access. Click on the
button below to open this review activity full screen.
LAUNCH ACTIVITY29

29 https://edxinteractivepage.blob.core.windows.net/miltstatic/MS100.3/20190329-071223255/static/CLD273x_M04_L03_cw_ExtAccesstutori-
al.html