The chapter is about extending the key security components necessary to operate and manage mobile devices in Office 365 and Azure. This chapter is focused on the deployment of multifactor authentication (MFA), Mobile Application Management (MAM), Windows Information Protection (WIP) and Mobile Device Management (MDM). These four components are compliance components that are included with the Microsoft 365 suites. At the end of this chapter, you will have a good understanding of the MFA, MAM, WIP and MDM components and be able to deploy them with the Microsoft Authenticator application. The Microsoft 365 E5 suite that we are using contains all the features of Office 365, Enterprise Mobile E5, and Windows 10 E5 in one license. Our objective in this chapter is to build out the Azure Intune management portal so it looks like Figure 5-1. Microsoft mobile device management is part of the Intune component of the Enterprise Mobility Suite (EMS).
In Figure 5-2, we have configured the MDM portion of Office 365 and Azure to provide policy management of our Office 365 organization. The configuration includes managing conditional access, managing application deployment, deploying windows information protection, deploying approved applications through the Company Portal (available through the vendors online store), and blocking business data from being deployed to nonbusiness applications through Mobile Application Management (MAM).
Before we begin, let’s look at the EMS components (see Figure 5-3). We have already covered all of the other components except for Intune and Multi Factor Authentication. (see https://docs.microsoft.com/en-us/enterprise-mobility-security/). Keep in mind that EMS assumes all devices can be managed from Macs, including Windows 10 desktops, laptops, and mobile devices such as iOS and Android devices. The subject is complex, so I broke this down into the logical areas of deployment for device management. We will start with MFA, then progress to simple device management with MAM and WIP. We will close with a compliant device management using MDM.
EMS: Managing Mobile Productivity
Access to the Intune portal is controlled with the Office 365 subscription. The subscription that we are using on our account is the Microsoft 365 E5 suite. This suite has the equivalent of EMS E3 and EMS E5 built into the license offering as used to enable EMS is either EMS + E3 or EMS + E5. Since we have already enabled the Azure portal, all we need to do is add the Intune component to our dashboard. To add the Intune, return to the main Azure dashboard (click the dashboard at https://portal.azure.com) and type Intune in the search component (see Figure 5-4). Once you see the Intune listed in the search window, click Intune and pin the component to the dashboard. (Remember the pin icon in the upper-right corner we used previously? This is the way you make the dashboard components appear on the Azure dashboards.)
At this point we have added the mobility component necessary to manage user and company owned devices. The next step is to configure Mobile Device Management for our business. In this case, we are defining the security aspects of the company-owned devices and employee-owned devices (aka BYOD - bring your own device). In this section, we look at the configuration of Microsoft Intune for mobile devices and desktops. The management of Windows Intune is through the Azure Intune portal (see Figure 5-5).
Management of mobile devices can be easy or complex to deploy depending on the business needs. We are going to approach the configuration of the management of mobile devices from two perspectives: simple (MAM/WIP) for BYOD devices and compliant (MDM) for company own devices. We will walk through the process of setting up the environment to handle concluded with a fully managed mobile device under MDM. The two approaches are outlined here:
Simple
This is a basic setup for Mobile Device Management to control company information. A limited set of controls are used. This is for a basic level of protection and is our MAM deployment.
Compliant
The organization has a compliance requirement, so stringent controls are used to manage the devices. Compliance oversight may require how the data is used and what data is maintained on the device. The company store is used for device management and compliance checks and is our full MDM deployment.
Before we look at this in detail, let’s step back and look at Microsoft Intune and why it is used. I have used Microsoft Intune since it was released for cloud-based device management for the simple reason that it just works. Devices that have Microsoft Intune deployed with Office 365 have fewer support calls and trouble tickets. My own experience is that the Microsoft Intune reduces support calls by 50 percent when deployed with Windows 10 Automatic Updates under ring management and Windows Defender Advanced Threat Protection. Figure 5-6 shows the two different deployment options for Intune, using a stand-alone configuration or with System Center Configuration Management (SSCM). Our focus with Azure is the stand-alone configuration.
Device management is the process and tools for the management of users, devices, applications, and data. Office 365 and Microsoft EMS/Intune are built with a self-service model providing users with access to Microsoft cloud services worldwide. Microsoft Intune Mobile Application Management and Mobile Device Management provide consistent experiences for all users and the management of the devices. Users (and IT administrators) can add users to the local Active Directory, either through a workplace/Azure join or the traditional Active Directory Add User/Computer function. Microsoft Intune provides consistency of device management with the following:
Workplace/Azure join allows you to dynamically add a device with multifactor authentication.
Windows 10 (version 1809) Domain joined systems can be remotely configured.
There are consistent opt-in messages across all environments.
This is a consistent implementation of self-service portals across all environments.
The Office 365 self-service portal (allows users to install Professional Plus software on demand) is extended with Microsoft Intune hosted in Azure. This trend is forcing a change to the management of devices: application distribution via a company-owned application store. As new users enter the workforce, they want to use their own devices and load the software that they need to use to improve their personal productivity. As an IT manager, you need to figure out how to supply these services without adding additional support costs. This is where Microsoft Intune comes into play. Microsoft Intune solves these problems for users and IT managers. IT managers now have a single view to all the devices in the organization (see Figure 5-7), including Apple and Android devices. Device management with integrated Office 365 support is the power of Microsoft Intune.
Microsoft Intune vs. System Center
Microsoft Intune currently operates with Microsoft System Center or as a stand-alone cloud service. The Microsoft Intune System Center hybrid configuration is a legacy configuration and will slowly be discontinued over the next few years. If you are currently using System Center for the management of Intune manage devices, you can convert the Intune services to the Intune cloud management hosted in Azure.
The selection of the hybrid service versus the dedicated cloud service was because of the limitations of the Intune Cloud services. Those limitations no longer exist. Both the cloud and System Center deployments support the following services:
Unified EMS admin experience
Scale of more than 50,000 device restrictions
Full access to the Graph API
New advanced reporting
Role-based access control
It is recommended that you use Microsoft Intune Azure services for your deployment. The scalability of Microsoft’s cloud services and the security model deployed with Window’s Azure Active Directory federation. The linking of the on site Active Directory is through the Azure join systems and the Intune management portal.
As Microsoft deploys newer operating system (OS) software (aka Windows 10 Pro 1809 or later), these operating systems are shipped with a lightweight management agent integrated into the OS. These management agents simplify the user access in enabling their own devices to be managed by Microsoft Management. These agents are as follows:
Mobile Device Management: Intune management (lightweight management)
Configuration Device Management: Workplace Join (Azure or AD)
The changes that have been made with the Windows 10 solutions have made integrating different products into the management portal easy. Microsoft has expanded the different portals with new configuration options for various market segments. A good example is the integration of the Windows 10 Software Updates rings. See Figure 5-8.
As Microsoft Intune is deployed in Azure, new features are being added that were available only with dedicated on-premises solutions and massive infrastructure support using Microsoft’s System Center. Microsoft added new features to hybrid Active Directory Connector (AdConnect), that links the on-premise active directory device metadata with Azure Intune services. This capability extends the Azure Intune services to provide greater device control. This capability is extended further with the newer versions of Windows 10 operating systems (Pro and Enterprise) adding windows telemetry and security support to operating systems. You can now collect data on the operation and management of the windows devices with these new features enabled. Better data collection means less system and security problems and better end user productivity.
Getting Started with Microsoft Mobile Device Management
Intune has significantly changed from the Windows 7 days. No longer do you deploy Microsoft Windows Intune agents to manage devices. Today you manage devices and use the Azure Intune center of management. If you are using mobile application management, there are no agents to deploy. If you are using Mobile Device Management, you deploy the Company Portal to the company owned device. The company portal is deployed from the store (Windows store, Android Google Play store, or iOS store), and you deploy the Microsoft store to your environment.
The approach that we will be using will divide Intune deployment into two categories: a simple configuration and a compliant configuration. This configuration will give you a better perspective of the work required to deploy a full company managed MDM and the necessary configuration. As an example, Figure 5-9 shows how the desktop will respond to an Office 365 environment where the systems are required to be compliant. Before we start to deploy Mobile Device Management, we need to deploy multifactor authentication and the mobile Microsoft Authenticator application on your iOS or Android mobile devices. This is a key component that needs to be deployed to secure the mobile devices and provide secure access to the Office 365/Azure environment.
Deploying Multifactor Authentication
Multifactor authentication includes different methods for authentication. Initially you set up MFA to use multiple methods to get users to use the service and train them to use the biometrics of the device (fingerprint visual recognition), and so on. To accomplish this, you will need to use the Microsoft Authenticator on mobile devices and integrated biometrics on Windows 10 systems (1809 or later). As an example, when I use Windows Hello on my Surface, I am providing a biometric login to Office 365 with no password prompt. Biometrics can replace the cell phone text messages for authentication.
There are many people who do not want to deploy MFA and think their passwords are strong enough. For those skeptics, take a look at the sign-ins by location for our Office 365 tenant (see Figure 5-10). This is a 90-day snapshot of the audit logs for our Office 365 tenant. The logins shown below are bad actors from countries that are attempting to access our Office 365 tenant. We only have offices in the US. If you have any doubt that your password is strong and unique, you need to dismiss those thoughts and deploy multifactor authentication and start using the Microsoft Authenticator for single sign-on. Let’s walk through the steps and configure your Microsoft 365 E5 subscription with full MFA. What is happening in this case is the bad actors are using a password spray attack to try different passwords against our office 3365 tenant. The bad actors most likely purchased passwords for my email address from the dark web.
Step 1: Enable Azure Password Self-Service Reset
Log into https://portal.azure.com and click Azure Active Directory and “Password reset.” Set up the MFA deployment similar to Figure 5-11 by enabling the mobile app notifications, mobile app code, mail, and phone. Click Save when completed.
Step 2: Enable Access to the App
In Azure Active Directory, click “User settings” and then click “Manage settings for access panel preview features” (see Figure 5-12). Set the user to a user group (that is eligible) and then click Save (see Figure 5-13). In this case, we set the MFA test group to all of the KAMIND employees.
Step 3: Register the User Accounts
Have all users go to https://myapps.microsoft.com, log in with their Office 365 user information. Once logged in, select the user icon (upper right hand corner - see Figure 5-14). Once the user icon is selected, the pop-up menu options will include Profile. Select profile, then set up self-service password reset. Enter your password and follow the wizard to set up the email address and your cell phone. This is used for your account verification for password reset. Proceed to the next step to add additional security information and set up the authenticator app.
Step 4: Set an Authenticator App
The Authenticator app will work for modern applications and modern devices. Install the Authenticator app from the mobile device store (iOS or Google Play store). Once the Authenticator app is installed then you are ready to configure the app. To configure the Authenticator App, select “Additional security verification” (see Figure 5-14). Once you have selected the option, you need to select how you want to use the app with your login credentials (see Figure 5-15). The most common configuration is to select “notify me through the app” and select the check box for Authenticator app or Token. You are going to configure the app to link your login credentials. The reason why we do this is to configure your smart phone, so you can later use Mobile Application Management to manage the company data on the device. Once you have configured the application select “save”. You will receive an additional verification prompt to verify the codes were set correctly.
Step 5: Test MFA for Deployment
At this point, the infrastructure is set up. Now we need to enable the conditional access so that all users are required to use MFA. In our case, we will set up one user account and test it, before deploying this to all users. To set up the conditional access, click Azure Active Directory and then click “Conditional access” (see Figure 5-16). The next step is to add a location followed by a policy.
Name Location 1: Create a Name Location
On the “Conditional access” page, click Name Location. We are going to define a location where users access our business. As an example, if we are in the United States, we should restrict external access to the United States only. Click “Named locations.” We will build a name location as the United States and use this later to deny access. See Figure 5-17.
Name Location 2: Set Up US as a Name Location
Click the name location and then select New location (+ sign). On the new location enter “All US IP Addresses”, then select countries and “United States” click “United States” and assign the location name as “Restrict to US”. Click the options as shown in Figure 5-18 and then click Save. We are going to use the new policy to reduce the sign-in attempts. You can set up multiple locations. Some organizations have a location for each country they do business in. Keep in mind that bad actors can hop to a system from a U.S. location and still attack you. All we are doing is filtering as much as possible to reduce risk.
Let’s create a second location for working at home. In this case, we will set the IP address as a trusted location so we can use this location setting later. When you are completed setting the location, you should have two locations: All U.S. Addresses and a trusted location address (Work-Home). We will use these locations to filter bad actors later. See Figure 5-19.
After we create the name location, we are going to create the MFA policy for conditional access. Go back to the “Conditional access” options, click Policies, and then add a new policy called US only (see Figure 5-20).
When you click add a policy, you have to make decisions on five different areas of the policy (see Figure 5-21). I’ll outline the five steps with the different options. Our objective here is to create a conditional policy for the enforcement of multifactor authentication on all users. We are going to set this up so that any user who comes in externally from the United States will be denied access when clicking cloud resources. We are also going to require that the user accounts meet some minimal standards. Initially, we will require that the user meets at least one of three requirements. Over time, we will start changing these requirements to be more stringent. The requirements that we are deploying for this conditional access are as follows:
Must be a U.S. location
Must be one of following:
MFA required
Device is compliant
Hybrid Azure joined
Approved clients
Looking back at the access map shown earlier, we can now see that by deploying these types of restrictions, we will reduce our threat of breach significantly. Let’s deploy our conditional access policy. The user in this case will be our test group that has only one user account. When you configure conditional access, make sure that you test out the conditions with a user account before you deploy the polices to the entire organization. In our case we created a test group called MDM test group. In the test group, I added the pass@getoffice365security.
Policy 1: Assign a Policy Name
After you have created a new policy, assign a simple, descriptive name for this conditional access policy. Our policy is called “Require MFA to access all cloud resources”.
Policy 2: Assign the Users
In the test phase, you include a selected user (Test User in this case), and on the Exclude tab, you click “All users.” When you go into production, you reverse this. You include all users, and you exclude selected users (such as certain service accounts), as shown in Figure 5-22.
Policy 3: Select the Cloud Apps
The best practice in this case is to select the cloud apps that are being used. Do not select all cloud apps; otherwise, you may find yourself locked out of the Office 365 tenant. In Figure 5-23, we select the cloud apps that we use in our environment. In this case, we are selecting Windows Defender ATP, Office 365 Exchange and Office 365 SharePoint Online. Once you have tested this you can change this later to all cloud apps.
Policy 4: Select the Conditions: Device Platforms
There are five different conditions that we can use to control the policy: Sign in Risk, Device platform, Locations, Client apps, and Device state. In our example, we will configure device platforms and locations. To start the process, click Device Platform and then select the supported devices in the organization. Since this is a new deployment, click “All platforms (including unsupported)” at this time. Later, after you have a better feel for the hardware in your company, you can deploy additional restrictions. Click Yes and then Save to continue (see Figure 5-24).
Policy 4: Select the Conditions: Locations
Click Locations and select the new location. We are going to force everyone to use MFA except the trusted locations (see Figure 5-25). You can change this over time, but this will give you a good baseline. Microsoft defines a trusted IP as the corporate network (or configuration). In our current configuration, we have not defined trusted network. Later, we will add a second conditional access policy which we will block any locations, but will exclude all US addresses.
Once you have the completed the conditions configuration, save the policy and let’s configure access controls.
Policy 5: Select the Conditions: Device Platforms
The policy is controlled by the access controls. Earlier we set the conditions for the policy, and now we need to configure the policy for what we need to accomplish. We are going to set three access controls and enforce the controls. This means that the client will need to meet one of three access controls to access our resources. This is in addition to the conditional access that we have already put in place.
Note
It is easy to build a version of an access control that has everything. Do not do this. Focus the conditional policy on a single task. Do not have a conditional policy that tries to do multiple things, which is difficult to debug.
In our access controls, enable MFA, “Require device to be marked as compliant,” and Hybrid Azure AD join. Click “Require one of the selected controls” and then save the controls (see Figure 5-26).
At this time you are ready to apply the controls and test the account. Click “Enforce policy”) (See Figure 5-27) to turn the policy on. The best way to select the client is to log into https://portal.microsoft.com with the smart phone you used earlier to set up the Authenticator app. You will be prompted to authenticate with the app that was configured earlier.
Step 6: Deploy MFA to All Users
Deployment is easy. Once you have tested the account, you can add additional users to the test group. Make sure you have tested the policy before you deploy and verify with your users. If your MFA is not working and your systems are not compliant, MDM deployment will fail.
Getting Started with Microsoft Intune
Microsoft Intune is an Azure service for device management. What is different is the way we think about the deployment. When you use the Intune MDM solution, you are thinking about users and devices. We recommend you step back and look at your organization and create dynamic groups for users and systems assignments (this is described in detail later in this chapter). When I deploy MDM, I create test groups for policy deployment, and I use dynamic groups for production deployment.
Setting up Intune requires decisions about the following:
Which users will have application management?
Which users will have device management?
Which groups will have access restrictions?
Are you going to manage the organization with dynamic groups?
Let’s begin the process and set up some of the must-do configuration so we can deploy Mobile Device Management. Once we define a few items and set up some administrative functions, we are going to look at two different types of deployment: a simple deployment and a compliant deployment.
Step 1: Set Up Deployment Groups
We are creating eight groups. These groups are for our organization (based on the department structure) and for our devices. Also, let’s create three MDM test groups. If you do not know how to create dynamic groups, see the “Additional Configuration section - Using Dynamics Groups” section later in this chapter. The number of groups you set up is a strategic decision. My philosophy is to automate as much as possible with dynamic groups. When users are added to an organization, I define the department and manager and assign a license. I use dynamic groups to read the metadata of the object and add the user to the appropriate group. Permission and access are assigned to groups. Likewise, in Azure I use the concept of a blueprint and management groups to assign access and permission to Azure subscriptions. When you click groups, you create groups based on the organization strategy. In our case, we are doing a demo configuration and are using the groups listed here:
Dynamic team groups for the following departments: sales, engineering, marketing
Dynamic device groups such as Android, iOS, and Windows
MDM test deployment groups (static)
MAM test deployment group (static)
When you are done, the groups should look like the list in Figure 5-27. Keep in mind that the production groups are the dynamic groups. The test groups will be deleted once we feel we have the deployment tested and validated.
Note
If you are not ready to build groups, let’s keep it simple. You have a test account (as we used in MFA deployment), and you have everyone else. Exclude everyone and assign the test account. Once you have a policy successfully deployed, then apply it to all users or the different management groups.
Figure 5-28 is a snapshot of the engineering team. Note that we have the users, but also, as we build out the security infrastructure, we will have resources assigned to different groups. We can define applications that this group has access to as well as Azure resources. The objective here from a security standpoint is to create processes and standardize the behavior. See Figure 5-29.
Once the group is created, we need to create the membership criteria of the group. We are not going to assign users to the group, but have Azure service assign users based on the membership criteria. When you create the test groups, replace the expression in the “Advanced rule” box with All Users. See Figure 5-30. This will automatically add all users to the group as the user accounts are created in Office35/Azure.
In a few minutes, the group you created will populate with all of the users in your Office 365 account. If this is a production tenant, please verify that this is the process you will want to follow for MAM deployment in a test group.
Step 3: Set Up the Intune MDM Authority
Intune must be set as the MDM authority, or if you are using Systems Center Configuration Manager (SCCM), then you can set SCCM as the authority. If you are using a third-party product, you will still need to select the none or Intune option. Which MDM do you choose? If you have no plans to use Systems Center Configuration Manager, then choose Intune MDM as the MDM authority (see Figure 5-31). The Intune management plans will be grayed out until you select an option.
Step 4: Configure the Mobility (MDM and MAM) Enrollment URLs
After we set the MDM authority, we need to enable the MDM/MAM enrollment URLs. The enrollment URLs should have been set up when you verified your domain in Office 365 and added the necessary cname. If these cnames have not been added to your DNS, then add the cnames listed in Figure 5-32.
The cnames are listed in your Office 365 domain setup. To access this record, go to the Office 365 admin center, click Setup, click Domains, and select your domain that you are using for your default domain. The Office 365 admin center will display the domain records that are being used. Verify that all the cnames and other DNS records have been entered correctly. After you have verified that the DNS records are in place, then the next step is to set the MDM/MAM enrollment. To do this, open Azure Active Directory and click Mobility (MDM and MAM) (see Figure 5-33). Then click Microsoft Intune.
Change the MDM/MAM enrollment for None to All (see Figure 5-34); then click Save.
Step 5: Enable the Office Update Policy
The Office update policy is crucial for MAM and MDM deployment. Once we have completed the test group deployment, we need to define the Office Desktop Suite Update policy (see Figure 5-35).
In Figure 5-35, we click Add, name the policy Office Desktop Suite, and configure the policy (see Figure 5-36).
There are a lot of different options that we can use; we have detailed this later in the chapter. The typical Office update policy will look like Figure 5-37. The configuration options for Office Pro Plus are described at the end of the chapter. This will ensure that the Office updates are deployed. You can verify the deployment in the Intune management portal (click Intune, Client Apps, Apps, and then Office Desktop Suite).
If you click Office Desktop Suite, you can see the status of the Office deployment (see Figure 5-38). Our deployment of Office Pro Plus has a required attribute, so users after they log into Office 365 will have the Office Pro Plus software pushed to the client. This is how software is automatically deployed to the client system - worldwide. Let’s move on to step 6 and configure the Windows 10 software update ring.
Note
There are detailed instructions in the “Additional Configuration” section later in this chapter for the configuration of Windows Updates and Office Updates. I purposely gave an overview in steps 4 and 5 so you would not lose focus on the objective. We are building a framework for Mobile Application Management (MAM), Windows Information Protection (WIP), and Mobile Device Management (MDM). If we go into too much detail (like dynamics groups), we will lose sight of our objective.
Step 6: Enable the Windows Update Ring
We are using a Microsoft 365 E5 suite. As part of the deployment, we need to ensure that Windows Updates are configured and managed. I wanted to focus on the reason for this here. The main reason we are enabling the updates at this point is because we want to have compliant devices (se Figure 5-39).
When we fully deploy MDM, we are deploying for mobile devices, desktops, and laptops; everything will be managed and must be compliant. If the devices are not compliant, then the user will not be able to access the corporate resources. See Figure 5-40.
The configuration process for software updates is similar to Office updates. You need to define the update target and the dynamic groups and let the system manage the updates (see Figure 5-41).
Step 7: Test for Compliance
The end game is that we must have systems that are compliant. At this point, you need to deploy Windows Updates and Office Updates and test that the systems are compliant. See Figure 5-42.
If your devices that you want to test with are not compliant, you need to resolve the compliance issues at this point. All compliance is a stake in the ground because your systems are linked to your organization policy on device management. If your devices are not compliant (with all green check marks), find out why and resolve the errors. If you do not do this, your MDM deployment will fail, and your users will be locked out of using your Office 365 resources.
At the end of this chapter, I have detailed information on four important areas for MDM deployment. These are the dynamic groups creation and management of the Windows updates.
Keep in mind that to deploy MDM you will need to complete these four steps:
1.
Set up Intune as the MDM authority (or System Center).
2.
Create the dynamic groups for MDM deployment.
3.
Create dynamic groups to capture the devices for Windows Update.
4.
Assign the dynamic groups to Windows Intune to be updated.
Note
Make sure you have deployed the Windows 10 update ring and that the Office Pro Plus updates are marked updated and are compliant. If this is not the case, fix the problem before you continue.
Mobile Application and Mobile Device Management
We are all ready to go; we have set up the basic components of our Mobile Application Management (MAM, Windows Information Protection (WIP)) and Mobile Device Management (MDM) deployment. We have Intune set up as the Mobile Device Management authority, and we have created our test groups. We are going to walk through two versions of Intune MDM deployment: MDM and MAM. MAM will be the simple deployment. Windows Information Protection (WIP) will be deployed with MAM.
A compliant deployment (such as a full Mobile Device Management deployment) requires that you use the Company Portal from the IOS, Android or Microsoft online store to validate the endpoints (Windows 10, iOS, or Android). Figure 5-43 shows the Company Portal completing an analysis of a device to bring the device up to compliance standard. If the device is not compliant, then the user will not be able to access the Office 365 resources. Our end game will have all compliant devices. If you want to verify your Windows 10 device, download the Company Portal application from the vendor device store and run it. The desktop configuration that we are using is for Windows 10 devices that are either workplace joined or hybrid joined via a local Active Directory instance and AD Connect.
Note
If you are running a local Active Directory and want to deploy MAM/MDM, you will need to install Azure AD Connect for Azure Identity. If you are using a test account and test machines and no Active Directory, the Windows 10 devices must be Azure joined. To Azure join a new Windows 10 device, reset the Windows 10 device (remove all data) and click the Work or School account when you start a first-time Windows 10 installation.
This is a Mobile Application Management style of deployment, with some conditional access. MAM deployment works for Microsoft Intune because Microsoft owns the application that we are deploying on the mobile device. There are enough controls over the device to protect information, but it is not a fully compliant deployment.
MDM is our compliant deployment. MDM is a much more robust deployment and requires device integration to the mobile device stores. In an MDM deployment, we create Apple and Android accounts to access the vendor store. If you have an AD, Group Policy is used to push information out to the devices, and the company portal is downloaded to the device and allows what applications can be used on the mobile device. If you have only an Azure joined device, you are using Intune policies to push out information to the mobile device. Windows 10 devices will be policy managed via Windows Information Protection (see docs.microsoft.com and search for Windows Information Protection (WIP)).
Simple Intune Deployment: Mobile Application Management
Let’s get started with our simple deployment. Our simple mobile device deployment will be a mobile application deployment and will be required for our Mobile Device Management deployment. The reason for this is a simple one. All mobile devices (and Windows 10 devices as well) have only one mobile device authority deployed to manage the activity of the device. In this section we are going to use our test MAM group called Test Users that we created earlier.
There are some gotchas with running MAM, and this has to do with the device that you are using. If you are using an iOS device, you need to download the Microsoft Authenticator from the Apple store and install it on the device. If you are running an Android device, you need to install the Intune Company Portal. If you do not do this, the device will not work with MAM and cannot be managed.
Note
iOS Users: If you have an iOS (on a mobile phone or an iPad) and you want to run MAM, you must install Microsoft Authenticator and link the Microsoft Authenticator to your Office 365 work account at https://myapps.microsoft.com.
Android Users: If you are using an Android device (on a mobile phone, a pad, or a Chromebook) and you want to run MAM, you must install the Microsoft Company Portal from the Google Play store and log in with your Office365 work account.
A MAM deployment does not require us to set up links to the iOS or Android store (this is required for a full MDM deployment). The MAM deployment allows us to directly configure Microsoft applications to the mobile device. The user can download the applications to their device, and the MAM integration will make the device compliant with the policies associated in our business. We are focusing on the MAM deployment in the Windows Intune portal (see Figure 5-44).
The configuration process is simple; we will define the app protection policy. Once this policy is in place, we will assign users to our test accounts. At the end of our MAM deployment, we will expand the test group for all users. Make sure you have thoroughly tested the deployment before you deploy the test group; otherwise, you will restrict access to the company data by your users. See Figure 5-45.
Let’s start the process and get our MAM configuration in place. Before you start this process, you will need to have completed the previous steps. If you have not completed them, you are putting your deployment at risk. The Windows Update, Azure joined/hybrid join devices, and Office updates must all be marked compliant at this stage. If they are not compliant, fix the problem before you continue. Otherwise, your deployment will fail. Let’s get started with Mobile Application Management. Our objective for MAM is to build the following policies for Mobile Application Management.
Note
When you deploy policies, you need to develop global policies to all devices and assign all users (Android, Windows 10, and iOS devices). Otherwise, the device will be marked noncompliant.
At this point, we have deployed the Software Updates and Office Pro Plus policy updates. The desktop clients that we have attached are all compliant (Azure join or hybrid join). The next step is to deploy the policy for applications management. If your devices are not compliant(with green check marks), stop now and resolve the issues with the devices. Once you have verified the configuration and devices are marked all compliant, you can start the mobile device deployment.
Step 1: Set the MAM Deployment Rules
Before we begin with the deployment policies, let’s review the three rules associated with MAM/MDM deployment.
The iOS device must have deployed the Microsoft Authenticator.
The Android device must have deployed the Company Portal.
You must have Intune license for all devices (part of Microsoft 365 E5 suite).
Verify that you have completed all these steps before you continue with the MAM deployment.
Step 2: Set Up the Windows 10 Application Policy for MAM Without Enrollment
What this means is that the device is not enrolled in Intune (aka MDM), but it is enrolled under MAM. We are creating a Windows Information Protection (WIP) app protection policy with Windows Intune. The process is outlined here.
Policy 1: Add the Windows 10 Application Policy
In Figure 5-46, add a new protected app policy by clicking the Intune and then “Client apps: and then “App protection policies.” Then click “Add a policy.” After you click “Add a policy” enter the following policy blade information for Windows 10:
Name: Enter Windows 10 Policy No enrollment.
Description: Enter Test Windows 10 Policy.
Platform: Click Windows 10.
Enrollment State: Click Without Enrollment.
Policy 2: Add Windows 10 Application Policy
After you click “Add a policy,” enter the following policy information for policy name, Platform and policy type. After you entered the information, select “add apps” to add the Microsoft applications that will be managed under those policies. See Figure 5-47. We are building two policies. One policy is for devices without enrollment into our deployment, and the other policy is for devices that are formally enrolled. Both are very similar, but only different in the policy type.
Policy 3: Select the Windows 10 Apps You Want to Deploy
Click the apps you want to push down without an enrollment. See Figure 5-48.
Click OK and add the apps, as shown in Figure 5-49. Click OK after they have been added.
Policy 4: Configure Windows Information Protection
In this case, we will enable Windows Information Protection (WIP) to track inappropriate sharing modes and block them (see Figure 5-50). This protects corporate data from data loss.WIP places controls over corporate data and personal data on Windows 10 devices. WIP policies allow corporate data to be managed on personal devices. As an example, when an employee leaves a company, and the user is removed from Office 365, the WIP policies will remove the data from the user’s personal Windows 10 device. The configuration below, allows WIP to look for inappropriate data sharing practices and blocks the user. Typically, you will see this when a user tries to copy data from a one drive to the desktop that is managed by WIP. The activity will be blocked.
Policy 5: Set the Windows 10 Advanced Settings
The next step is to configure the advance settings. Select configure the advance setting option, and set up the policy and use the defaults. Since this is a device that is not enrolled and managed, we need to define the offline policy. If the device is offline, then our policy is to wipe the persistence data. Once you make the changes, select save and create the policy. See Figure 5-51.
Policy 6: Assign the Test User to the New Policy
Once you have completed creating the policy, click the policy and click Assignment. Either assign your test group (recommended) or the All User policy (see Figure 5-52). In this example, I have a test tenant with an all users dynamic group.
Step 3: Set Up a Windows 10 Application Policy for MAM with Enrollment
After we created the without enrollment policy, we need to create the corresponding systems with enrollment for our Windows 10 devices. We will create a section with enrollment. With the exception of selecting the enrollment (see Figure 5-53), the steps are the same. Once you have set up the steps, we can move to step 3, policy 2.
Policy 2: Add the Office Pro Plus Exception
The only change that you will make is adding an exempt policy for Office Pro Plus (see Figure 5-54).
Policy 3: Configure Windows Information Protection
In this case, we will enable Windows Information Protection (WIP) to track inappropriate sharing modes and block them. This protects corporate data (Figure 5-55).
Policy 4: Configure the Advanced Settings
Click “Configure advanced settings” and leave the defaults. When you are done, it should look like Figure 5-56. Click OK and Create. This will create the baseline Windows 10 policy.
Policy 5: Assign the Test User to the New Policy
Once you have completed creating the policy, click the policy and click Assignment. Either assign your test group (recommended) or assign the All User policy (see Figure 5-57).
Step 4: Set Up an iOS Application Policy for MAM
The process is almost identical to the Windows apps. The difference is in the hardware setup and configuration. In Figure 5-58, we added a policy, and then we clicked the iOS applications to add.
The next step is to set the device restrictions. The device restrictions are set up to protect the corporate data. In Figure 5-59, we have a section of different options to choose from. The key criteria is to restrict the data from being copied. Set up the data elements and pay attention to the circled areas. This is where the data restrictions are located.
One you have set up the data, save and create the iOS profile. The next step is like the other policies: edit the properties of the policy and set it to everyone for deployment (Figure 5-60).
Step 5: Set Up an Android Application Policy for MAM
The Android device is similar to the iOS device. Create a new policy, assign applications, and assign the restrictions in Figure 5-61 for the initial application assignments. Be careful when you select some applications and make sure you test them. As an example, if you select the Android Microsoft launcher, you can effectively lock the user out of using any application on the Android phone.
Once you have completed the applications assignment, click “Configure required settings” to set up a finer level of detail of data management on the device, identical to what we’re doing on the iOS devices (see Figure 5-62).
The final step is to assign all users to the device (see Figure 5-63).
Step 6: Set Up a Default Compliance Policy
One of the other policies we need to put in place is a default compliance policy. If the devices that are connected to our network meet certain criteria, we will make the devices compliant. You can expand on the policies and tighten them down based on your business criteria. Our goal at this point is to put in place a basic policy. To add the policy, go to Azure Active Directory, click “Conditional access,” and add a new policy (see Figure 5-64).
Policy 1: Set Up a Policy for All Users
Name the policy Default Compliance Policy, and select “All users.” See Figure 5-65.
Policy 2: Assign the Applications for Access
Select “All cloud apps” and assign them to all cloud apps. Ignore the message shown in Figure 5-66.
Policy 3: Create the Conditions for the Compliance Status
Compliance is extremely important. If a device is marked non-compliant, then the device will not be able to access corporate resources. In this case, we are adding a compliance factor for risk level. Select Conditions, and we will define three different areas for compliance. These are the sign-in risk, the client apps, and the device state. You can add additional restrictions, but at this point, let’s keep this simple and change them later. The goal is to force the clients to authenticate to our network. If they cannot authenticate, we will make them noncompliant. The criteria we are using are as follows:
Client applications used on network (see Figure 5-68)
Set up the device state for cloud app security (see Figure 5-69)
We will step through the configuration to set up the default compliance policy.
Policy 4: Set the Access Controls
At this stage, we are setting the access controls for the compliance. We are going to grant access based on the Microsoft application being used (see Figure 5-70).
Policy 5: Set the Session Controls
The final policy step is to set the session controls to use CAS. This is important because the data will be monitored in real time in CAS. We configured CAS in an earlier chapter. See Figure 5-71. CAS is used to generate systems alerts for security breaches.
Policy 5: Enable the Policy
To enable the policy, just click “Enable policy” and create the policy. See the status on the new policy. To see the impact to an organization, open Outlook on your iPad, and you will see the pop-up message requiring you to log out and log back into Outlook (see Figure 5-72).
Also, in our configuration we set the requirement to use a six-digit PIN code. When you restart Outlook, you will be greeted with the requirement to enter a six-digit PIN (see Figure 5-73).
If you do not see this behavior, verify that the Company Portal application and the Microsoft Authenticator application has been installed on the mobile device. Android clients require the Company Portal (from the Google Play store) has been installed. iOS clients require Microsoft Authenticator application to be installed from Apple store.
The basic MAM and WIP management is complete. Now we need to expand our management with conditional access. Conditional access will only allow Microsoft applications to use the service and no longer allow data to be copied between third-party applications. This is how you block the email client on the device. All of the compliance regulations are requiring this feature to be deployed.
Step 7: Lock Down Access to Nonconditional Access
Currently, if you started the Apple e-mail, you would see that local e-mail is permitted to access company e-mail (see Figure 5-74). What we will do next is to block corporate data from being used by the native applications.
There are multiple ways to do block corporate data on mobile devices. The method I use is to set up a global condition that overrides all the other conditions for sharing e-mail information. To do this, we are going into Microsoft Intune; then we will click “Conditional access” and set the Exchange access policies through the Exchange Active Sync connector.
Policy 1: Enable the Exchange Active Sync Connector
In the Microsoft Intune “Conditional access” settings, click the Exchange Service connector and click Set up Service to Service Connector (see Figure 5-75). Once you click the service connector, it will take a few minutes to set up. When you see the setup notification, then click Full Sync (see Figure 5-76).
Refresh the browser, and the status will change to a connection status (see Figure 5-77). At this point you are ready to block e-mail access to nonmanaged e-mail clients. (When you refresh the browser, it will display on-premise; ignore this.)
Policy 2 : Set the Notification to the End User That E-mail Is Being Blocked
Click Microsoft Intune, click “Conditional access,” and click Exchange Active Sync (see Figure 5-78). We are going to add the notification to the users, followed by the restrictions on using ActiveSync. Select user notification and the default configuration.
We are adding a message for users to redirect them to https://portal.manage.microsoft.com (also called the Company Portal). The is where the device can be checked for compliance with Mobile Application and Device Management. Compliance is critical for Mobile Device Management. The Company Portal will help to debug compliance issues when a device is under management. If the user goes to this screen at this stage, there will be no applications displayed because we are not deployed MDM. The sample message is shown in Figure 5-79.
The message gets loaded in the configuration section. Note that we added information for Android devices and iOS devices. iOS requires that Authenticator application is installed (not necessarily running) and that the Company Portal is installed for Android devices (again not configured). These applications must be installed on the device for access to corporate data. See Figure 5-80.
Policy 3: Block E-mail to Nonmanaged Devices
Once you have the policy in place, the next step is to determine the behavior for nonmanaged applications when accessing e-mails. In this case, we are restricting e-mail communications only to devices that have managed applications. This means that the Apple Mail and Google Gmail clients (and any other third-party clients) will no longer work on the devices that are subject to this mail policy.
The reason for this is to control data on the personal device. As a corporate custodian, I need to be responsible for all the business information for any device that is connected to my network. When an employee leaves, I must be able to remove corporate data from the user device. All we are doing in this case is blocking the data so it is on managed applications. See Figure 5-81.
Step 8: Test the Changes in the New Policy
Let’s open an iPad and click the Apple Mail client. If the policy is working correctly, there should not be any e-mail received in your Apple e-mail clients. Send a new test e-mail to your account and see what is the displayed. Now open the Outlook e-mail client that is on your iPad, and you will see a new e-mail message with the block notification that we just configured (see Figure 5-82).
At this point, all that is left to do is to complete the testing and apply the policies from the test user to all of the users. One note of caution: before you apply this company-wide, send out an e-mail notification to users that they are required to download the Outlook clients to the mobile device and that they will need to download the company portal (all Android devices) and Microsoft Authenticator (all iOS devices). Once these applications are in place, the company resources will be protected.
MAM and WIP Setup Is Complete
We have completed the MAM setup and WIP setup for Windows 10 devices and Android and iOS devices. We restricted data to these devices to our Office 365 tenant. This approach allows control over the company data on the user devices but does not give permission for the corporate entity to wipe the company device. If a device is compromised, we can wipe the data from the applications. In our MAM model, we disallowed data from being stored locally.
Once you move outside of applications management to device management, that is when you cross the line to Mobile Device Management. Mobile Device Management is a different configuration altogether and requires additional work to set up and configure the services. If you lay out the services correctly, MDM, WIP and MAM can co-exist with each other. Mobile Device Management will require us to use the Company Portal to manage the device. You can manage mobile phones to laptops (including Mac-based systems). Figure 5-83 shows the company portal with an MDM deployment. Notice that the MDM deployment verifies that the device hardware is compliant with the company policies. This is the topic we will discuss next. It is important that you have tested the MAM/WIP polices and have all the systems marked compliant. If your systems are not marked compliant, those devices will be blocked from accessing corporate resources.
Compliant Intune Deployment: Mobile Device Management
Earlier, we completed the deployment of Mobile Application Management and we have deployed Windows Information Protection (WIP). At this point, you have managed your corporate data and access to personal devices. We have a set of policies around the operation of the devices that connect to our network. In this section, we will deploy a device-managed MDM. There are five different areas associated with MDM deployment in Microsoft Intune (Figure 5-84). These are device enrollment, device compliance, device configuration, mobile apps and conditional access. Earlier in our deployment of Mobile Application Management, we deployed only a basic set of applications on the device. We were restricted what applications we could deploy. As an example, we could not download additional applications for deployment such as the Salesforce applications or a new version of Waze for GPS directions. Another capability that we did not have is the ability to tightly manage the device.
When we integrate a full MDM deployment, we add the application management, conditional access, and full application management on the mobile device. MDM-deployed devices require that we deploy the Company Portal to the device so we can manage and deliver applications securely. The Company Portal is the management agent that is deployed on a managed mobile device (windows, IOS or Android) The Company Portal application can detect if a device is compliant and blocks the device from accessing corporate data. In this section, we will deploy Mobile Device Management in five areas.
Device Enrollment: Setting up accounts in the manufacturer’s online store
Device compliance: Setting polices around devices for the management of our corporate data
Device configuration: Setting up policies for device management
Mobile Apps: Managing applications on the device
Conditional Access: Controls on accessing corporate data on devices
A fully managed device means we need to set up and configure each of these areas against the corporate policy. Our objective is to set up an environment where you can have a fully managed device.
Device Enrollment
The first step to building a compliant Mobile Device Management deployment is to set up accounts in the two mobile device stores, Apple and Google. Enrolling in the stores allows you to download a trust certificate that you can use for the deployment of applications to the mobile device. Earlier in our simple deployment, we were deploying Mobile Application Management (MAM) and not Mobile Device Management. See Figure 5-85.
Application support on the mobile devices requires us to download the applications for us to manage them. For this to happen, we need to create accounts and download trust certificates to our Office 365/Azure tenant. The trust certificates allow us to change the mobile applications and push them out to the mobile devices that are controlled. Once we have set up the trust relationship to the iOS and the Android store accounts, we can push out the applications to the device. See Figure 5-86.
Step 1: Sign Up for an Apple Push Certificate
Click the Apple push certificate and follow the wizard to set up a business ID with Apple. The process is straightforward; you need to create an Apple ID (go to https://appleid.apple.com) that you will use to manage your certificates and portal access. Once you have created the Apple ID, then complete the following steps (see Figure 5-87):
1.
Grant Microsoft access to send user and device information to Apple.
2.
Download the Apple certificate (you will upload this to Intune in step 4).
3.
Enter in your Apple ID so Microsoft can sync data with Apple.
4.
Upload the MDM push certificate you received from Apple.
Once you have completed the upload, the status will change from not set up to set up.
Once you have linked Apple and Microsoft Intune, the status will change (see Figure 5-88). At this point, you can access applications from the Apple store and enable applications to be used in your MDM deployment. Once you have a valid certificate installed, you can use the additional configuration options that Apple provides. We are not going to focus on these additional options, rather on the basic MDM deployment.
Step 2: Sign Up for Google at Work
Google has a similar process to Apple. You need to create a Google Gmail account and use that account to manage your Android enrollments. Once the setup is complete, you can configure apps. See Figure 5-89.
When you launch Google to connect, you will connect to the Bring Android to Work site. Like with Apple, you will need to set up a Google ID for accessing data from the Android environment (see Figure 5-90). Be advised that when you sign up for a new Google account, you will be required to enter the GDPR information, such as the data protection officer (DPO) on your Bring Android to Work account. See Figure 5-91.
Once you have completed the Google account setup, you can define the work profile and enrollment restrictions. Likewise, you can restrict user devices. We will not be using these configurations, so leave them at the default settings.
Step 3: Set Up Windows Enrollment
We will use all of the default settings for the Windows enrollment. Earlier in this chapter, we verified the cnames for the Intune portal on device registration. No changes are required at this time because we have already completed all the work in this section for our deployment.
Step 4: Set Up the Terms and Conditions
The terms and conditions should reflect your company policies and what is in your employee handbooks. Typically, these terms and conditions should match your organization’s policies. As an example, our terms and conditions are listed in Figure 5-92. After you accept your terms and condition, verify that you assign them to all users.
After you have completed these steps, you have set up the device enrollment. The next step is to set up the polices for device compliance.
Device Compliance
Device compliance consists of the rules and polices that you want to have deployed in your organization. These rules and policies may be driven internally or through an external organization. The point is that these policies for compliance are driven by the organization for some business need. When we look at Mobile Device Management, we are configuring hardware to meet compliance requirements. When we look at Mobile Application Management (MAM), we have the same goals, but we can configure only the software. MDM allows us to do both. To configure device compliance, you configure policies to manage the hardware deployment. In our case, we are deploying different policies for device management (see Figure 5-93), one policy for each type of device that we are managing.
The device policies can be extremely complex depending on your business needs. Let’s start the process.
Step 1: Create a New iOS Policy
Click Create Policy. We will click an iOS device and set up some minimum requirements for the iOS device. In our case, we will require that the password to unlock the device is six characters, and we will block simple passwords (like 123456). Create the policy similar to Figure 5-94.
After we have set the base set of parameters, click OK and then Create. This will create a new iOS policy. Our policy is a simple policy and requires a password on the iOS device.
Step 2: Assign the Test User Account to the Policy
After we create the test policy, we need to assign a test user. We need to assign one based on the security groups. If you have not created a test security group, do so at this time and assign the test user to that security group. In our case we created a test group called MDM Test Group and assigned our test user to this group (see Figure 5-95).
Step 3: Create the Three Other Policy Groups and Assign the Test User Group
Follow the same process and select four additional policies. If you want to set a policy, then set it. I chose iOS because it is easy to see the deployment. The key to setting policies is that Intune is smart enough to determine what policies apply to which devices. Your objective is to make all devices compliant. To make all devices compliant, you need to cover your bases (as they say) and deploy all policies against the same group. The policies you need to create are as follows:
Android
iOS
Windows 10
macOS
After you complete the policy deployment and the device is enrolled (we are not at that stage), you should see something like Figure 5-96. In this case, I have six devices in my test group, and only one device (the iPad) is compliant (as I would have expected). For the other five devices, the iOS policy does not apply.
Step 4: Set Up the Compliance Policy
As you deploy your policy, you will have a situation where devices that do not have a compliance policy are set to compliant. See Figure 5-97.
That is all we need to do at this stage. The next step is the device configuration.
Device Configuration
We have already deployed some policies in the device configuration. One of the policies we deployed is OMA_URI for the Windows 10 commercial ID deployment. We completed this in an earlier chapter. Device configuration is the hardware configuration that you want to have in your MDM policy to be deployed on the devices. In our case, we already deployed the Windows 10 commercial ID. In Figure 5-98, we have a Windows 10 deployment profile. In this case, we can click the different deployment models that we want to follow. As an example, if you click Windows 10 and “Device restrictions,” then select that option so you can deploy restrictions on the Windows 10 devices.
You will have a complex profile that allows you to set all of the hardware parameters associated with the Windows 10 device (see Figure 5-99). I wanted you to see the options that are available to you. At this time we have only one policy deployed, and that is the commercial ID that we deployed in a previous chapter.
Verify that you have deployed the commercial ID. If this not deployed, return to Chapter 2 and review the Log Analytics instructions where we deployed the commercial ID.
Devices
Select Intune then Devices to see the status of the deployment. The only actions we can do on devices is to set up remote support via Team Viewer Connector and the devices cleanup rules. I will not describe Team Viewer here; there are different philosophies on what tools to use for remote support. However, the one device policy that needs to be configured is for cleanup rules on old devices. Be careful with this; this will remove the device from Intune management.
In our case, we will create a policy that remove devices after 180 days from Intune management (see Figure 5-100). This policy is for all devices. When I mark this policy with the deletion option, make sure you copy bitlocker keys for the Windows 10 devices and archive the keys. The BitLocker key for the Azure join system is in Azure Active Directory under the device name.
That is all the configuration that we do with devices. Figure 5-101 shows the status of our enrollment. As you deploy additional systems under MDM, you can see the status displayed under the Device category.
Client Apps
Earlier we enrolled in the Apple Store and the Google Play store. The enrollment was necessary so we have access to the client apps that we can download and deploy via the Company Portal. What is different with MDM is that we deploy a management policy against the device. The Company Portal is the management agent on the device. The management agent implements the management policy and the agent writes to the device registries if needed. The management agent deploys all the applications to the device. In our MAM world, we are managing applications and not devices. This is the fundamental difference between MAM and MDM.
There are three categories of application deployment: apps, app configuration policies, and app protection policies. When we deployed the MAM deployment, we used the app protection policies. Those policies are in place for the MDM solution that we define. This is why we deploy MAM policies first, and MDM policies second.
App configuration policies are used to customize an application. As an example, if you are deploying a configuration for an app, you need to customize the configuration from the Intune SDK. Configuration policies are available for iOS and Android apps. This setting allows an app to be customized for deployment. The configuration policies are used when a app checks them, usually the first time the app is run. You can configure apps either as a managed device implementation or as a managed app implementation. The best way to look at the capabilities of customizing an app is through the Intune SDK. This is beyond the scope of this chapter.
App protection policies are used to customize the behavior of an application as a managed app with restrictions on what the app can or cannot do. As an example, Microsoft apps can be restricted to handle information to/from the managed applications. This means a user cannot cut data and place the data into nonmanaged applications. This implementation is required for compliance management, and we discuss this in the MAM section. We will not be making any changes for our MDM deployment.
Apps are applications that are downloaded from the various online stores (Apple, Google Play, and Microsoft) and are enabled for deployment to the device under MDM. When we created device enrollment earlier, we created links to download the different applications for deployment. This is the focus of the deployment in this section.
How Are Apps Deployed to Devices?
Before we jump into the app deployment, let’s look at the process for MDM deployment. MDM is different than a MAM deployment. MAM deployment is managing applications on the device. The MDM deployment will set up the device as a managed device. The process of enrolling a device in Mobile Device Management follows theses three steps:
1.
Deploy the company portal from the device store.
2.
Log into the company portal with your Office 365 account and accept the terms and conditions.
3.
Install the apps that are permitted by your company to run on your device.
This is how devices are managed under MDM. To get started, we need to install the applications for the device into the Company Portal. The user will start up the Company Portal on the device and install approved applications to the device. This is why it is necessary to make sure the devices that are used are compliant before you deploy MDM. The Company Portal application will check for compliance and block application deployment and users access to corporate data on non compliant devices.
Making Android Apps Available
Before we start to load apps, there is a special Android app configuration that we must complete. We need to select the Android apps from the Google Play store to be able to download them to our MDM devices. In Figure 5-102, click “Client apps” and then Google Play. You log into the Google Play store and select the apps that you want to deploy; once you selected all of the apps, then you click Sync.
The process is a little bit tedious for Android. You need to select each app and approve them for download, one at a time. (see Figure 5-103). After you select the apps, then you sync them.
The process is straightforward:
1.
Log in to the Google Play store with the login you created earlier.
2.
Select the apps that you want to enable.
3.
Sync the apps to the Intune MDM platform.
Once you complete this, the only step left is to configure the apps for the Company Portal. At this time, complete these steps for Android and sync the apps so we can configure them for the company portal and MDM deployment. After you click Sync, the dashboard will update the status.
Load Apps for the Company Portal Management
To load apps, click App. You will notice that the apps that are available are already displayed. There may be Android apps present but no iOS apps. To add the iOS or Windows apps, follow the steps outlined next.
You repeat the process to add all of the apps to the company portal. When you add an app, pay attention to the app characteristics. Make sure you set the updates (if available) and you select to display the application in the company portal. This will allow the end user to see the availability of the apps in the company portal and how the apps interact with each other.
In our MAM deployment, we define the apps as a managed app. This means that the apps cannot share data with third-party apps; they can only share data with managed apps approved by the company. The MDM deployment uses the MAM app condition access configuration as part of the deployment.
The final step in the app configuration is to make sure the apps are assigned. In Figure 5-105, we show how to assign an app. If an app is not assigned, it cannot be downloaded to the company portal and used.
When you click an app (see Figure 5-106), you must do the following to make the app available for distributions:
1.
Click Assignment; then click “Add group.”
2.
Click the drop-down to make the group available for all devices.
3.
Select the included groups and click Yes for all enrolled devices.
Perform these steps with all the apps that you want to make available in the Company Portal. After you are completed, the client apps should display Yes for an assignment. Review the apps that display No, and go back and assign the app or remove the app from the Company Portal (see Figure 5-107).
Conditional Access
Conditional access is used to restrict applications that are not approved to access corporate data from accessing corporate data. A good example is using your third-party mail applications to access corporate data versus the approved managed applications. This access enables data loss on the device. You should not need to make any changes here. The settings that we deployed for MAM and MFA are all that are needed for our MDM deployment.
MDM Setup Is Complete
We are now ready to test. What is the best way to test? Grab a new laptop or iPad, load the Company Portal, and log in with your work e-mail address. The Company Portal will tell you what needs to be fixed on the device and will attempt to fix it. What is happening is that the Company Portal is making the device compliant based on the standard that you have deployed. Continue testing your deployment. It is important that you get this right before you deploy to all of the clients at large.
Deploying MDM
In our MAM deployment, the final step was to make sure that we had a fully compliant system before we started to deploy MDM. We have taken a slower approach on the deployment of MDM with test groups to ensure that we didn’t create a situation where the users are locked out of accessing the corporate resources on Office 365 and Azure. To make sure that we deploy MDM successfully, we used test groups. At this point, we are making one last check with our Windows 10 devices before going live in a production environment. After you are sure the Windows 10 devices deploy correctly, then deploy iOS and Android.
Once you have configured and tested the iOS and Android configuration, you need to test in the production environment. The MDM/MAM configuration discussed in this section makes the following assumptions:
1.
You have fully deployed a MAM configuration.
2.
You have deployed MDM in a test group model.
3.
The Windows 10 and Mac desktops/laptops are compliant devices.
4.
Windows 10 devices need to be running version 1809 or later.
The common mistake that is made is that the desktop systems have not been verified with the Company Portal application and are not compliant before the MDM services are deployed to the users. What causes this is the conditional access policies. For the conditional access policies to work correctly, the Windows and Mac desktop clients must be compliant. If you do not have desktop systems that are compliant, then the mobile policy may work on the mobile devices, but the desktop will not work. When a noncompliant policy is deployed, the user will be unable to access corporate resources on Office 365 and Azure services from the desktop and web applications on their workstations. Deployment of the Company Portal is mandatory. If you are not using Group Policy to push changes, you can use the Company Portal (the downloaded application from the Microsoft store) to identify problems and make changes and to bring the desktop/laptop systems into compliance.
Microsoft has supplied an end-user Company Portal for the deployment of the Intune MDM/MAM solutions to user desktops, available from the Apple store and Google Play store. Accessing the Company Portal is easy; go to the Microsoft store (or Apple or Google Play) and search for Company Portal. You download the application to the system and install the software. If you are using a Windows 10 system or Mac, make sure you pin this to your Start menu or Finder (see Figure 5-109).
The steps are easy for the end user.
1.
Add the user to the Windows 10 (or MAC) MDM group (discussed earlier).
2.
Download the company portal from the Microsoft store, and run the application.
3.
Log in with the company credentials and accept the corporation’s terms and conditions.
4.
Follow the steps outlined in the application to make the system compliant.
The steps walk the end user through the configuration. Once the end user has deployed the Company Portal, the managed applications will work as expected. In Figure 5-110, the Company Portal was deployed, and the system that it was deployed on is not compliant. To make a system compliant, expand the item in question and click “Check status” (see Figure 5-111).
That is all there is to do with the company portal. This is useful when you are troubleshooting an MDM solution that is deployed on a client, either remotely or on-site.
Production Release of MDM
All of the hard work is done. All that is needed at this stage is to expand your test group to all users (or to use the different dynamic groups created earlier). The choice is up to you on what is the best type of rollout. On MDM we recommend that you start with small test groups and slowly expand the test group. MDM is a lot different than running with the MAM solution. MDM requires control of the hardware. You need to be careful so you do not block users from accessing corporate resources.
These are the next steps:
1.
Add additional users to test groups.
2.
Verify connectivity and compliance (use the company portal).
3.
Deploy to the organization once testing is complete.At this point you have completed the deployment of Mobile Application Management, Windows Information Protection and Mobile Device Management. Keep in mind that it is best to deploy the basic infrastructure and make sure your systems are marked compliant before you start a MDM rollout. Once you have a good baseline deployed, then you can expand the MDM deployment with tighter controls on the devices.
Additional Configuration
I set up a separate section to described how to configure some of the out of scope problems that you may come across. In this section, I have detailed some of the additional customization that you can do. I wanted to provide you with information on the service customization but handle that in a different section so you would not be distracted from deploying the service. Once you have the service in place, you can change the service to match your business needs.
Using Dynamics Groups
You have new users who constantly bring devices to your network, and you are trying to manage those devices. Do you individually create groups for management and manually move users to those groups, or do you use dynamic groups for managing devices? The correct answer is that you use dynamic groups for the management of the devices and users. The reason for this is simple; you have better control of the mobile device policies as devices are added in your network. See Figure 5-112.
Most organizations have some type of functional structure in place; in our case we have the engineering, sales, marketing, security, and service departments. Looking at the device types in the organization, we have Android devices, iOS devices (phones and iPads), Windows 10 devices, and unknown devices. Instead of manually adding the groups, we are going to set up the groups for dynamic enrollment. The initial policy we are using will be simple, but you will be able to use this model and expand the group model based on your business needs. In our case, we are setting up the dynamic enrollment for the management of our environment. We will walk through the process of creating dynamic enrollment groups for devices and users for our iOS group and for our service group. You can repeat this process for the organization as needed for other devices and users.
Step 1: Set Up a Dynamic Device Group: iOS
Go to https://portal.azure.com, select the group, and add a new group called MDM iOS Devices Staff. In our organization we have two classes of iOS users - Staff and Management. The capabilities are different, and the controls are different. That is why we set up two different groups, in addition to our test group (non-dynamic group). This allows us to manage our compliance requirements.
The groups are set up as dynamic groups. Looking at Figure 5-113, we have made a decision on the characteristics of the device that we want to use for device auto selection. In this case, we are looking for all devices that are iPhone devices. The expression that is used to find the devices is device.deviceOSType -contains "iPhone" or device.deviceOSType -contains "iOS". You can look up the device parameters, but typically they are iOS, iPhone, Windows, Android, or Other. See Figure 5-114.
Step 2: Set Up a Dynamic User Group: Service
When we add a new user in our organization, we add attribute information about the user. In this case, we assigned the user to a department (service, security, engineering, sales, marketing, or executive). The user in our Azure AD is assigned to a functional department. When we hire, transfer, or fire folks, we will make adjustments in the records, and this in turn adjusts the rights in the organization. If we remove a user from the functional organization, we have to remove their privileges from the resources that they were accessing. I use department as a filter (like iPhone earlier), and the user was assigned to the correct functional group (see Figure 5-115 and Figure 5-116).
Software Updates: Office Pro Plus
Office Pro Plus updates can be managed through Azure deployment. The management process is simple; you can use an Office deployment group, or you can allow Intune to manage the deployment for all enrolled devices. The model that we are using here is to allow Intune to manage the deployment for all enrolled devices. This means when you use your Office 365 account to enroll your device (either through a hybrid join or an Azure join), the device becomes an enrolled device, and the management of the device is subject to the MDM deployment. See Figure 5-117.
In our case, what this means is that we will deploy the necessary updates and configuration changes to the device when the device is enrolled in our company’s Office 365 account. When a user leaves and we remove the user, then the access to the company’s software and resources will also be removed. Let’s walk through the configuration process of adding a controlled software update process for Office updates.
Step1: Add a New Office Deployment Group
Click + Add to add a new deployment group. Click Office 365 Suite – Windows 10 (see Figure 5-118). Select the suite as indicated. This will set up additional configuration options for Office Pro Plus deployment. In our case, we want to enable updates but not force deployment of the software.
We are going to select the Office apps that are used in our deployment. This should look like Figure 5-119. The reason for this is that we are going to manage the updates for all connected devices). Click OK once the selection is completed.
We need to define information associated with the update for the desktop suite. Click OK once the selection is completed (see Figure 5-120).
Our goal is to put in place an update policy for all Microsoft Office applications that have been deployed. This way we can ensure that all users have the latest software on their managed device, independent of our MDM or MAM/WIP deployment. The update channels are listed in Figure 5-121. Take a quick look at the chart so you understand the update process. We are going to use a Monthly Channel update for our Office updates.
The next step is to click the channel for the update. As part of the process, you also want to set up device management to remove the previous version of the Office software and automatically accept the license agreement. Configure the updates like in Figure 5-122. Click OK when completed and then Save.
After you have clicked the updates, the next step is to click who the updates are supposed to apply to. In this case, all updates will be applied to all users or to one of our Office test groups. If you have a mixed environment with kiosk users (no desktop software), you will need to create a separate group. In their case, you will use a dynamic group and pick the users based on the license type that they are using. If the user is provisioned with Pro Plus, then set the dynamic group to only deploy Pro Plus to those licensed users.
In this case, we will select the required option and the “All users” group (see Figure 5-123) to set up the deployment groups, click Assignment, and then click “Add group.” The assignment type is required. Click “Make this app required for all users.” This will deploy the Office software to all connected devices that meet our criteria.
You can make this have a smaller granularity than all users. Keep in mind that if a user opens Office and is not licensed, the software will exist after loading. Each organization is different on the types of software to deploy and the business, so be careful on how you push the software out to the clients. Our objective here is to make sure the client systems are using the latest version of software to reduce the support cost.
At this point, the configuration is complete. The next step is to verify the deployment and see if we have any system errors.
Step 2: Verify That the New Office Software Has Been Installed
The Office deployment software installation will need to be checked for errors. In Figure 5-124, the Office software tried to push an update out to the client, but the updates failed because the Office software was open on the desktop.
In Figure 5-125, we have two systems installed. The one system that had an error now has a valid installation, and the second system’s installation is pending. To see the error, move your mouse over the error.
Software Updates: Windows 10 Update Rings
Once you have set up your dynamic teams and dynamic device groups, the next step is to set up the Windows Update rings. What we do is assign the update rights to all detected members in our company. If you are running Windows Insider, you need to set up the condition in the dynamic group to separate the Windows Insider users from the dynamic users. In our update case, here we are using all user groups to manage updates corporate-wide.
Step 1: Set Up the Software Update Rings
The software update ring group was added to the Azure dashboard. Click Intune, click “Software updates,” and then click “Windows 10 Update Rings.” In Figure 5-126, we have our Windows 10 update group. In our case, our Windows 10 update group is set to all users (similar to the Office Pro Plus update group). You can set up multiple groups, and how you set up groups is dependent on the license type. You cannot mix devices and users in the same group.
Office 365 Windows 10 licenses come in two flavors: device licenses and user licenses. The test subscription we are using is Microsoft 365 E5, and this is a user license. To set up a group, click Intune, click “Software updates,” and then click Windows 10. Then click Create.
The key to picking an update strategy is to understand the update channels. The standard update channel that you want to use is the semiannual targeted. This will give you the standard updates on a released schedule. The update options are listed in Figure 5-127. If you have users in different update programs, you will need to configure a service channel for them and adjust the dynamic group.
The update configuration that we are using in our deployment is shown in Figure 5-128. Click these options and then click OK; then save and create the policy.
In our case, we are not using a Windows 10 Insider group, so we assign the update policy to all users (see Figure 5-129).
As users join the organization, our dynamic group is automatically updated. You can easily make changes in the update policy. In our case, we created another group for all users that we managed the Windows Update and a Windows 10 insiders group. Our Windows Insider group is a static group, since the users need to be manually added and managed. See Figure 5-130.
Step 2: Check the Update Status
Once you have deployed the updates to the device, you can easily check the status of the deployment. Just click the overview to see the status of your Windows 10 deployment update. You will see the status of your deployment (see Figure 5-131).
Legacy: Password Multifactor Authentication
Microsoft has not removed the legacy multifactor authentication. I included this here as a reference, but it is recommended that you use the Azure multifactor authentication. The Azure process based on Office 365 has integrated multifactor authentication with Azure. All administrators are enabled by default. When you enable a user for multifactor authentication, the user needs to have two forms of identity.
We recommend that you check the user status before you enable MFA at https://aka.ms/setupsecurityinfo (see Figure 5-132) or use https://myapps.microsoft.com (MS moves the url around, so you may find one URL works and the other does not). Our desktop systems in this example are Windows 10 Pro (or Enterprise) systems are linked to Office 365 via Azure Join. What this means is that the “password reset of MFA” action will affect the user desktop device. The user desktop is using Office 365/Azure identity to manage the security.
There are two different types of multifactor authentication: Office 365 and Azure. Office 365 MFA is enabled on certain subscriptions and is in place for all administrators. Azure MFA is set up for all accounts with Azure Identity Plan 2. In a previous chapter, we discussed the Microsoft Enterprise Mobile + Security suite MFA configuration. In this section, we will look at the Office 365 MFA deployment. We will deploy the Azure EMS Identity solutions versus the Office 365 MFA.
Multifactor authentication uses a secondary device (such as your smartphone) to supply you with additional login information for a Microsoft service. To use multifactor authentication, log in to Office 365 with your username and password. The Microsoft Office 365 service prompts you to enter a PIN (usually six or eight digits). The PIN comes from three different sources.
Microsoft calls your cell phone and supplies you with a number.
Microsoft texts your cell phone with a number.
You supply a PIN from your smartphone via the authentication app.
The PIN is unique and has a short lifetime. You use this PIN to log in to the Office 365 service (see Figure 5-133).
There are two ways that you can set up multifactor authentication: log in to https://portal.azure.com (described in Chapter 2) or log in to Office 365 (if not using EMS/Intune) and click Azure Multifactor (click Grid and then Admin ➤ Admin Center ➤ Service & Add-ins ➤ Azure Multifactor, as shown in Figure 5-134). The services are similar in some respects but different. Office 365 is a basic service (like what Apple deployed for iCloud), or there is an advanced service that is part of the Enterprise Mobility + Security (EMS) suite. The main difference is that it is an enabling/disabling function, where the Azure EMS identity allows you much more customization of the MFA features.
Note
If you are planning to use MFA across the organization, the best approach is to use an EMS E3 or EMS E5 subscription. This service is more robust than the base service supplied in Office 365.
Setting up multifactor authentication is straightforward. Click the link Manage Multi-Factor Authentication. Office 365 will direct you to Azure to authenticate your credentials. All user identities are managed in Azure. To set up multifactor authentication on a user account, follow the next steps.
Step 1: Enable the Users
Select the user to enable multifactor authentication for, and set the policy (see Figure 5-135). Then click Enable to set up the multifactor authentication properties.
Step 2: Set Up User Credentials
After you have enabled the user (click “enable multi-factor auth”), have the user log in to Office 365 to set up the credentials (see Figure 5-136). If you want to set up the credentials for the user, you need their smartphone and login credentials for Office 365.
The next time the user logs in to Office 365, they are informed of the setup to the new services (see Figure 5-137).
Step 3: Authenticate Smartphones
Azure is used to authenticate the service for Office 365. The authentication service is an international service and requires that you own a phone that can receive a text message for login or can install an Office authentication app on your smartphone. You need to pick the service that makes business sense (see Figure 5-138). If your phone does not receive text messages, you can elect to have Microsoft call you in your native language.
Once you have verified your smartphone with Microsoft, you are supplied with a security token to allow your mobile device to access the Office 365 account. This passcode is unique and is used to configure mobile applications that do not use two-factor authentication (see Figure 5-140). Use this passcode as the new password for your mobile applications that access Office 365 services. Click Done when completed.
Step 4: Test the Service
Log in to the Office 365 service at https://portal.microsoftonline.com. Office 365 will text or call your cell phone with the authentication password (see Figure 5-140).
Summary
This chapter focused on setting up Mobile Application Management and Mobile Device Management. We looked at the different configurations and how you set up software upgrades for Windows 10 and the Office 365 software. MDM deployment is a process. Make sure your deployment focus on MAM (and WIP) deployment with continued compliance check process before you deploy MDM. I introduced you to dynamic groups as a management tool for Mobile Device Management and Mobile Application Management. At this point, you have the security configuration in place for Office 365 and Azure. The next step is to look at the different tools for compliance and eDiscovery. We wrap up the book with a chapter on migrating to Office 365 (for those who are still contemplating moving to Office 365).
References
We covered a lot of information in this chapter. My goal was to give you an overview of the various components to give you a head start on the configuration of protection management and security. If you follow the steps discussed in this chapter, you will be able extend the capabilities of your security deployment. Here I list some links that will assist you in getting to the next level of securing your Office 365 and Azure environment.