Intune, Azure AD, and Zscaler Private Access

Securing the perimeter has become increasingly difficult with more and more services moving to the cloud and users needing, no, expecting, access from their personal devices. The days of relying on the walls of a network to “trust” access are fading fast, and some would say they’re long gone. This is why organizations are using Microsoft technologies to build out zero trust networks where they rely on device and user claims to evaluate access to resource both on and off network. As I’ve written about in the past, security comes in layers, and zero trust encompasses many layers of security behind the scenes.

Over the past few years, Microsoft has worked with many security and management vendors to integrate with Microsoft Intune and other solutions in EMS such as Azure Active Directory.

The following list is just an example of the many technology partnerships Microsoft has in place today.

To keep up to date with Microsoft security partners please visit: https://www.microsoft.com/en-us/enterprise-mobility-security/microsoft-intune?rtc=1

For this month’s post I’ll focus on Intune, Azure Active Directory, as well as a Microsoft security partner, Zscaler, particularly Zscaler Private Access and its integration with Azure AD and Intune.

What is Zscaler Private Access?

According to Christopher Hines, Head of Product Marketing at Zscaler:

“The Zscaler Private Access (ZPA) service provides users with seamless and secure access to private applications without placing them on the network and without exposing apps to the internet. Allowing enterprises to embrace a software-defined perimeter that supports all private apps and environments.”

More details about Zscaler may be found by visiting: : https://help.zscaler.com/zpa/getting-started/what-zscaler-private-access

Before we get started, I want to give special thanks to the following individuals I collaborated with for this post:

    • Tyler Castaldo – Microsoft Program Manager – Intune
    • David Creedy – Senior Product Manager – Web Security
    • Christopher Hines – Head of Product Marketing – ZPA and Zscaler App

Let’s get started

Zscaler SSO Setup

First, we need to set up Zscaler with Azure so we can provide SSO as users access the app. Once the user accesses the the Zscaler App on their device, they’ll be passed through to Azure AD for sign-on.

Setting up Zscaler Private Access (ZPA) requires a few steps so I won’t go through them, however the steps are well documented here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/zscalerprivateaccess-tutorial

In addition, Zscaler has also created their own documentation that may be referenced as well:

Adding Zscaler App to Intune for deployment

For this post I focus on iOS and Android. However, Zscaler is also supported on macOS and Windows 10 (more details at the bottom of this post).

After SSO is set up with Zscaler and Azure AD, we now need to add the Zscaler App to Intune for deployment.

Navigate to portal.azure.com or devicemanagement.microsoft.com and select “Client apps -> Apps”

Select “Add” then App Type and from the dropdown select iOS. Search for Zscaler and select “Zscaler App” as shown below. Add the app and assign it to a group for deployment.

For Android, repeat the steps above, however for the “App type” select “Android“. Use Managed Google Play in the console to search for Zscaler, then add and assign the app to a group for deployment.

Note: if you haven’t set up Managed Google Play with Intune yet, you will find details steps on how to do so by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

When performing a search for “Zscaler” under apps in Intune you should see both assigned apps.

Configuring the Zscaler App using a VPN policy for iOS and app config for Android

Configuring Zscaler Private Access for iOS in Intune is straightforward as Intune has the settings available directly in the Intune adming portal UI as shown below.

Note: the “Organization’s cloud name” is case sensitive and FQDN and key/value pairs are optional, for more details please visit: https://docs.microsoft.com/en-us/intune/vpn-settings-ios#base-vpn-settings.

Select how the VPN will be launched:

Configure additional settings your organization requires to provide access to applications bridged by Zscaler:

For Android, we need to create an app configuration policy and assign it to the Zscaler App we added earlier.

https://docs.microsoft.com/en-us/intune/app-configuration-policies-use-android

Create an app configuration policy by navigating to “Client apps -> App configuration policies”

Select “Add”, provide the policy a name and from the “Device enrollment type” drop-down select “Android”.

Under “Associated app” select the Zscaler App added earlier.

Under “Configuration settings” select “Use configuration designer” from the drop-down and select all the options provided. Select ok to begin configuring the values.

Configure the values based on how your Zscaler environment is configured. In my case, my Zscaler environment is set up in Azure so I utilized the cloud name for the service in Azure as well as the domain my users log into. For username, I selected variable and chose “Partial UPN”.

Once all the settings are configured select “Ok” to complete the setup.

Note: you’ll notice the “deviceToken” value is set to “DummyValue”. This value isn’t needed when Azure AD is used as the identity provider (IdP), however it is needed in the profile, so just add it and type in whatever you like for the value. Also, please note the “Organization’s cloud name” is case sensitive.

After you’re finished with the app config policy, be sure to assign it to the same group you assigned the Zscaler App to.

Client experience

