EMS: From SME to you

Manage Mobile Browser Access | CA Scenarios for Success (4 of 4)

Sarah L Handler — Wed, 11 Jul 2018 16:32:09 GMT

Today we are back with the final installment of our four part series on conditional access scenarios for success! We often hear from our customers that they want to give end users flexibility to access corporate resources on the go through their mobile browser, but still need the ability to manage that access and prevent data loss. When users access data through apps that support Intune App Protection, such as the Intune Managed Browser/Outlook/OneDrive, we can enforce policies to prevent data loss; however, up until a few months ago we had no way to force the use of a MAM protected app when accessing web resources. This left customers running the risk of data leakage when users accessed resources through unmanaged browsers such as Safari/Chrome. Thanks to new features of Conditional Access, we can block access to corporate resources on unmanaged browsers (such as Safari/Chrome) and force the use of the Intune Managed Browser! This enables web view of O365 and on-premises resources published through App Proxy to only be available through the Intune Managed Browser where we can prevent data loss with Intune App Protection policies. The additional benefit to end users? True Single Sign-On to Office 365 and other Azure AD applications! When your users access other web applications from the Intune Managed Browser (such as third party federated apps or those you have published with App Proxy), they will be seamlessly signed in to these applications- no username/password prompts. So this is a great improvement in end-user experience and accessing applications that they may need to use on mobile devices!

Scenario Requirements

This scenario requires a single Conditional Access policy along with an Intune App Protection policy targeting the Managed Browser, plus any other applications you want to protect. In our configuration today we focus on ExO/SPO, but you can extend the Intune App Protection policy to ensure the DLP settings are in place across additional applications.

Conditional Access policy
- Policy: scoped to EXO/SPO, targets Browser for iOS and Android, and requires devices use the Approved Client App
Intune App Protection Policy
- Policy: targets the Intune Managed Browser (plus at least one other application*), configured to meet your desired security settings to protect your corporate data (i.e. disallow copy/paste to unmanaged locations, etc)

With these two policies, we lock down web traffic to corporate resources on mobile devices to the Intune Managed Browser, and then use Intune App Protection to ensure that the applications are managed with the application controls. This enables a managed experience when accessing corporate web resources, while also providing an improved end-user experience with SSO via the Managed Browser!

Configuration Steps

Create the Conditional Access policy that targets EXO/SPO to force users who are accessing these resources via the Web are doing so via the Intune Managed Browser

Create an Intune App Protection policy that targets the Intune Managed Browser and any other apps you plan on protecting

*NOTE: The Intune Managed Browser cannot be the only application you target with this policy. It does not have the ability to communicate with the App Protection service on its own, so a user will need to set up another managed application before the Managed Browser will receive policy Once you have completed these two steps, you are ready to move on and start testing this scenario.

End-User Experience

Let's take a look at what the end-user experience looks like after you implement this scenario. When a user opens the native browser on their device and tries to access Exchange Online or SharePoint Online/OneDrive content, they will see a message redirecting them to the Intune Managed Browser. To access the desired corporate resource, they simply click on "Launch in app" button and are seamlessly redirected if they already have the app installed. If they do not yet have it installed, there is a link they can click that will take them to their device's app store to download the application. The first time users launch the Managed Browser, they will be prompted to install the Microsoft Authenticator application. This is our "broker" application that relays the identity of the application to Azure AD and allows the Conditional Access check to be satisfied. You can read more about "broker" apps and the entire validation process here. The Authenticator app also provides SSO inside the Managed Browser for end-users. So once this app is installed and configured, they will be able to seamlessly sign in to Office 365 and other Azure AD web resources through the Managed Browser. Once the Authenticator setup is complete, the end-user arrives at the link they were originally attempting to access in their device's native browser. So you can see below that they have landed in OWA and are successfully seeing their mailbox in the Managed Browser!

In Review

Scenario Goal: Ensure users access web resources (like OWA, SPO, OneDrive, etc) from an app with Intune App Protection applied- the Intune Managed Browser Scenario Scope: iOS/Android Recommended when…

You allow browser access to corporate data on mobile devices
You want to extend Intune App Protection capabilities to the browser

This wraps up our four-part series on Conditional Access and Scenarios for Success. We hope you have found it helpful and now find your environment a bit more secure! Have more questions about securing mobile device access to Office 365? Have you tried out these conditional access scenarios? Let us know in the comments below!

Force Protected Apps or Devices | CA Scenarios for Success (3 of 4)

Josh Douglas — Thu, 28 Jun 2018 13:34:53 GMT

We are back today for part two of our four part series on conditional access scenarios for success. Today, we will discuss how to restrict resource access from mobile devices unless they are managed by Intune (and compliant) or using an approved application (like Outlook mobile). You may want to protect your corporate data, but also want to balance the experience that end-users have while using these protected resources. To do this, customers can leverage Conditional Access rules to go through and secure email access, but give end users a choice on which mail client they would like to use. Many users love using the native applications on their mobile devices to access email, while others may be fine using Outlook mobile instead. We can allow users to access email in the application they want while staying secure. Regardless of the choice your end users make, IT can rest assured that they will be accessing mail in a secure way. In this scenario, your users have two choices:

