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.

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.

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 1: Set Up Deployment Groups

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.

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.

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.

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.

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.

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

• Sign-in risk is low (see Figure 5-67)

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

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

   Grant Microsoft access to send user and device information to Apple.

    
2. 2.

   Download the Apple certificate (you will upload this to Intune in step 4).

    
3. 3.

   Enter in your Apple ID so Microsoft can sync data with Apple.

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

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

   Log in to the Google Play store with the login you created earlier.

    
2. 2.

   Select the apps that you want to enable.

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

Click Add (see Figure 5-104).

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

   Click Assignment; then click “Add group.”

    
2. 2.

   Click the drop-down to make the group available for all devices.

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

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.

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.

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.

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