On first launch, the Zscaler App on iOS and/or Android it will redirect to sign-on using Azure AD, however subsequent launches of the Zscaler App will sign-in automatically.

Azure AD Conditional Access

To prevent access to an application Zscaler Private Access is securing access for, we need to create an Azure AD conditional access policy. The Azure AD Conditional Access policy will ensure the device and/or user meets compliance policies (e.g. Intune) before allowing access.

Navigate the Azure Active Directory in the Azure portal and select “Conditional Access”

Provide a name for the policy and under Cloud app add “Zscaler Private Access” and add the Zscaler cloud app used to access resources, i.e. the organization cloud name that points to the app we added earlier. The cloud app I utilize is called Zscaler ZSCloud as shown below.

Select the device platforms to target the Azure AD CA policy, since I’m focusing on iOS and Android in this post, I select iOS and Android from the devices platforms list.

Now grant access if the device is marked as compliant by Intune, enable the policy and save.

Note: additional conditions and access controls may be checked if needed.

If the device is compliant with Intune compliance policies, Zscaler will connect the user to the application. If the device isn’t compliant, Azure AD Conditional Access will block access to the application Zscaler provides access until the compliance issue is remediated.

Note: currently there is an issue with Conditional Access and Android Enterprise where the device is treated as not enrolled.  Zscaler is working through this and we’ll provide an update as soon as the issue is resolved.

Let’s see this in action

I’m testing with my Android device enrolled with Intune under Android Enterprise Device Owner as a fully managed device. The Zscaler Private Access (ZPA) App and ZPA App configuration is automatically deployed.

Intune_Zscaler.gif

Conclusion

In summary we learned how to set up Zscaler with Azure and provide SSO using Azure Active Directory. We also learned how to set up Zscaler Private Access App configuration and app deployment with Microsoft Intune. Finally, we learned how to set up an Azure Active Directory Conditional Access policy to further secure application access with Zscaler based on Intune device compliance.

I hope this post helps you and your organization further secure corporate applications, devices, users, and resources using Microsoft Intune, Azure Active Directory, and Zscaler Private Access. If you’re a Zscaler customer today, go out and give these steps a try.

Appendix

Information on setting up Zscaler for Windows and MacOS

Outlook app configuration – contact field export control

Organizations utilizing the Outlook app on iOS and Android may desire granular control of app behavior such as only allowing certain contact fields to be sync’d with the native contacts app on iOS. Fortunately, Outlook settings are available to further control the Outlook app on iOS and Android.

I’ve worked with organizations who have strict data protection and GDPR requirements and utilizing Intune we were able to protect data from leaking from users’ corporate email to unmanaged apps and storage while allowing limited contact attributes sync’d to the local contacts app so caller ID will show for callers residing in contacts. Some of the restrictions are enforced by the platform (i.e. iOS/Android) while other restrictions are controlled at the app and device layer by Intune.

To learn more about app config with Outlook please visit: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

As you walk through the settings make note of the “Device Enrollment Type” for each configuration setting, e.g. “Managed devices”, “Managed apps”. The device enrollment type corresponds to the Intune “Device enrollment type” setting when adding a configuration policy (see screenshot below). It’s important to understand the differences as there are different settings for different types of profiles and if settings are used for an unsupported profile type, they simply will not deploy to the app. In addition to the contacts settings, there are also account configuration, wearable, and iOS notification settings that can be configured as well.

Let get started

The following example demonstrates syncing only certain contact fields to the local contacts app so the end user will see the caller ID for a contacts for phone numbers when calls are received.

Navigate to the Intune admin portal and select “Client Apps > App configuration policies > Add”

Give the configuration policy a name and select “Managed apps” as the Device enrollment type as I’m pushing this policy via an App Protection Policy.

Select “Associated app” and select Outlook for the platform(s) you’re interested in configuring Outlook for. For “Managed Apps” I recommend using a single policy for iOS and Android to maintain consistency across platforms.

Add configuration settings to configure the app configuration settings for contacts in Outlook as shown below. These are key/value pairs and are documented here: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

I’m only allowing first name, last name, and mobile phone number. If other phone fields are required such as home, office, other, you may want to allow those as well. Note: these fields match up to the existing fields in Outlook contacts and the native contacts app.

Assign the policy to a group of users:

Syncing contacts to the native contacts app

For contacts to show up in the native contacts app, users need to manually select “Save Contacts” in Outlook settings to sync contacts to their device.

Note: if you don’t see “Save Contacts” an Intune App Protection Policy may be blocking contacts sync. To check APP settings install and open the Edge browser and type in: about:intunehelp in the search box and view Intune app status for Outlook. If block contact sync is enabled, it will be set to “1” disabled will be set to “0”. Also, the “Save Contacts” setting cannot be set by policy at this time.