Use the native mail client, but enroll my device in to Microsoft Intune
Use Outlook mobile with Intune App Protection policies applied to secure the corporate data

This scenario enables users to securely access corporate data from their mobile device while giving them options; IT achieves the sweet spot of securing corporate resource access in a way that promotes positive end-user experiences.

Scenario Requirements

This scenario is simple to fulfill- all it requires is setting up a conditional access policy. That's it!

One Conditional Access policy
- Policy: scoped to EXO/SPO, targets Mobile Apps and Desktop Clients for Modern Auth and Exchange ActiveSync, and requires devices be either Compliant or using the Approved Client App

With this single policy, we target both the modern auth and Exchange ActiveSync channel, ensuring that with either option a user chooses they will be protected (see Additional Options on how to secure Office 365 for how to protect third party apps). This gives end users the flexibility they are looking for, while ensuring that corporate data remains secure.

Configuration Steps

Create the Conditional Access policy to require mobile devices either be enrolled or using an Approved App to access corporate data

Once enabled, this policy will do everything that you need in regards to setting this scenario up.

End User Experience

Let's take a look at how these policies impact the end user experience. When a user tries to set up the native mail client on an iOS 11 device, they will see this message prompting them to enroll in to Intune: Since this is a modern auth client, we stop them before they can even finish setting up the mailbox on the device. The experience differs a bit using the legacy EAS authentication channel, which allows the mailbox to be set up, but quarantines the device in EXO and prompts the user to enroll. That message looks like this: So these are the two prompts your end users may get when you set this scenario up, so make sure that you provide some communications to them on what to expect if they are trying to use the native mail client on their device. If users are using Outlook mobile, they will be prompted to set up the "broker" app on their device based on their device platform. On iOS devices, they will need to install the Microsoft Authenticator app; on Android, they will need to install the Company Portal (so if you are using Intune App Protection for Android today, end users should already have this installed). Part of this process of installing the broker app is also registering the device with Azure AD. The broker app becomes the manager for connections to Azure AD/Office 365 and is in charge of determining that the application trying to connect to cloud services is indeed an approved application. You can read more about this here: https://docs.microsoft.com/en-us/intune/app-based-conditional-access-intune

Additional options to secure Office 365

We have also recently had the option arrive in Conditional Access to block legacy authentication. Until this was available, Conditional Access only worked with modern authentication and EAS clients. We can now block all traffic coming in to Office 365/Azure AD with Conditional Access (including Exchange Web Services, SMTP, POP, IMAP, etc). We strongly recommend you create a simple policy in Conditional Access to target "Other Clients" and block that traffic. This ensures that legacy mail clients using other connection options than modern auth or EAS will be blocked. You can read more about this new functionality here: https://cloudblogs.microsoft.com/enterprisemobility/2018/06/07/azure-ad-conditional-access-support-for-blocking-legacy-auth-is-in-public-preview/

In Review

Scenario Goal: Protect corporate data on mobile device while giving users a choice on how they want to use their mobile device Scenario Scope: iOS/Android Recommended when…

Customers are concerned about protecting mobile access to Office 365
There is an end-user population who uses the native applications today
Customers want to provide options to end-users in how they access Office 365 data

In the next post of this series, we will shift our focus to how we can ensure users are accessing web content via the Managed Browser instead of the native device browsers. Have more questions about securing mobile device access to Office 365? Have you tried out these conditional access scenarios? Let us know in the comments below! -Josh and Sarah

Creating Device Groups Based on User Groups with Graph API

Sarah L Handler — Fri, 11 May 2018 08:59:29 GMT

We are here today with another post that focuses on using Graph API to automate actions in Azure AD! Today, our post will be focusing on how to create device groups that only contain the devices belonging to users in a certain security group. As we talked about in a previous post, dynamic groups are powerful feature in Azure AD that allow you to automatically populate groups based on their user or device attributes. We oftentimes have customers ask how they can create a dynamic device Group based on user groups. In today's Dynamic Device Groups UI, you cannot base the membership of a dynamic device group on the owning users' attributes. However, if you look beyond the UI, we can absolutely achieve this with Graph API!

Today's Goal: Populate a device group with devices belonging to users in a particular security group

To achieve this goal, we have written a script that you can run a few different ways, depending on how you want to populate your device group. We have 3 scenarios…

I want to populate users' devices in to a device group if they are a member of a particular security group
I want to populate users' corporate devices in to a device group if they are a member of a particular security group
I want to populate users' personal devices in to a device group if they are a member of a particular security group

How do I run this script?

First, download a copy of the script from the TechNet Gallery: https://gallery.technet.microsoft.com/Create-Device-Group-Based-73eb063e Once you have a copy, you will need to ensure you have the Azure AD PowerShell module installed. If you do not, you can simply launch PowerShell and run: Install-Module -Name AzureAD You will also need to run this with a Global Admin account to ensure you have the right permissions to achieve everything the script is doing. If you want to try and delegate permissions, take a look at this blog post where I address delegating rights: https://blogs.technet.microsoft.com/smeems/2017/12/18/automate-dep-assignment/#delegate The script written is set up to be run to meet one of these 3 scenarios. Depending on the scenario you want to achieve, you will start script execution a certain way. In the order of the scenarios above…

