1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Planning for Azure AD Device Join

Review and Assess

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW1m 9s
Course Summary

The course is part of this learning path

Review and Assess
Overview
Difficulty
Intermediate
Duration
20m
Students
104
Ratings
5/5
starstarstarstarstar
Description

This course looks at what goes into planning for Azure AD Device Join in Microsoft 365, and what you need to take into consideration when formulating your plans.

Learning Objectives

  • Understand the scenarios that you may encounter during the planning phase
  • Learn how to review identity infrastructures and assess device management
  • Learn about key considerations for applications, resources, and provisioning options
  • Understand the mobility options available and how to configure them

Intended Audience

This course is intended for anyone who wishes to learn about planning for Azure AD Device join in Microsoft 365.

Prerequisites

To get the most out of this course you should have a basic understanding of Azure Active Directory as well as Microsoft 365.

Transcript

Hello and welcome to Planning for Azure AD Device Join: Review and Assess. The process of planning for Azure AD device join includes several distinct phases, or steps. In this lesson, we’ll touch on the first few phases. More specifically, we’ll review scenarios you may encounter, we’ll talk about reviewing identity infrastructures, and then we’ll dive into device management assessment.

Let’s talk about common scenarios and use cases that you might find yourself planning for.

The real purpose of Azure AD join, when you really break it down, is to help you transition to a cloud-first model with Windows. 

For example, if you are planning on moving to Microsoft 365, you should probably think about leveraging Azure AD join. Azure AD join is also useful if you want to use a cloud device management solution to manage your organization’s devices.

Azure AD join is also a solution to think about if you are trying to simplify your device provisioning process for a user base that might be spread out over multiple locations or geographies. If you are planning to modernize your application infrastructure, Azure AD join can help there as well.

Now, before you implement Azure AD Device join, you need to review your current identity infrastructure. Is it a managed environment? Federated? These are the questions you need to consider.

You can integrate Azure AD join with managed environments AND with federated environments.

If you are planning to deploy a managed environment, using Azure AD join, you can use Password Hash Sync OR Pass-Through Authentication with Seamless Single Sign On. 

Password hash sync is probably the most-used sign-in method to accomplish hybrid identity. When using Password Hash Sync, Azure AD Connect synchronizes a hash, of the hash, of your users’ passwords from your on-prem AD to your Azure AD instance. 

Pass-through Authentication allows users to sign into on-prem apps and cloud-based apps, using the same password. The benefit of pass-through authentication is that it requires users to remember one less password. It’s important to note that when users sign in using pass-through authentication, they are validated directly against the on-prem Active Directory. 

Seamless Single Sign-On automatically signs users in when they’re on their corporate devices and connected to the corporate network. When you use Seamless Single Sign-On, your users don't have to provide their passwords when signing into Azure AD.

Neither of these managed deployment scenarios requires a federation server for authentication.

Now, if you DO want to leverage a federated environment, you need an identity provider that supports both WS-Trust and WS-Fed protocols. WS-Fed is required to join a device to Azure AD, while WS-Trust is required to sign into an Azure AD joined device.

If your current environment includes AD FS, you’ll need to enable the following WS-Trust endpoints in it.

If you are currently using a third-party identity provider, it’s important to note that if that identity provider does not support these protocols, Azure AD join will not work natively.

As far as smartcards and certificates go, I should mention that smartcards cannot be used to join devices to Azure AD, nor can you use certificate-based authentication to join devices to Azure AD. That said, you CAN use smartcards to SIGN INTO Azure AD joined devices, provided you already have AD FS configured.

Instead of using smartcards and certificates, Microsoft recommends using Windows Hello for Business if you require strong, password-less authentication for Windows 10 devices.

I also want to point out that if you currently create and manage your user accounts in an on-prem AD, you’ll need to deploy Azure AD Connect and sync your users to Azure AD, if you want to take advantage of Azure AD Device join.

It’s also important to note that if you have UPNs on-prem that are different from your Azure AD UPNs, they are not going to be supported on Azure AD joined devices. In these cases, you need to think about switching your users over to using their primary UPN in Azure AD.

The last phase I want to touch on in this lesson is the assessment of your device management needs.

It should be noted that Azure AD join can only be used with Windows 10 devices. You can’t use it with previous versions of Windows, nor with other operating systems. Part of your planning for an Azure AD Device join deployment should include upgrading any current Windows 7 or 8.1 devices to Windows 10.

I should also mention that while Azure AD Device join IS supported for FIPS-compliant TPM 2.0, it’s not supported for TPM 1.2, so you’ll have to plan a strategy for disabling TPM 1.2 on your devices before deploying an Azure AD join solution. 

Since you’ll need an MDM platform to manage Azure AD joined devices, you’ll have to give some thought to the management platform you want to use. Intune is the recommended choice, but Windows 10 has a built-in MDM agent that works with all compatible MDM solutions, so you aren’t locked into InTune if you don’t want to be. Either way, you need to think about your device management solution as part of your deployment planning for an Azure AD Device join solution.

Because Azure AD joined devices aren’t connected to an on-prem AD, it stands to reason that Group Policies are not supported on Azure AD joined devices. This reinforces the concept that the management of such devices has to be done through an MDM like InTune.

There are two ways to manage Azure AD joined devices. You can go the MDM-Only route, or you can go the Co-management route.

If you go the MDM-only route, your devices are managed exclusively by an MDM solution like Intune. All policies that get enforced are part of the MDM enrollment process.

If you need to go the Co-management route, your devices will be managed by both an MDM solution like InTune, and SCCM. If you need or want to go the co-management route, you need to install the SCCM agent on your MDM-managed devices in order to manage certain aspects of those devices.

If your environment is like most, and currently uses Group Policies, the planning phase needs to include an evaluation of your GPOs and you have to note their parity with MDM policies. This can be done by using Group Policy analytics in Microsoft Endpoint Manager.

You’ll need to determine whether or not you can use an MDM solution instead of Group policies. 

Ultimately, it’s Microsoft’s recommendation that, if possible, you use MDM-only management for Azure AD joined devices. 

So, they key takeaway here is that the process of planning for Azure AD device join includes several distinct phases, or steps. In this lesson, we touched on the first few phases. More specifically, we reviewed scenarios you may encounter, we talked about reviewing current identity infrastructures, and then we dove into device management assessment.

About the Author
Avatar
Thomas Mitchell
Instructor
Students
59671
Courses
71
Learning Paths
30

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.

In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.

In his spare time, Tom enjoys camping, fishing, and playing poker.