As shown below, only the fields specified in the Outlook configuration policy show up when the contact is accessed from the native contacts app. All other fields are blanked out. Even if I add the additional data to the fields, such as a phone number, the field will show up populated in the native contacts app then disappear when the policy refreshes (the update to the field will retain in Outlook though).

If you continue to see the fields that are blocked, try waiting a few minutes and disabling and re-enabling contact sync in Outlook.

Finally, when the email profile is removed from Outlook so are the sync’d contacts from the native contacts app.

Additional info

For MDM enrolled iOS devices, if contacts do not sync with the native contacts app after going through the steps above, because of certain Apple restrictions, you may need to toggle these settings to “Not configured”. There is a support post on this topic that is worth reading with additional tips: https://blogs.technet.microsoft.com/intunesupport/2018/04/17/support-tip-ios-11-3-and-native-contacts-app/

Android + Intune = Android management

When I speak with organizations who are considering Android devices there’s usually the question of, “which management option should we choose?”. The answer to the question requires a clear understanding of the scenarios the organization would like to bring under management such as personal devices or corporate devices or even purpose-built devices (e.g. inventory scanners, digital signage, etc.).

There are many different versions of Android from many different OEMs and choosing and supporting each version can be challenging. However, as I’ll discuss later in this post, Android enterprise aims to address OEM fragmentation while providing a variety of management options. Fortunately, Microsoft Intune will address various Android management methods available today including those offered with Android enterprise, so let’s look at how Android management is accomplished with Intune.

The table below walks through each available Android device management scenario, how Microsoft Intune supports it, as well as items to evaluate when considering each option.

Device Management Type Enrollment Type Intune Management
Android Device Admin
Considered legacy administration, the Android device administration API has provided APIs to manage the Android device since Android 2.2. The issue with device admin is there are only so many management APIs available, the user experience is challenging, and according to Google, device admin will be depreciated in 2019. With Android Q, device admin will not be available at all.Device Admin requires an Android device to be enrolled via an MDM and requires various administrator permissions during certain enrollment scenarios. As such, device admin offers insufficient privacy for BYOD, insufficient management capabilities for corporate owned devices, and a poor user experience all around. In addition, device admin is less secure than Android enterprise and device admin is not ideal for an environment requiring minimal or no touch enrollment.To learn more about device admin deprecation please visit: https://developers.google.com/android/work/device-admin-deprecation
Intune supports devices enrolled with device admin on Android 4.4+

To enroll a device to Intune using device admin please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-android

In addition, Intune App Protection policies are supported with device admin (or without enrollment): https://docs.microsoft.com/en-us/intune/app-protection-policy

For BYOD, Intune App Protection policies are a great choice as the policies protect the corporate data at the app layer without requiring the user to enroll their device.

Samsung KNOX Standard
With Samsung devices, Samsung added their own management APIs which expands the management capabilities for devices enrolled with device admin.  An example is managing the email profile for the native email app on a Samsung device.KNOX is only available with certain Samsung devices so utilizing other OEM devices would require device admin or Android enterprise.Note: Samsung has announced the unification of KNOX and Android enterprise. More details may be found here: https://www.samsungknox.com/en/blog/android-enterprise-and-samsung-knox-your-questions-answered-hereSamsung also offers KNOX Mobile Enrollment (KME) which allows for automatic enrollment of devices even after a reset. KME is supported starting with Android 2.4 and KME is beneficial for mass enrollment of devices without having to touch each one. Devices may be manually and/or added through a carrier to an MDM. After which, users will experience a streamlined enrollment process which removes the touch points required by device admin.KNOX Mobile Enrollment is only available with Samsung devices so if no touch enrollment is needed for other device OEMs, Android enterprise may be an option.To learn more about KNOX Mobile Enrollment please visit: https://www.samsung.com/us/business/solutions/samsung-knox/mobile-security-solutions/knox-mobile-enrollment/
Intune supports KNOX standard without additional licensing for KNOX. However, KNOX also requires Device Admin enrollment as well. Once a device is enrolled with an MDM the end user will also see prompts about KNOX after which both device admin and KNOX policies may be deployed to the device. KNOX Mobile Enrollment streamlines the enrollment process by enrolling the device automatically.

To learn more about enrolling a device that supports Samsung KNOX with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll#end-user-experience-when-enrolling-a-samsung-knox-device

In addition, Intune App Protection policies are supported with Samsung KNOX: https://docs.microsoft.com/en-us/intune/app-protection-policy

Intune supports KME and to learn more about setting up KME with Intune please visit: https://docs.microsoft.com/en-us/intune/android-samsung-knox-mobile-enroll

In addition, Intune App Protection policies are supported with devices enrolled with KME: https://docs.microsoft.com/en-us/intune/app-protection-policy