.\Add-SpecificDevicestoAADGroup.ps1
.\Add-SpecificDevicestoAADGroup.ps1 -CorporateOnly
.\Add-SpecificDevicestoAADGroup.ps1 -PersonalOnly

Depending on how you choose to start the script, that will determine which types of devices the script will find and add to your specified device group. Now that we know how to start the script, let's talk about what to expect when you run it…

So what exactly does the script do?

Once you start the script using one of the options above, a few things happen. The first thing it does is ensure you did not run the script using both the -CorporateOnly and -PersonalOnly switches. If you did, the script will stop right there and inform you that you should start it again and choose only one switch. If you want to run the script and get all devices for users in a group, simply execute it with no switch selected. The next thing it does is ask you two important questions…

Enter the Azure AD user group name that contains the users who have the devices you are adding to a group:
Enter the Azure AD device group name where devices will be assigned as members:

For the first question, you need to specify the AAD group that contains the users who have devices that you want to add to a device group. This group needs to be created in advance of running the script. The name you enter is not case sensitive, and as soon as you enter it we do validation to ensure it is indeed a group in AAD and pull the members from it. For the second question, you need to specify the group that you are using as the destination for all the user's devices. This group needs to be created in advance of running the script. Again, once you enter the name (not case sensitive), we validate that the group does indeed exist in AAD and pull the current list of members in the group. We pull the members in this group so that way we can check that devices we find for users in the first group are not already members of the destination group. Once we have this info, this is where we start pulling devices from Intune and adding the AAD object to the destination group you specified. We do some validation to ensure that when we try to add the device that it does not already exist. Below are some screenshots that show the 2 experiences for what can happen with a device…

Device does not already exist in the Device Group (destination)

Device does already exist in the Device Group (destination)

There is also the scenario that a user in the group does not have any Intune registered devices. If this happens, you will see this output: Once the script finishes executing (as long as we added at least 1 device to the group, or 1 device existed in the group) you will get a summary of the number of devices that were added to the group, and also the number of devices that already existed in the group. That output looks like this: You can then go and check out your group in AAD, and see that the devices you added are indeed now included in the group:

Bringing It All Together

You now have everything you need to download the script and start creating device groups based on the membership of a security group. You can run this script as many times as you need, and we will handle ensuring that the appropriate devices are added to the group you specify, and if they are already there, we will let you know directly in the PowerShell window. So feel free to start using this to build your device groups based on security group membership! To ensure that this script updates the group membership as users get new devices, you can create a scheduled task to ensure that the script runs every day. We covered how to set this up in one of our previous blog posts here: https://blogs.technet.microsoft.com/smeems/2017/12/18/automate-dep-assignment/#create If you are interested in learning more about automation opportunities with Intune, go check out our PowerShell samples on Github: https://github.com/microsoftgraph/powershell-intune-samples The script written today started by downloading a sample and modifying it to meet our needs: https://github.com/microsoftgraph/powershell-intune-samples/blob/master/ManagedDevices/ManagedDevices_Add_ToAADGroup.ps1 These samples can be very handy in putting together scripts that will help with your automation opportunities. Looking for guidance on how to automate other Intune and AAD actions? Let us know in the comments below. Happy scripting! -Josh and Sarah

Protect Unmanaged PC Access | CA Scenarios for Success (2 of 4)

Sarah L Handler — Wed, 02 May 2018 09:31:52 GMT

We are back today for part two of our four part series on conditional access scenarios for success. Today, we will discuss how to restrict unmanaged PCs from accessing corporate resources. We often hear that organizations want to empower their employees to be productive, even on their personal PCs- but that they need to do so in a way that prevents users from leaking their corporate data. We find that most want to enable full resource access (such as through thick clients) only from corporate PCs where they have the capability to wipe/manage that data. However, they still need to provide some access from personal PCs- which we can accomplish by enabling browser-only access with MFA enforced for personal PCs, providing a more limited (yet still protected) experience. Today, we are going to focus on implementing this for SharePoint Online and Exchange Online, since we see most organizations focused first on protecting mail and files, but you can extend these policies to other corporate resources as well. This scenario enables personal, unmanaged devices (non domain-joined) to access their corporate resources through the browser only with MFA controls, while allowing only domain-joined (corporate) devices to access corporate data using thick clients. Additionally, we can use SharePoint session controls to enforce restrictions for browser access on personal PCs, preventing users from downloading/printing/syncing their files.

Scenario Requirements

This scenario is simple to fulfill- all it requires is setting up two conditional access policies, enabling SharePoint session controls, and configuring Hybrid Azure AD Join for your domain-joined devices. Let's dive a little deeper into these requirements before we begin setting up the CA policies!

Two Conditional Access policies
- 1st Policy: scoped to EXO/SPO/etc., that targets Client Apps and requires devices be Domain Joined to access. This policy will prevent non-domain joined devices from accessing ExO/SPO through thick clients.
- 2nd Policy: scoped to EXO/SPO/etc., that targets the Browser, excludes Trusted Networks, and requires MFA and Session Controls to access. This policy will allow browser-only access to ExO/SPO for personal devices and will force them to complete a MFA prompt before being granted access. For SPO, additional controls will be in place to prevent downloading/printing/syncing.
- For Conditional Access policies to take effect, you also need to ensure the targeted users have Azure AD Premium licenses assigned.
Access control restrictions enabled in SPO (required for Session Controls to work)
- In the SharePoint admin center under "access control" we will "allow limited, web-only access" for unmanaged devices
- NOTE: When you enable these access controls in the SharePoint admin center it automatically creates two conditional access policies in Azure AD that by default apply to all users. You have two options: you can either modify the auto-created policies to target the specific security groups you want to receive this policy and add ExO as a targeted cloud app. Or, you can delete the auto-created policies and follow the configuration steps below to create them.
Hybrid Azure AD Joined Devices
- In order for conditional access to consider a device "Hybrid Azure AD joined", it must be a Windows device that is joined to an on-premises AD and registered to Azure AD using Hybrid Azure AD Join. Follow the straightforward instructions in this doc to get Hybrid Azure AD Join configured for your devices.

Configuration Steps

To configure the two conditional access policies, simply follow the configuration outlined in the screenshots below. Policy 1- Enabling thick client access for only domain joined devices (effectively blocking thick client access for personal, non domain-joined devices) Policy 2- Enforces MFA to access ExO/SPO through the browser on personal PCs, with additional session controls for SPO.

End User Experience

Let's take a look at how these policies impact the end user experience. When we try to access the Teams client on an unmanaged device (which honors CA policies targeted to SPO), end users will be blocked and notified that they need to be domain joined. On that same unmanaged devices, if we try to access OneDrive through the browser we will see this limited experience enforced by the SharePoint Online session controls. The banner on the top of the page notifies the end user that they can't download/print/sync using this unmanaged device. This enables your end users to stay productive by accessing and editing documents, while preventing that corporate data from leaking to this unmanaged device.

In Review

Scenario Goal: Allow only Domain Joined devices to access corporate data using thick clients, but restrict unmanaged device access to the browser with MFA Scenario Scope: Windows PCs Recommended when…

You want to enable remote access to web resources on personal PCs
You only want full resource access from corporate PCs
You want a strong, yet flexible, security posture for Windows PCs

In the next post of this series, we will shift our focus to protecting corporate data on mobile devices. Have more questions about protecting unmanaged PC access? Have you tried out these conditional access scenarios? Let us know in the comments below! -Sarah and Josh

Conditional Access | Scenarios for Success (1 of 4)

Sarah L Handler — Wed, 11 Apr 2018 14:07:31 GMT

Hello folks! Conditional Access is quickly becoming one of the most popular features our customers want to implement- it allows you to secure your corporate resources (such as Office 365) with quick and simple policies. We have identified 3 common scenarios that customers implement using conditional access. These scenarios secure your environment from different angles, enabling more holistic coverage. These are by no means the only policies that you can or should implement, but we have found them to be successful in addressing the most common customer scenarios we see. This post is the first installment of a four-part series on securing your environment with these conditional access scenarios. In this series, we will identify the requirements for each of these scenarios and cover configuration steps so you can implement them in your environment. In today's post, we will introduce the three scenarios, their goals, and when they may be appropriate for you- stay tuned for posts on how to enable these scenarios in the coming weeks!

SCENARIOS

Restrict Unmanaged PC Access

Scenario Goal: Allow only Domain Joined devices to access corporate data using thick clients, but restrict unmanaged device access to the browser with MFA Scenario Scope: Windows PCs Recommended when…

You want to enable remote access to web resources on personal PCs
You only want full resource access from corporate PCs
You want a strong, yet flexible, security posture for Windows PCs

Enforce Protected Apps or Devices

Scenario Goal: Enable users to access corporate data on their mobile devices in a way that you can protect and wipe. You want to ensure users are accessing corporate data in Office 365 using either an Intune managed device (MDM) or using an application that supports Intune App Protection policies (MAM). Scenario Scope: iOS/Android devices Recommended when…

You need to protect mobile access to Office 365
You allow end-users to access corporate data using their personal devices
You have an end-user population who uses native email apps today
You want to provide options to end-users in how they access Office 365 data

Enforce Managed Browser/Manage Mobile Browser Access

Scenario Goal: Ensure end-users access web resources (OWA, SPO, app proxy published resources, etc.) from an app with Intune App Protection policies applied the Intune Managed Browser Scenario Scope: iOS/Android devices Recommended when…

You allow browser access to corporate data on mobile devices
You are already using Intune App Protection for Office 365 apps
You want to extend Intune App Protection capabilities to the browser

In the next few weeks we will talk more in depth about the steps required to enable each of these scenarios. Have questions? Let us know in the comments below!

Automating Stale Device Cleanup with Graph API

Josh Douglas — Wed, 07 Mar 2018 16:51:41 GMT

We are back with another post today on how you can use Graph API to automate actions in Intune. We hear from a lot of customers that they want to automatically clean up devices that have not checked in with Intune in 90 days. Since Intune is built on top of Graph API, we can automate this pretty easily.

Today's Goal: Wipe devices that have not checked in with the service for 90 or more days.

Why Should I Automate Device Cleanup?