Up to this this point we’ve reviewed traditional management methods available on Android as well as enrolling and managing Android devices with Intune. However, if you’ve noticed, there seems to be a theme throughout and it’s around Android enterprise. It appears all paths are leading to Android enterprise so let’s learn about what Android enterprise is and how Intune will assist with managing devices enrolled using Android enterprise.

Android enterprise

There are two primary modes of management under Android enterprise (AE). Work profiles for BYOD and Device Owner for corporate owned devices.  More details on Android Enterprise device ownership please visit: https://developers.google.com/android/work/requirements 

Android enterprise
Android enterprise (AE) offers a variety of management scenarios for certified devices providing more robust management APIs over device admin. Although Android enterprise is supported on Android 5.0+, Google recommends 6.0 or later.Once a device is enrolled in an MDM such as Intune, Android enterprise has the concept of a work profile (formerly Android for Work) that separates or containerizes corporate applications and data on a personal device. The managed profile contains corporate data and allows only applications within the work profile to access the data within while leaving personal data separate. To learn more about work profiles please visit: https://support.google.com/work/android/answer/6191949?hl=enIn addition to work profiles, Android enterprise offers Device Owner mode where corporate owned devices are enrolled with an MDM and managed based on the purpose their intended for. To learn more about Android enterprise management for company-owned devices please visit: https://www.android.com/enterprise/management/To provision the device owner mode the device must be factory reset, unfortunately there are no migration paths to device owner mode from device admin. The provisioning process may be driven by NFC, QR code, or zero-touch. Previous versions of Android such as 5.0 and 5.1 can use an activation code to begin the enrollment process.For more details about device provisioning please visit: https://developers.google.com/android/work/prov-devicesTo learn more about AE management scenarios please visit: https://www.android.com/enterprise/management/Note: as stated previously, moving from device admin to Android enterprise requires a factory reset. Consider the ramifications of already deployed devices to end users and in the workplace before beginning a migration. A strategy of enrolling new devices with device owner while continuing to manage existing devices enrolled with device admin may be an option. Through attrition, devices will onboard using Android enterprise. As mentioned earlier, with Android Q, device admin will not be an option.
Intune supports Android enterprise purpose-built device management including single-use and work profiles which aligns with many organizational use cases.

Details on how to configure Intune to and manage devices supporting Android enterprise are below.

Management of Android enterprise managed profiles and other details may be found here: https://docs.microsoft.com/en-us/intune/android-enterprise-overview

Connect Intune to Android enterprise:

https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

Android enterprise single-use (Kiosk) devices Intune enrollment: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll

In addition, Intune App Protection policies are supported with Android enterprise: https://docs.microsoft.com/en-us/intune/app-protection-policy

Applications, including LOB apps are published through managed Google play.

Selecting an enrollment option

Choosing an enrollment option really depends on the scenario and what your business requires. For example, if your devices require minimal or no touch enrollment you may consider KNOX Mobile Enrollment and/or Android enterprise. Since Android enterprise appears to be OEM agnostic, if the plan is to have various device OEMs deployed, devices supporting Android enterprise may be an option. However, if devices are used for kiosk, digital signage, ticket printing, inventory scanning, Android enterprise would be something to investigate as well. If devices are personal devices (BYOD), I recommend looking at Intune App Protection for unenrolled devices and/or Work Profiles. Lastly, before selection consider the short- and long-term ramifications of one option over another.

That’s it! We’ve reviewed the options available for Android enrollment and Intune, documentation on how to enroll Android devices, and the future of Android management through Android enterprise.

Scan file servers, network shares, and SharePoint with Azure Information Protection Scanner

 

With GDPR just around the corner (May 2018), organizations are heads down identifying data, creating compliance processes, and hiring additional resources to lead the compliance and reporting required by GDPR.

In a previous post I reviewed GDPR as well as the technologies and services Microsoft offers to assist with discovery, managing, protecting, and reporting on data.

For this post I’ll expand on the topic of scanning file servers and SharePoint servers using a the Azure Information Protection Scanner or AIP Scanner.

 

Scanning SharePoint Server and File Shares

Azure Information Protection includes a scanning tool called the Azure Information Protection scanner or AIP scanner.  The AIP scanner is used to comb through file shares and SharePoint and identity and/or classify + protect data.

 

The scanner runs as a service on Windows Server and lets you discover, classify, and protect files on the following data stores:

  • Local folders on the Windows Server computer that runs the scanner.

  • UNC paths for network shares that use the Common Internet File System (CIFS) protocol.

  • Sites and libraries for SharePoint Server 2016 and SharePoint Server 2013.

Source: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner 

 