Well, there is nothing saying that you have to… but if you are anything like us, it is nice to keep our tenant records clean. Sometimes devices stop checking in or are no longer managed, but their record stays around in the Intune console. This can inflate the reported number of devices being managed by Intune, and potentially even cause you to see duplicate records for the same device. Through automating device cleanup, you can run the below script to (1) go through and get a list of all of your devices that have not checked in for 90+ days, and then (2) determine if you want to proceed with retiring all of those devices from the Intune console.

How Do I Run This Script?

Download a copy of the script from the TechNet Gallery. You can find it at this link: https://gallery.technet.microsoft.com/Script-to-Remove-Stale-8328aca0

Ensure that rights have been delegated so the service account (if you are not using a Global Admin for this task) has permissions to execute actions via Graph API. We discussed more details on this in a previous blog post. For more detail here about setting up a service account and granting rights for it to execute actions against Graph API: https://blogs.technet.microsoft.com/smeems/2017/12/18/automate-dep-assignment/#delegate

Set up your method for authenticating to Graph API. Review the aforementioned blog post for steps to determine how to set up your authentication file: https://blogs.technet.microsoft.com/smeems/2017/12/18/automate-dep-assignment/#set

Open the script and search for #update before running. This will allow you to specify your username and the path to the secure password file on your machine. Remember, when you generate the secure password file it is only valid on the machine it was created on. So, you cannot move it to other machines and run the script without creating a new password file.

So What Does This Script Do?

The script first returns all of the devices that have not checked in with the Intune service for 90 or more days by calling Graph API. Once we have all of these device records, we ask for admin input on a few items…

We first ask if you want to see all of the returned devices right in the PowerShell window formatted as a table. This allows you to quickly view the devices returned, and may be better used if you do not think there are many devices that fit the criteria of not having checked in for 90+ days.
We then ask if you want to export device info to a CSV, that way you can further review the devices that have not checked in within 90 days. When this CSV is created, we check to see if there is a file path at "C:\temp", and if not, we create a folder there and then create the CSV in that location.

***Proceed with caution! Read the below IMPORTANT NOTE before completing step 3***

Finally, we verify that you are indeed ready to start removing these stale devices. When you go forward with this, we first issue a "Retire" command, and then we follow up with a "Delete" command for each device in the returned devices from Graph API.

IMPORTANT NOTE: Once you continue with step 3, there is no going back. The devices that were returned initially will be retired/wiped, meaning they will be removed from Intune. Ensure you are ready to do this. We recommend you review all of the devices returned and make sure that you do indeed want to remove them. We recommend you run this script manually each time and do not set it up to run in a Scheduled Task. By running it manually you can ensure that nothing is removed that you do not want to remove. The other great thing about Intune being built on top of Graph API is that we have full auditing capabilities. So whenever you run this script, you can then look at the Audit Logs in Intune and see that the devices were retired and deleted. Here is a screenshot of what these logs look like after running the script: We capture the date, who initiated the wipe, and what the activity was on the device. The two records in the screenshot above represent the running of this cleanup script and removing a stale device that had not checked in since November of last year. So even though you are executing these actions via PowerShell, you will still have an audit trail.

Bringing It All Together

You now have everything you need to download the sample script and remove any stale devices that may be lingering in your tenant. Again, execute this script with caution because it can remove a large number of devices. Review the exportable CSV to ensure that everything being removed from Intune lines up with what you are looking to accomplish. With all of these things in mind, you should be able to clean up your tenant and get rid of those pesky, stale device records! If you are interested in learning more about automation opportunities with Intune, go check out our PowerShell samples on Github: https://github.com/microsoftgraph/powershell-intune-samples The script written today started by downloading a few of these samples and modifying them to achieve our needs. The two base samples used were:

Authenticate from a File: https://github.com/microsoftgraph/powershell-intune-samples/tree/master/Authentication
Invoke a device action: https://github.com/microsoftgraph/powershell-intune-samples/blob/master/ManagedDevices/Invoke_DeviceAction_Set.ps1

These samples can be very helpful in putting together scripts that will help with your automation opportunities. Looking for guidance on how to automate other Intune actions? Let us know in the comments below. Happy scripting! -Josh and Sarah

The Magic of Dynamic Groups

Sarah L Handler — Thu, 01 Feb 2018 11:57:25 GMT

One request that we commonly hear from our customers is that they want to simplify the management of resource access and policy assignments for their end users. Today, you may be spending time manually updating group memberships or reassigning resource access when an employee moves to a new location, gets a new device, or has a new job title. As long as these attributes are syncing to Azure AD, we can automate this process using dynamic groups in Azure AD! Today we will cover the basics of dynamic groups and how to implement them for common scenarios we hear from customers.

What are Dynamic Groups?

Simply put, dynamic groups are automatically populated groups based on user or device attributes in Azure AD. For example, if you want a group of all your users in Chicago, you could create a dynamic group with a rule for users in that city. When a user's attributes change, they will be automatically added or removed from a dynamic group. In our example, if Mary lived in Chicago and then moved to Phoenix, once the city attribute changes she will be automatically removed from the Chicago group! Admins have two options when creating dynamic groups: dynamic device groups or dynamic user groups. It's important to note that you can't create a dynamic group that has both user and device objects. Additionally, this feature does require AADP P1 licensing. Dynamic groups become more powerful when you combine them with the other EMS features, such as group-based licensing, conditional access, and Intune. When you use dynamic groups for policy or license assignments, you ensure that your users will get the appropriate access and policies based upon their attributes. In our above example, if you were automatically giving access to a SaaS app and assigning an O365 license to the dynamic Chicago users group, then when anyone moves to the city and their AAD attribute is updated they will automatically be assigned licenses and access.

Set-Up Basics

To set up a dynamic group, we will start in the Azure AD blade of the Azure portal.

Select "Users and groups", "all groups", then select "+New group" at the top of the page
Select either "dynamic user" or "dynamic device" as the membership type
Construct your query. You can use the drop down menu to create a simple rule or select advanced rule to write one yourself
To save the group, click "add query" then "create"

Check out the full list of attributes you can use to create groups for user and device objects. For more information on constructing advanced rules you can reference this doc.

Common Scenarios

All Guest Users

A dynamic group for all guest users can be helpful when securing guest access to your corporate resources. With a dynamic group of all guest users, you can then apply conditional access policies forcing them to MFA, block access of corpnet, etc. More info on how to enable conditional access for these users here. (user.userType -eq "guest")

Advanced User Group

There may be occasions when you need to create a group based upon multiple user attributes, such as country and department. For example, you could create a group of all the IT users in the US who are not in the IT department. (user.country -eq "United States") -and -not (user.department -eq "IT")

Corporate/Personal Device Groups

When using Intune as your MDM, you may want to easily target different policies to corporate and personal devices. This is especially helpful if you have users with both corporate and personal devices- by using device groups you can apply different policies/apps for their devices depending on ownership. To differentiate between the devices we will create two dynamic device groups. Unlike assigned groups, these groups won't be populated until the device finishes Intune enrollment and registers with Azure AD. It is normal for Intune policies to take a little longer to apply to these groups since the dynamic group population takes time (typically under 30 minutes, by up to 24 hours for larger directories). (device.deviceOwnership -eq "Company") (device.deviceOwnership -eq "Personal") NOTE: All devices in Intune are automatically labeled "personal" unless they: 1) Came in through DEP, 2) Were pre-declared as corporate, or 3) Had the ownership changed by the admin in the portal.

What Next?

Once you start building dynamic AAD groups you will find how many activities you can automate when leveraging all of EMS. Do you have more group related actions that you want to automate? Let us know in the comments so we can cover them in future posts! -Sarah & Josh

Automating Intune DEP Profile Assignment

Josh Douglas — Mon, 18 Dec 2017 12:01:05 GMT

Update: As of April 2018, we have started rolling out our new DEP experience in Intune. Once your tenant receives this update, you will no longer need to use Graph API and automation to ensure that the profiles are assigned to DEP devices. Check here to determine if your tenant has been updated based on the UI you see: https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-ios Once your tenant is updated you can go through and assign your default profile and new devices will assign it as they flow in to Intune through DEP. Note: The Graph API calls we were using in the script below are also being updated, so the process below will no longer function once your tenant is upgraded to the new DEP experience. If you did set the automation described in the post below, you can simply go and remove the scheduled task you created so it no longer runs daily. With Intune's migration to the Azure portal, the default Device Enrollment Program (DEP) profile functionality was eliminated. While this prevents unintentional profile assignment, we heard from customers that they want to automate the assignment of enrollment profiles. Thanks to the Microsoft Graph API, you can do just that! Keep reading to find out how you can automate this in your environment and save your Help Desk and Intune admins a lot of time!

Why Should I Automate DEP Profile Assignments?
Configuration Steps
What Else Can I Do with Graph API?

Why Should I Automate DEP Profile Assignments?

Customers who use Apple's Device Enrollment Program often have new devices flowing in to Intune daily. When this is the case, it can be a lot of work to constantly sign in to the Intune portal and ensure that all of your devices have a profile assigned prior to them reaching your end users. If a device makes it to an end user before a DEP profile is assigned, it will be treated as a standard device and not a corporate-owned DEP device. To help decrease the overhead of ensuring all devices have a profile assigned, you can leverage Graph API to do this work for you!

Configuration Steps

Delegate Rights to Execute Graph Scripts to Non-Global Admins

The first time you run this script if you are using a "service account", you will need to execute another script for this to work properly. By default, non-Global Admins do not have the ability to execute Graph API calls unless a GA delegates rights to them. To allow this account to execute the script, you first must assign it rights within Intune. The easiest way to do this is to assign the account the AAD role "Intune Service Admin" since this will give the account the user rights to execute these Graph API calls. NOTE: You will not want to have this account enforce MFA since you are trying to automate this action. MFA requires user input, so to make this a truly automated task, do not require MFA for this account Next, you need to run the Admin Consent script from our Intune PowerShell Samples site on GitHub. You can find a copy of this script here: https://github.com/microsoftgraph/powershell-intune-samples/blob/master/AdminConsent/GA_AdminConsent_Set.ps1 Tip: You can copy this into Notepad and save it as a .ps1

1. Once you have a copy of the script from the link above, you will launch it with PowerShell. When prompted for the Azure AD Username, enter the UPN of your "service account" to specify this as the account you want to delegate permission to.
2. You will then get a notice that this application needs rights that only a Global Admin can grant. Choose "sign in with another account" and complete sign in with the Global Admin (GA) account
3. Accept the permissions