Once the AIP scanner is deployed, use it to report on information you’re looking for and when discovery is complete, run the AIP scanner and apply classification with or without protection across those files.

The classification labels and encryption policies come from the Azure Information Protection service in Azure.  Labels may be defined with or without encryption.  At a minimum I recommend all information at least be classified.  To learn more about creating classification labels using Azure Information Protection please visit: https://docs.microsoft.com/en-us/information-protection/understand-explore/what-is-information-protection

 

I won’t go through the details of installation process as it’s clearly documented in the link I provide below.  However, the output below is from a scan I completed using the AIP scanner against a few sample files.  The AIP scanner will look for specific information based on the AIP policies that are configured (e.g. credit card info, passport numbers, etc.).

clip_image001

For more information about the Azure Information Protection scanner please visit: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner

 

Automation

To help with automating the AIP Scanner process I created a script to walk through each option.  Feel free to utilize, however keep in mind when new AIP scanner versions are released you may need to update the script to accommodate new features. I also make no guarantees so use at your own risk.

 

#AIP Scanner Script

#Created by Courtenay Bernier

 

 

$AIPScannerLogFiles = $env:LOCALAPPDATA + ‘MicrosoftMSIPScannerReports’

 

#AIP scanner config

Write-Host “”

Write-Host ‘AIP scanner configuration’

Write-Host “”

$ScanMode = Read-Host -Prompt ‘ScanMode: Enforce | Discover’

$Type = Read-Host -Prompt ‘ScanType: Incremental | Full’

$ReportLevel = Read-Host -Prompt ‘ReportLevel: Off | Debug | Info | Error’

$Schedule = Read-Host -Prompt ‘Scanner Runtime Schedule: OneTime | Continuous | Never’     

$JustificationMessage  = Read-Host -Prompt ‘JustificationMessage: Free Text or leave blank’

 

Write-Host “The AIPScannerConfiguration options selected are: ‘$ScanMode‘, ‘$Type‘, $ReportLevel, $Schedule, $JustificationMessage

 

Set-AIPScannerConfiguration -ScanMode $ScanMode -Type $Type -ReportLevel $ReportLevel -Schedule $Schedule -JustificationMessage $JustificationMessage

 

Write-Host “”

Write-Host ‘This is the AIP Scanner Configuration set:’

Get-AIPScannerConfiguration

 

 

 

#AIP scanner repository

Write-Host “”

Write-Host ‘AIP scanner repository’

Write-Host “”

$OverrideLabel = Read-Host -Prompt ‘OverrideLabel: On | Off’

$SetDefaultlabel = Read-Host -Prompt ‘SetDefaultLabel: UsePolicyDefault | On | Off’

$PreserveFileDetails = Read-Host -Prompt ‘PreserveFileDetails: On | Off’

$DefaultOwner = Read-Host -Prompt ‘Specify the default owner by: email address or leave blank’

 

do {$DLID = Read-Host -Prompt ‘Add a default label ID by GUID? Yes or No’ }

until (‘yes’,‘no’ -contains $DLID)

 

if ($DLID -eq ‘yes’)

    {

        $DefaultLabelID = Read-Host -Prompt ‘specify the label GUID found in the AIP label policy’

 

    }

elseif ($DLID -eq ‘no’)

    {

       Write-Host “”

       write-host “No default label ID was added”

       Write-Host “”

    }

 

 

#add file location

$Path = Read-Host -Prompt ‘Fileshare or SPS Path: e.g. F:SharesFileShare or \networkpath or http://sp2013/Shared Documents’

Add-AIPScannerRepository $Path

Write-Host “”

 

 

#ask to add for more file locations

do {$answer = Read-Host -Prompt ‘Would you like to add another file location? Yes or No’

 

if ($answer -eq ‘yes’)

    {

       $Path = Read-Host -Prompt ‘Fileshare or SPS Path: e.g. F:SharesFileShare or \networkpath or http://sp2013/Shared Documents’  

  

       #add file location

       Add-AIPScannerRepository $Path

       Write-Host “”

 

    }

 

else

    {

       Write-Host “”

       write-host “No additional paths were added”

       Write-Host “”

       Write-Host “To remove repositories: use Remove-AIPScannerRepository share/sps path”

       Write-Host “”

       Get-AIPScannerRepository

       Write-Host “”

  

    }

}

Until ($answer -eq ‘no’)

 

 

#set AIP scanner repository

Write-Host “”

Write-Host ‘Setting scanner repository config:’

Set-AIPScannerRepository -OverrideLabel $OverrideLabel -PreserveFileDetails $PreserveFileDetails -DefaultOwner $DefaultOwner -Path $Path -DefaultLabelId $DefaultLabelID -SetDefaultLabel $SetDefaultLabel

 

 

#show file location(s)

Get-AIPScannerRepository

Write-Host “”

 

 

#start AIP scanner service or abort

do {$answer = Read-Host -Prompt ‘Are you ready to start the AIP Scanner Service? Yes or No’ }

until (‘yes’,‘no’ -contains $answer)

 

if ($answer -eq ‘yes’)

    {

       write-host “Starting AIP Scanner Service for ($ScanMode)”

       start-Service ‘Azure Information Protection Scanner’

       Write-Host “”

  

       #Show last AIP events

       Write-Host “waiting for eventlogs to populate”

       Start-Sleep -s 15

       Get-EventLog -Newest 4 -LogName ‘Azure Information Protection’ | Format-List -Property *

       Write-Host “”

  

       #Open Scanner Report Folder

       explorer $AIPScannerLogFiles

       Write-Host “”

    }

elseif ($answer -eq ‘no’)

 

    {

       Write-Host “”

       write-host “Canceling AIP Scan”

       Write-Host “”

       Write-Host “To remove repositories: use Remove-AIPScannerRepository share/sps path”

       Write-Host “”

    }

 

 

Regulations and data management in a hybrid world

 

I speak with a lot of organizations and often they’re interested in locating, tagging, and controlling data for various reasons such as legal, regulatory, or protecting personal and proprietary information.

However, there’s one regulation that keeps popping up and it’s the new EU General Data Protection Regulation or GDPR.  GDPR will be enforced on May 25, 2018, which is just around the corner.  Unfortunately, GDPR is not a one-time process, it’s an ongoing regulation and failure to comply could result in heavy fines.  For most organizations, data may be stored across all types of systems and services including backups so locating and managing data across those environments may be difficult.

For this post, Microsoft provides guidance around GDPR and I’ve utilized some of the terms and guidance provided to simply the overview.

To learn more about how Microsoft is addressing GPDR please visit: https://www.microsoft.com/en-us/TrustCenter/Privacy/gdpr/default.aspx

The categories below align with the Microsoft GDPR guidance provided in documentation above, however I’ve attempted to simplify while targeting Office 365 and Enterprise Mobility + Security.  The last topic I’ll discuss is how to identity and classify information across SharePoint Server and file shares.

 

Let’s take a look at the four pillars of addressing data management requirements:

image

clip_image001[4]

 

Tying everything together, we have a process to identify, manage, protect, and report on data:

clip_image002[4]

 

Now that we have a definable process, let’s align the Microsoft services around all four categories, again the area of focus here is EMS and O365:

clip_image003[4]

image

 

 

Let’s take close look at some of the details across the Microsoft offerings:

Azure Active Directory

  • Lay the foundation for your organization by protecting access to sensitive information, which starts with modernizing your identities with Azure Active Directory. Whether a cloud or on premises application, Azure Active Directory will act as a controlled gateway to your data.

Azure Information Protection

  • Automated Classification, Labeling, and Protection + File scanner for file servers and SharePoint.

Office 365 Data Loss Prevention

  • Identify and retain data by applying retention policies to data across O365 services. Discover data through eDiscovery and actions on data via O365 audit logs.

Exchange Online

  • Prevent data from leaking by creating message rules to stop sensitive information from being sent through email. Ties into Data Loss Prevention as described above.

Microsoft Cloud App Security

  • Discover, monitor access, and apply governance to sensitive data across cloud services.

Microsoft Intune Application Protection

  • Protect information from leaking to non-protected applications and accounts across devices such as iOS, Android, and Windows.

Microsoft Power BI

  • Create insightful and visual reports by importing audit data into Power BI.

 

SharePoint Server and File Shares

I understand the previously mentioned services are great for managing data across cloud services, however what about on premises environments?

Azure Information Protection includes a scanning tool called the Azure Information Protection scanner or AIP scanner.  The AIP scanner is used to comb through file shares and SharePoint and identity and/or classify + protect data.

Once the AIP scanner is installed, use it to report on information you’re looking for and when discovery is complete, run the AIP scanner and apply classification and protection across those files.

Below is the output of an AIP scanner scan I ran against a few sample files.  The AIP scanner will look for specific information based on the AIP policies that are configured (e.g. credit card info).

image

For more information about the Azure Information Protection scanner please visit: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner

 

All the services described above dovetail nicely with GDPR and other regulations requiring control of data.  If you don’t believe your organization is affected by a regulation such as GDPR I highly encourage further research as you may find out that your organization actually is.  Unfortunately, there are steep penalties with non-compliance so doing some research before May will save organizations time and money.

 

Again, to learn more about how Microsoft is addressing GPDR as well as managing data across other services such as Microsoft Azure, Dynamics 365, SQL Server, etc. please visit: https://www.microsoft.com/en-us/TrustCenter/Privacy/gdpr/default.aspx