Once this is complete, you can set up the automated DEP profile assignment.

Set Up the Automation Required to Assign DEP Profiles

There are a few pre-requisites you must complete prior to creating the Scheduled Task that will run the PowerShell script to automate assigning DEP profiles.

Create a secure password file for the service account and store it in an accessible location (i.e. in Documents, Desktop, etc). You can create the secure password file by running this cmdlet in PowerShell: Read-Host -Prompt "Enter your tenant password" -AsSecureString | ConvertFrom-SecureString | Out-File "\credentials.txt"
Download a copy of the automation script here: https://gallery.technet.microsoft.com/Automate-DEP-Profile-0657c740
You need to update three variables in the PowerShell sample. You find these located towards the bottom of the script. Here are the three variables: NOTE: To easily find the variables you need to update in the script, open in PowerShell ISE and search for #UPDATE $User - the username of your service account that will be executing the daily task to assign DEP profiles (NOTE: this account does need admin rights to Intune, meaning it will also need an Intune license) $Password - this is the path to the secure password file that you created previously. It needs to be created and stored on the server that will be executing the daily task. You cannot move this file around to other machines and use it since it only works on the machine it was generated on. $global:profileID - this is the GUID of your DEP profile that you have created in Intune. To get this guid, you must navigate to the Corporate Device Enrollment profile in the Intune portal, and the GUID is located at the end of the URL. Here is an example URL that shows you where the GUID is located: https://portal.azure.com/#blade/Microsoft_Intune_Enrollment/EditAcProfileBlade/overview/profileId/af897c67-05ac-469f-b6c1-64a9fa41eaea
Once you have the script and have saved the updated variables, you will use this to create your Scheduled Task

Create the Scheduled Task

Now that you have your script, let's create our Scheduled Task. You should create this task on a server (or Windows 10 machine) in your environment that is consistently online and available, so that you can ensure the script will run at the same time every day. As a side note, on this machine you will need to make sure you have the latest Azure AD PowerShell module installed. You can install this by simply launching PowerShell as an admin and running this cmdlet: Install-Module -Name AzureAD NOTE: If you are running a version of Windows Server (or Windows) other than Windows Server 2016 (or Windows 10) on the machine you are setting up the scheduled task, you will need to install the latest version of the Windows Management Framework to be able to install the Azure AD PowerShell module. You can download WMF 5.1 here: https://www.microsoft.com/en-us/download/details.aspx?id=54616 This will install the module on the server so that way the automation script for assigning DEP profiles will work. Back on track, here is what we need to do to create the task…

On the machine you have selected to host this, launch the Start Menu and search for "Task Scheduler"
Right-click on "Task Scheduler (Local)" and choose "Create Task"
Give your Task a name and choose which account you will have execute this task -- you will need to choose an account that exists on the machine, choose to run whether logged on or not, and store the password
Set up your Trigger to run this task at a specific time, daily
Choose your Action to "Start a program" and in the "Program/script" field enter "PowerShell". In the "arguments" enter the path to your saved PowerShell script
Click "OK" to finish creating the task. To confirm, you can go to the "Task Scheduler Library" and you should see your task in the list -- it will execute at the time you chose when creating the task
You can test the task by right-clicking on it and then choosing to "Run" it -- this will execute it now and you can then go and view your DEP devices in the Intune portal to confirm you have no unassigned DEP devices (if you still have unassigned DEP devices, this means the script did not execute successfully and you will need to determine why)

NOTE: To easily filter on devices that do not have a DEP profile assigned, follow the instructions on our docs site to do this directly in the Azure portal: https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-ios#assign-an-enrollment-profile-to-devices. By loading the "unassigned" filter, as an IT Pro you can see if even a single device in your environment is missing a profile.

What Else Can I Do with Graph API?

To learn more about the actions you can automate with Graph API, check out our Graph API samples on Github! You can find them all here: https://github.com/microsoftgraph/powershell-intune-samples In this blog post, we used two of the sample scripts from GitHub. You can find both of them individually at these locations: Authentication: https://github.com/microsoftgraph/powershell-intune-samples/tree/master/Authentication Apple Enrollment: https://github.com/microsoftgraph/powershell-intune-samples/tree/master/AppleEnrollment We hope this post helps you and leave us comments if you have questions or feedback! -Sarah and Josh

Protecting Email on Any iOS/Android Device

Sarah L Handler — Wed, 13 Dec 2017 12:02:19 GMT

As organizations are moving their mail to the cloud, we have heard from our customers that they want to easily protect their Exchange Online data on mobile devices. One of the most exciting features of Intune is the ability to protect your corporate data even on mobile devices that aren't enrolled in an MDM. With Intune App Protection (aka "Intune MAM"), we can give employees secure access to corporate data with minimal end user effort. The best part of all? Setting up and deploying MAM can be completed in a matter of hours (and that's with testing)! Today, we're going to cover the basics of Intune app protection, how to get it configured for Outlook, and (most importantly) how to successfully deploy it to your organization.

What is Intune App Protection?

(Already know the basics? Skip down to the "Configuration" section)

Intune app protection applies protection at the app level for iOS and Android devices. If you want to enable your employees to access their corporate email on their personal (BYOD) devices without taking control of the entire device, MAM allows you to manage only the corporate content within targeted apps (such as Outlook). You can use Intune MAM to protect a number of applications, but today we are going to focus on the Outlook app and securing access to email with MAM. The benefits of applying MAM policies?

Minimal end-user set up- If they already have the Outlook app installed, they will receive a one-time pop up to inform them of the new policy. If they don't have it installed already, all they need to do is install the app and log in! (For Android, they also need to download the Company Portal in the background)
Wipe the corporate data- If an employee leaves your organization or loses their device you can wipe the Exchange Online data from the Outlook app!
Prevent data leakage- MAM policies can be configured to prevent cut/copy/paste and restrict Save-As to unmanaged locations
Ensure app-layer protections- Prevent unauthorized users from accessing the application but enforcing a PIN on the Outlook app itself
Protect your employees' privacy and autonomy- MAM is only applied to the corporate account, so you can protect corporate data without touching personal data! Using MAM-only for BYOD devices eliminates the chance that an employee would have their entire device wiped by IT (and lose precious family photos in the process!)

Configuration

To get your app protection policies configured, follow these steps: 1. Identify your target user group(s) For testing purposes, you should identify a group of pilot users. When ready to fully deploy, you can use a broader user group (such as an "all users" group). Make sure that the security group(s) have synced to Azure AD. NOTE: Make sure that the users have an Intune/EMS license! If they don't, you can quickly assign licenses to the groups with group-based licensing. 2. Decide on your policy settings When you create a new MAM policy the settings will have the default values. You should review the available settings and customize them to fit your security requirements.

3. Create the Outlook app protection policies You will need to create two policies: one for Android and one for iOS. Detailed instructions on this with screenshots can be found here When you create the policy you will select the target app(s)- for this example we are choosing Outlook, since we are focused on email access. But you can also select and include other Microsoft apps to expand your protection. Then, configure the policy settings. Once done, make sure to click "OK" to save 4. Deploy the policies Once the policies are ready, deploy them to your pilot user group. Detailed instructions here. After testing with the pilot users, you can deploy to your broader organization by simply selecting the appropriate group(s) under "user groups". However, before you deploy the policy make sure you have communicated this change to your end users (as described in the "Deployment & Adoption" section below). 5. Enforce protection- set up conditional access Corporate email in the native mail apps on iOS and Android cannot be managed or wiped unless the device is enrolled with an MDM. You can prevent users from utilizing native mail apps on personal devices and enforce use of the protected Outlook app with app-based conditional access. App-based conditional access (powered by Azure AD Premium) ensures that only apps which support MAM can access your company data. Note: This will not impact users' ability to access personal email on whichever application they choose. To configure app based conditional access follow these instructions, ensuring that you configure it for "Exchange Online". Wait to deploy this policy until you have taken the end-user notification actions in the below section. Once you're ready, you will add the same group you used for the MAM policy under the "restricted user groups" tab to enforce conditional access.

Deployment & Adoption

Now that you have gotten MAM configured it is time for the most important step… deployment and end-user awareness! As with any roll-out of new technology, it is important that you are up-front with your end-users and help them understand the benefit of this change If you followed the above steps for the configuration, this roll-out will mean that end-users will be empowered to access their corporate email on Outlook for iOS and Android but will be prevented from accessing corporate email in their native mail clients. To inform your end-users of this change, you can use this customizable e-mail template. The template includes instructions on how to set this up for iOS and Android, as well as a field for you to complete which informs them of the deadline to switch to Outlook mobile if they aren't already using it. Once end-user communications have been sent out and you have reached the deadline you specified for end-users to move to Outlook, you are ready to turn on the conditional access policy (step 5 above) You can also post this information internally, so end users have an easy way to learn more about what this means for them and how Intune app protection works. Consider adding information to your internal website on what end users can expect when their Android or iOS app is managed by app protection. Now that you have deployed Intune app protection, you can monitor user adoption from the Azure portal. Congrats-- you can now breathe easier knowing that your corporate email is protected across iOS and Android devices! Questions? Post them in the comments below. -Sarah and Josh

From SME to You

Sarah L Handler — Fri, 08 Dec 2017 16:17:13 GMT

Welcome to "From SME to You- Bringing security to the cloud" with Sarah Handler and Josh Douglas! We are engineers in the FastTrack Center at Microsoft, and spend our days helping customers to secure their cloud services with Enterprise Mobility + Security (EMS). We have worked with a wide variety of customers across industries, and understand the common tasks, challenges, and needs that arise during an EMS deployment. Join us as we team up to bring this knowledge to you! What we do

To save our customers time and money, we enable an accelerated and optimized deployment of Enterprise Mobility + Security. We work hand-in-hand with customers to envision their mobility and security plan, guide their configuration, and drive value as they onboard users. Combined, we have helped over half a million users stay secure and productive across their apps and devices.

What you will find on this blog

Frequently asked questions from our customers
Steps to enable common security scenarios
Tips and tricks on configuring EMS
Resources to drive end users adoption
Common automation scenarios

What content would you like to see? Let us know in the comments below! [caption id="attachment_57" align="alignleft" width="296"] Sarah Handler, Support Escalation Engineer[/caption] [caption id="attachment_65" align="alignright" width="300"] Josh Douglas, Escalation Engineer[/caption]