Windows Information Protection Explained – Windows 10 Creators Update

 

With the release of Windows 10 Creators Update there have been many enhancements to Windows 10. For this post, I’ll focus on an expanded feature that is only available in version 1703 (i.e. Creators Update).

In Windows 10 version 1607 we released Windows Information Protection where devices that are enrolled with Microsoft Intune (or SCCM) may receive policies that protect corporate application content from data leaks. In Windows 10 1703 (i.e. Creators Update) a new feature called Mobile Application Management or MAM is available. If you’re familiar with MAM policies for Intune for iOS and Android we’ve brought similar functionality to Windows 10 Creators Update for non-managed devices. This means that non-managed devices such a home user PC with Creators Update can access corporate data without risking data leakage because the MAM policy will prevent cutting and copying data to unmanaged applications.


Requirements

  • Intune licenses
  • Global Admin for Azure Active Directory
  • Windows 10 Creators Update (any version)

Getting started

Service setup

  1. Navigate to portal.azure.com from a browser
  2. Select Azure Active Directory
  3. Select Mobility (MDM and MAM)
  4. Add or select Microsoft Intune

 

clip_image002

 

Verify the settings look similar to those in the image below. Add a group as well to make sure the policies flow to the proper individuals:

Note: if the MAM Discovery URL is missing, select “Restore default MAM URLs”

clip_image004

Policy setup

From the Azure portal locate the Intune Mobile Application Management (MAM) service. It will look similar to the following:

clip_image006

 

Select “App Policy” and “Add a policy” at the top. Give the policy a name and select Windows 10 under Platform.

clip_image008

 

Now we need to configure what apps the MAM policy will apply to. Do this by selecting “Allowed apps” and then “Add app” at the top of the blade:

clip_image010

Fortunately, many Microsoft applications are already published to select from, for the purposes of this post I’m going to select Microsoft Edge, Notepad, and IE11. The apps in this list are what we call “enlightened apps” where they know about MAM policies. Refer to the links at the end of this post for how non-enlightened apps are supported.

Note: For custom apps, desktop apps, etc. that need to be added, information about these apps is easily found using App Locker via the local policy editor on the device where the apps are installed. More details: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

clip_image012

 

Data Protection

After selecting apps from the list, in my case Notepad, Edge, and IE11 we now need to configure the behavior of when protected data is moved from those apps to non-protected environments (e.g. WordPad).

Select “Required settings” from the policy. The only change I made is to select “Allow Overrides” which means the user will be prompted when they attempt to relocate corporate data outside of the managed app (very similar to how MAM works with iOS and Android):

clip_image014

 

Now move to “Advanced settings” where there are a number of options to further restrict and identify boundaries.  For this post I’ll keep it simple by adding a cloud resource as a network boundary, in this case SharePoint Online and turn on “Show the enterprise data protection icon” for the protected enlightened apps:

clip_image016

Note: Once service and client are configured, you may encounter site access issues, to remediate, add the Value “|/*AppCompat*/” (no quotes) string to the end of the URL string, more details here: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

 

Once the boundaries are set and saved, we need to assign the policy to a group of users.  Feel free to create any group you want in Azure AD, I created one called MAM-WE_Users:

Note: users may be dynamically assigned to Azure AD groups as well for auto assignment to apps, licenses, etc., more details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-with-advanced-rules

clip_image018

Client setup

The end user will need to attach their non-managed (e.g. personal) Windows device with Creator Update to their workplace by selecting “Settings” then “Access work or school” and then “Connect” as shown below.

Note: Non admin users may enroll in MAM.

clip_image020

 

The user will then be prompted to sign on to their corporate account (i.e. O365, Azure AD, Intune, etc. if available) account as shown below (do not join Azure AD or local AD, typically this is performed only for corporate issued/owned devices).

To summarize, there are two steps, add your email and select next.

clip_image022

 

Once the account is verified, and the device is registered, select the account and the Info:

clip_image024

 

The “Info” button will show the last time the device had a successful sync. Also make sure the Management Server Address is populated. Keep this in mind as we’ll refer to this process after we have the MAM policy set up.

clip_image026

End User Experience

Because I’m protecting “.cbenterprisemobility.sharepoint.com” and selected both IE11 and Edge (they’re both enlightened apps) when I navigate to them we see a little briefcase icon show up.  When I navigate away from this site, the briefcase will go away.

clip_image028

clip_image030

 

For example, when I download a file from SharePoint Online, it will contain a little briefcase on the file icon as well as state the ownership of the file in “File ownership” column.  Additionally, the MAM policy can use either a custom EFS certificate or and Azure Information Protection template (RMS) to protect files.

clip_image032

 

When I open the file in a managed app (i.e. Notepad) and because the file is protected by policy, the app shows it’s managed by displaying a briefcase icon on the app itself:

clip_image034

Clicking on the briefcase icon we see the following:

clip_image036

 

When I attempt to cut, copy, and even open the file in an unmanaged app such as WordPad I receive the following prompt.  I can choose to give access in which case that action is logged to event viewer or cancel.  This prompt may be hidden from the user completely by changing the policy in Intune.  Separate policies may also be created and targeted at specific groups of users as well.  For example maybe you want to allow Executives to override as shown below and block certain users such as contractors, etc.

clip_image038

 

Closer look at the prompt:

clip_image040

 

If you need to change the file ownership, I right click on a file and change the file ownership to Personal if needed:

clip_image042

 

That’s all, we configured Mobile Application Management for a non-managed or domain enrolled Windows 10 client and successfully protected corporate content from leaking outside of corporate sanctioned applications.

Troubleshooting

  • First place to look is to make sure the settings are correct and sync’s are successful under Windows 10 Settings/Accounts/Access work or school
  • Next steps are to look in event viewer under: Application and Services Logs/Microsoft/Windows/Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
  • MAM policies also land under: c:windowssystem32AppLocker folder and you can open the “policy” files in notepad.
  • You’ll also find the MAM policy settings populated under the following registry keys: HKEY_LOCAL_MACHINESOFTWAREMicrosoftPolicyManagercurrentdevice
  • When adding apps to protect, the prepopulated apps should be adequate, however if you’re adding protected apps by hand make sure the format is correct or the MAM policy will not take effect on that app.
  • When users upgrade from MAM to MDM on Windows Home edition, they lose access to WIP. On the Home edition, we do not recommend pushing MDM policies to enable users to upgrade.  More details here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/implement-server-side-mobile-application-management

Closing thoughts

With all the data theft that happens daily, it’s better to have increased security for non-managed devices than simply guessing if your data is secure from those devices.  Whether your users have iOS, Android, or Windows devices, Intune MAM will protect all three.

Another option is to block unmanaged devices completely and Azure Active Directory Premium with or without Intune will address this scenario via Conditional Access.

For additional details about MAM with and without MDM as well as supporting desktop and custom apps, please refer to:

Azure AD Geolocation by sign-in activity using Power BI

 

If you’re an Office 365 customer or even an Azure customer then you’re probably familiar with Azure Active Directory (or Azure AD).  Azure AD is the core identity provider that the majority of Microsoft services rely on for authentication.  For today’s post I thought it would be interesting to pull sign-in activity into Power BI and show how simple it is to display a dashboard of geolocated sign-ins by user and device.

 

Assumptions

The user creating Power BI reports has an Azure AD Premium and Power BI licenses assigned

Note, if a new user account was recently created, I recommend waiting a day for the sign-in data to fully populate otherwise no sign-in data will be present.  Check the Azure AD Premium admin portal for sign-in activity for the user periodically.  Once the sign-in data is present, refresh the Power BI dataset connection to pull it into Power BI.  More details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-faq

 

First we’ll need to sign into Power BI and pull in the Azure AD Activity Logs Content Pack.  Do this in Power BI by selecting Get Data, Services (Get), then search for Azure.  Select Azure Active Directory Activity Logs (Preview) from the search results and provide your Azure AD domain name and then select next.

Once the Azure Active Directory Activity Logs (Preview) content is added we can begin to create a dashboard.  From the Power BI UI find the “Azure Active Directory Activity Logs” under Dataset and select it.  Under “Visualizations” select Map and under “Fields” expand “Signin Activity” and select City, Country, Name, and Total Signins.  Without any further modifications your map should look similar to the following:

 

image

 

Feel free to play around with the data to get the information you find most interesting or better yet, what your security team will find most interesting.  Hover over the data circles to display additional information about the data point.

 

Now a map of sign-ins may be all that is required, however I went a step further and created two slicers to drill in on certain data points.  To add slicers, select the Slicer image from under Visualizations from under Fields expand “Unique Users” and then select “Details.Name”.

 

image

 

To add another slicer, repeat the process from above, only instead of expanding Unique Users, expand “Signin Activity” and then select “Device Information”

image

 

Adding slicers enables me to check mark interesting information and drill down on that specific data point.  Pulling it all together the final dashboard looks like the following:

image

 

If I want to hone in on a specific data point, all I need to do is select either a data point under one of the slicers as shown in the gif below:

AADSigninPowerBI

 

Update
Add a slicer for date and time to show time based sign-in activity:

2017-03-30

This was just a simple method of creating a Power BI report that show’s a lot of rich data points that may help you understand where your users are logging in across the globe from what browser or device.  In addition, use the Azure AD Premium to create conditional access policies to protect user identities, corporate information, and block malicious devices, apps, and browsers from unsecure locations.