Intune, Samsung Knox, and OEMConfig

I work with many organizations who are beginning to migrate from Android device admin enrollments to device owner (i.e. Android Enterprise). While migration to device owner requires a factory reset on the device, once enrolled with device owner, devices have a more standardized approach to management and consistency vs. the fragmented management experience device admin enrollments exhibit when multiple OEMs are being managed.

Realizing there was a need to standardize and secure devices beyond the device admin APIs, years back Samsung introduced Knox. Samsung Knox provides an additional set of security and management APIs built on top of Android and is included with many Samsung devices. EMMs, including Microsoft Intune, also took steps to integrate with Samsung Knox to provide a rich set of management capabilities where the device admin APIs didn’t cover (e.g. email profiles).

Google requires device OEMs wanting their devices to be Android Enterprise Recommended (AER) to meet certain requirements thus standardizing and provide consistency across the Android Enterprise device ecosystem.  However, Samsung Knox remains available and continues to provide security and management features, in some cases, beyond what Android Enterprise offers with their current set of APIs.  Although Android continues to update/add security and management features with every API version.

With Android device owner enrollments, Samsung and other OEMs support OEMConfig.  OEMConfig provides a set of OEM specific features EMMs can configure along with standard device settings.

What is OEMConfig?

“OEMConfig policies are a special type of device configuration policy very similar to app configuration policy. OEMConfig is a standard defined by the AppConfig community (opens another web site) that allows OEMs (original equipment manufacturers) and EMMs (enterprise mobility management) to build and support OEM-specific features in a standardized way. Historically, EMMs, such as Intune, manually build support for OEM-specific features after they’re introduced by the OEM. This approach leads to duplicated efforts and slow adoption.

With OEMConfig, an OEM creates a schema that defines OEM-specific management features. The OEM embeds the schema into an app, and then puts this app on Google Play. The EMM reads the schema from the app, and exposes the schema in the EMM administrator console. The console allows Intune administrators to configure the settings in the schema.

When the OEMConfig app is installed on a device, it can use the settings configured in the EMM administrator console to manage the device. Settings on the device are executed by the OEMConfig app, instead of an MDM agent built by the EMM.

When the OEM adds and improves management features, the OEM also updates the app in Google Play. As an administrator, you get these new features and updates (including fixes) without waiting for EMMs to include these updates.”

Source: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Although Samsung offers OEMConfig settings, some Samsung features/settings require a Samsung license, for more details please visit: https://www.samsungknox.com/en/blog/knox-platform-and-android-enterprise

Intune documention on OEMConfig may be found here: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Let’s get started with OEMConfig with Intune and a Samsung device

Samsung Knox Service Plugin

First, let’s add the Knox Service Plugin from the Managed Google Play store which is required to deploy OEMConfig policies to Samsung devices.

Assumptions: Intune is already connected to Managed Google Play, if it’s not you can find details on how to do this by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

We’ll do this by navigating to https://devicemanagement.microsoft.com -> Client apps -> Apps -> Add -> App type = “Managed Google Play” -> select Managed Google Play Approve

To learn more about Samsung OEMConfig settings, browse through the Knox Service Plugin (KSP) admin guide: https://docs.samsungknox.com/knox-service-plugin/admin-guide/welcome.htm

Creating an OEMConfig profile for Samsung in Intune

Navigate to Device configuration -> Profiles -> Create profile -> add a name -> Platform = Android Enterprise -> Profile type = OEMConfig

Associated app = Knox Service Plugin – this is the app added in the previous step.

Select OK after selecting Knox Service Plugin.

After selecting OK we’re taken to Settings where we’ll see a full page of JSON. Don’t be intimidated it’s straight forward once you understand the structure which are just key/value pairs.

Either select all and copy or select Download JSON template and open in your favorite text editor.

There are a couple values I want to point out in the JSON:

I mentioned at the beginning some Knox features/settings may require an additional Samsung license, this is where the license key would be set:

We want to turn on the policies, do this by setting doPoliciesIsControlled to “true

Troubleshooting – everyone likes an easy method to troubleshoot a device and by setting verboseMode to “true” will enable you to view the policies deployed to the device via the Knox Service Plugin app. More on this later in the post.

There many settings that are controlled with OEMConfig, however for the purposes of this post I’m going to turn off face recognition and only allow fingerprint. Disable face recognition by setting doPasswordBioFace to “false“.

Note: blocking the ability to use Face unlock to unlock the phone doesn’t prevent the device user from adding their face recognition. They just won’t be able to log in with face recognition as password and fingerprint are allowed in the OEMConfig.

Once you’ve completed filling out the JSON, copy and paste into Intune where you originally copied the JSON from and select OK then Save.

Note: you don’t have to have every key/value in the profile present, feel free to delete key/values from the JSON, just make sure the formatting is correct.

Device view

Once the policy is targeted to device it should only be a few seconds or so before the policy gets pushed to the device through Google services.

We can check if the policy deployed by opening the Knox Service Plugin app and selecting “Configuration on yyyy/mm/dd” (e.g. “Configuration on 2019/07/08”)

Select the “Configuration results” dropdown and select “Policies received” and from here we see the same JSON that was deployed from Intune.

Look for the password policy in the JSON as shown below:

On the same Samsung device navigate to Settings -> Biometrics and security -> Face recognition -> enter your password if prompted and we see “Face unlock” is disabled.  Again, we can add face recognition, however we can’t use it to unlock the device, so it’s essentially benign.

Here’s a video of the process above:

C02937BC-C8ED-4E0A-A3B2-3915A014D37A

Intune MacOS management capabilities

Back in 2015 I wrote a blog about Mac management with Intune, however it’s been a few years and I feel it’s time we re-visit Mac management with Intune to learn more about what’s changed. You’ll soon learn there’s been a significant amount of progress and since my first post Intune now has a lot of native Mac management capabilities built in.

First let’s look at MacOS enrollment options with Intune.

MacOS enrollment options

There are two methods to enroll MacOS with Intune, user driven or using Device Enrollment Program.

User driven enrollment

For user driven enrollment the end user will need to sign into the web based version of the company portal via https://portal.manage.microsoft.com

If the user already had a device registered it will show on the screen, if the Mac is the first device being enrolled, they will see the following:

Once the user selects “Add this one by tapping here” they’ll be prompted to download the Intune Company Portal app.

After the Company Portal is downloaded and installed, open it up and you’ll be asked to sign-in using your corporate credentials. These are the same credentials used to sign into Office 365 (derived from Azure AD).

After sign-in is complete the device will begin the enrollment process.

For more details on user driven Mac enrollment please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-macos-cp

Apple Device Enrollment Program

The concept of the Apple DEP is to associate devices with an organization and to streamline the enrollment process, similar to enrolling Apple iOS devices. However, enrollment requires a different process by associating an Apple enrollment token with Intune. After the enrollment token is added and enrollment profile is created in Intune and associated with the enrollment token.

During the enrollment profile creation process you’ll be asked to select user affinity (i.e. userless or user associated). Once user affinity is selected, you’ll also select whether or not you’ll allow users to remove the enrollment profile via the “Locked enrollment” setting.  Finally, you’ll customize the setup assistance which allows for hiding setup screen, e.g. Apple Pay, Siri, Registration, etc.

For more details on the Apple enrollment token process with Intune please visit: https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-macos

Conditional access

An exciting feature of Azure AD is the ability to target certain device platforms (e.g. MacOS) and set a series of conditions for access by creating conditional access policies in Azure AD.

Compliance

Azure AD and Intune compliance policies also play a role in access. Step through the compliance policies below to view the restrictions that may be enabled for the device to be compliant.

Device Health

System integrity protection prevents malicious apps from modifying protected files and folders.

Device Properties

Specify which OS version and builds you’ll allow before accessing corporate resources.

System Security

Configured password and password integrity, storage encryption, firewall, and gatekeeper to project against malware.

Actions to take for non-compliance

Take action when devices are not compliant with the compliance policy by sending the user a mail and/or locking the device.

Associating an Intune compliance policy with Azure AD conditional access policy

Create an Azure AD conditional access policy to require the device be compliant to access corporate resources.

Looking at device configuration for MacOS there are a number of settings, and in my opinion, those settings address a lot of organizations requirements for Apple Mac management.

Device features

Device restrictions








Endpoint protection

Looking to protect the device further by configuring the firewall and controlling where apps are installed from? Gatekeep will help with those requirements.


Further configure firewall settings to device what you’ll allow in and which apps are allowed and/or blocked.


Certificates

Intune supports PKCS certificates for general and S/MIME purposes.



Device and user-based certificates are both supported via SCEP


VPN

Many VPN settings are available including 3rd party VPN support.


Make note of On-demand and per-app VPN


Use a proxy server? No problem!


Wi-Fi

Both Basic and Enterprise Wi-Fi profiles are supported with various auth types.


Customize with Apple Configurator

Don’t see a setting in the UI, not to worry as you can create a custom profile using Apple Profile Manager and/or Apple Configurator and upload the payload for delivery through Intune.


App deployment

Both line of business and Office apps are supported right from the UI.


When selecting “Line-of-business app” the MacOS app must be wrapped using the app wrapping tool for Mac which will wrap the app and give it an extension of .intuneMac.

The tool is available on GitHub: https://github.com/msintuneappsdk/intune-app-wrapping-tool-mac

To learn more about Mac app deployment with Intune please visit: https://docs.microsoft.com/en-us/intune/lob-apps-macos

One of my peers Scott Duffey @Scottduf has a great post on this topic: https://blogs.technet.microsoft.com/microscott/deploying-apps-to-macs-using-microsoft-intune/

Note: as of this post only .pkg files are supported nor are conversions from .dmg to .pkg

Microsoft + Jamf partnership

Microsoft has also has a partnership with Jamf. Jamf also provides MacOS management and if your organization currently utilizes Jamf and would like to receive the benefits of integrating Jamf with Intune you can do this today with Jamf Pro. So, what does this mean?

MacOS devices managed by Jamf remain managed by Jamf when Intune comes into the picture (thus are only registered with Intune not enrolled) and integrating Jamf Pro with Intune provides a path for Jamf to send signals in the form of inventory to Intune. Intune will use compliance policies to evaluate the Jamf signals and in turn send signals over to Azure AD stating whether the device is compliant or not. The Azure AD conditional access policy will kick in and based on your configuration of the conditional access policy, will either block or further challenge the user to remediate before access company resources.

For more details about Intune and Jamf integration please visit: https://docs.microsoft.com/en-us/intune/conditional-access-integrate-jamf

Jamf also has a whitepaper about Intune integration: https://www.jamf.com/resources/technical-papers/integrating-with-microsoft-intune-to-enforce-compliance-on-macs/

That’s it for now, however Microsoft is always releasing updates for Intune.  Check back monthly with What’s new in Microsoft Intune and be sure to check which Intune features are under development by visiting: https://docs.microsoft.com/en-us/intune/in-development

Android Kiosk Enrollment and Microsoft Intune

Last month I wrote about the different Android enrollment scenarios Microsoft Intune supports. For this month’s post, I’m focusing on the Android enterprise enrollment process, specifically single purpose device enrollment (e.g. kiosk) using a factory reset device.

Note: the device must be factory reset to enroll using Android enterprise.

Let’s get started

Create an Azure AD Group

Create a group in Azure AD that will dynamically add Android enterprise devices to it. This group will be associated with the Android enterprise enrollment profile. To do this,

  1. Navigate to portal.azure.com, locate and select Azure Active Directory
  2. Select Groups > New group
  3. Group type should = Security
  4. Provide a name for the group such as “Android Enterprise Kiosk Profile”
  5. Membership type = Dynamic device
  6. Select Dynamic device members

Use a simple rule using the “enrollmentProfileName” attribute to create the dynamic rule as shown below:

Create Android enterprise device enrollment profile

  1. Find and select Microsoft Intune from portal.azure.com
  2. Under device enrollment > Android enrollment select “Kiosk and task device enrollments”
  3. Create a new enrollment profile by selecting “Create”
  4. Provide a name and select an expiration date for the Token (this can be used to register devices with a token or QR code if necessary)

Add apps from Managed Google Play

  1. Navigate to the Managed Google Play account by selecting Mobile apps > Managed Google Play > Open the managed Google Play store
  2. Search for and add the “Managed Home Screen” app and additional apps you’d like on the locked task screen for the device.
  3. Sync with Managed Google Play within Intune and assign the apps and/or weblinks to the kiosk group created earlier.

For the apps to show up on the locked task screen (i.e. kiosk device) we must do two things:

  1. Under Mobile apps in Intune, assign the apps to the Azure AD group we created earlier (“Kiosk and task device enrollments” in my case), including assigning the Managed Home Screen.
  2. In the configuration profile we’ll create next, under kiosk add the same apps, except the Managed Home Screen (leave the Managed Home Screen out of the configuration profile).

Creating an Android enterprise kiosk configuration profile

  1. Within Intune select Device configuration > Profiles > Create Profile
  2. Select Properties > Platform = Android Enterprise, Profile type = Device restrictions
  3. Under settings select Kiosk > Kiosk mode: either select Multi-app or Single app kiosk. For this post I’ve selected Multi-app kiosk.
  4. Select Add and add the apps previously added to Managed Google Play that were synced with Intune. Remember, do not add the Managed Home Screen app (otherwise it will show up as an app on the screen of the kiosk device which isn’t necessary).

For the remaining settings, feel free to configure the other settings to match your business requirements.

Enrolling devices

There are various methods for enrolling a device shown in the table below:

Enrollment method Minimum Android OS supported
NFC (Near Field Communication) 5.1+
Token entry (manual setup) 6.0
QR Code 7.0
Zero Touch (ZTE) 8.0

For more details about Android kiosk device enrollment with Intune please visit: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll#set-up-android-kiosk-management

Below are the series of steps performed when my Pixel 2 device is enrolled with Intune with Android enterprise as a multi-app kiosk using a QR code, of course if you prefer, zero-touch is available on supported Android (8.0+) devices as well:

 

Tap on the screen six times

I tapped 5 times and it’s asking me for 1 more tap

 

Needs to download the QR reader app before QR code scan

 

Connect to Wi-Fi so we can download the QR reader

 

Once connected to Wi-Fi the device checks for updates

 

Downloading Google Play Store

 

Checking device info…

 

Installing QR Reader

 

Once the QR Reader is installed it will use the camera to scan the QR code under the Android enterprise enrollment profile created earlier

 

QR code is accepted and we’re prompted to continue setting up the device.

 

Updating the Google Play Store again which is connecting to the Managed Google Play store

 

Downloading Google Play services…

 

Uploading Google Play services…

 

Finish device updates

 

Registering the device with Intune

 

Intune device configuration policy we created earlier is now applied

 

The Managed Home Screen is applied and the apps we assigned earlier are shown on the locked down kiosk screen.

Windows Autopilot – check those logs…

Windows Autopilot is a Windows 10 feature that enables organizations to pre-register devices either through an OEM or manually.  When users receive a Windows 10 device that is registered with Autopilot and turn it on, they’ll walk through a streamlined and customized out of box experience (OOBE).  In summary, Autopilot helps to reduce the costs (and in some cases, infrastructure) of deploying devices to users.

If Autopilot were to run into an error there are several methods to check what and why issues occurred. Michael Niehaus has several posts about troubleshooting Autopilot including a recent blog post outlining new methods of accessing information to investigate Autopilot. Refer to Michael’s posts for detailed information on how to troubleshoot Autopilot.

In this post I’m sharing a simple script I wrote (based on the info Michael Niehaus outlined in his post) to view aggregated information about Autopilot from the registry and event viewer. In addition to registry and event viewer info, deeper investigation steps may be pursued with ETW.

 

Let’s get started

Requirements

  • Windows 10, 1709 or later
  • PowerShell


PowerShell Script

Feel free to modify the script to suite your needs such as remotely pull information from devices, etc.

The script is straight forward, first it looks for the Windows 10 version, i.e. 1709, and if it’s greater than or equal to “1709” it runs through both steps and pull registry and event logs. If the installed OS is greater than “1709” it will only pull event logs for 1709 as registry entries didn’t show up until 1803. Lastly, the script only pulls the latest 10 events, however that is easily modified.

 

#Get Windows Version
$WinVersion = (Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion” -Name ReleaseId).ReleaseId
Write-Host “”
Write-Host WindowsVersion= $WinVersion

if ($WinVersion -ge ‘1709’)

{
Write-Host “”
Write-Host “AutoPilot Registry Entries”
Get-ItemProperty ‘HKLM:SOFTWAREMicrosoftProvisioningDiagnosticsAutoPilot’
}

if ($WinVersion -gt ‘1709’)

{
#Show AutoPilot events
Write-Host “AutoPilot Event Logs”
Write-Host “”
Get-WinEvent -MaxEvents 10 -LogName ‘Microsoft-Windows-Provisioning-Diagnostics-Provider/AutoPilot’
}

 

Let’s see it in action:

Below are the results of a device not deployed with Autopilot.  As we can see there’s not much to look at or troubleshoot…

clip_image002[6]

Let’s take a look at a device deployed with Autopilot (notice the new setup screen that shows up in 1803)

clip_image003

The results of the script shows more information that may be utilized when troubleshooting Autopilot errors:

clip_image004[6]clip_image005

Add Windows Defender Browser Protection to Chrome with Intune

I recently read a really great post by Martin Bengtsson about utilizing Configuration Manager (SCCM) to force installation of the Windows Defender Browser Protection extension for Chrome. So I decided to take a different approach and deploy the extension utilizing a PowerShell script deployed through Microsoft Intune.

To learn more about the Windows Defender Browser Protection for Google Chrome please visit: https://chrome.google.com/webstore/detail/windows-defender-browser/bkbeeeffjjeopflfhgeknacdieedcoml

Assumptions

Windows 10 device enrolled in Intune


Let’s get started

I created the following PowerShell script to add the Defender Chrome extension as a registry entry:

New-Item -Path HKLM:SoftwarePoliciesGoogleChrome -Name ExtensionInstallForcelist –Force

$RegKey =”HKLM:SoftwarePoliciesGoogleChromeExtensionInstallForcelist”

Set-ItemProperty -path $RegKey -name 1 -value “bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx”

I saved the script as a .ps1 file and added to Intune utilizing the steps below:

clip_image001

Name the script, upload, and save

clip_image002[4]

Assign the script to a group

clip_image003

Sync your Windows 10 device with Intune

clip_image004[4]

Sync the device with Intune 

clip_image005

Registry Before sync

clip_image006[4]

Chrome without Defender browser protection

clip_image007

Registry after sync

clip_image008[4]

Chrome with Defender browser protection

Once Chrome is launched, the extension is automatically downloaded to the extension directory and added to Chrome.

clip_image009

Chrome extension directory

clip_image010[4]

In addition to configuration, Configuration Manager will also perform remediation if this is something you’re more concerned with, SCCM is the best path to go currently. Again read Martin Bengtsson’s detailed post for insight on deploying and remediating for the Windows Defender Browser Protection for Chrome extension through SCCM.

Windows 10 Group Policy vs. Intune MDM Policy who wins?

 

When I speak with organizations about managing Windows 10 devices with Microsoft Intune there is a concern about disruption of current projects to deploy new OSs, patches, etc.  When moving to Intune for managing Windows devices, Intune will leverage the built-in MDM agent vs. having to install another agent to manage Windows 10 devices.

 

With modern management of Windows 10, the process of updating and upgrading Windows 10 devices is seen as continual process.  Updating Windows doesn’t have to be seen a massive project, evaluate your current processes for updating Windows and look at updating Windows 10 as an ongoing predictable process for IT and end users.  In addition your users and company benefit from the latest security features built into Windows 10.

 

Managing Windows policies are also a concern when moving to a newer OS.  Traditionally, configuration policies are managed by Group Policy, however Modern Management of Windows 10 with Microsoft Intune also has a set of policies, even policies that are duplicative of Group Policy (where applicable, not all Group Policies are available via MDM or CSP).  In environments where Group Policies are deployed and managed by Intune there’s the question of which policy wins.  The following describes which policy wins according to Windows 10 version.

 

  • Windows 10 versions 1709 and earlier Group Policy will override MDM policies, even if an identical policy is configured in MDM.

  • Windows 10 version 1803 and beyond there is a new Policy CSP setting called ControlPolicyConflict that includes the policy of MDMWinsOverGP, where the preference of which policy wins can be controlled, i.e. Microsoft Intune MDM policy.

 

For more details about the new ControlPolicyConfict setting please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-mdmwinsovergp

 

What happens to the policy if the device is unenrolled from Intune?  If applicable, Group Policy will re-apply the policies in this scenario.

 

 

Setting up a policy

In the link above, the “scope” of the policy is set for “device” so we’ll need to target the policy at the device scope. 

 

To learn more about user and device scopes please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider#policy-scope 

Since the ControlPolicyConfict policy applies to the device, we’ll have to utilize the following string: ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy. 

 

Next replace AreaName/PolicyName with ControlPolicyConflict/MDMWinsOverGP

After the modification to the string, the policy should look like the following: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP

 

Creating the policy

 

Let’s create a new policy in Intune to control the GP vs. MDM winner

 

  1. Navigate to portal.azure.com and locate Intune
  2. Select “Device configuration à Profiles à Create profile”
  3. Under Platform select Windows 10 and later
  4. Under Profile type select “custom” and “add”
  5. Name the custom setting with something intuitive
  6. For OMA-URI add the policy OMA-URI string: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
  7. For Data type select Integer and add the number 1

 

Supported values for this policy are as follows:

0 (default)

1 – The MDM policy is used and the GP policy is blocked.

 

 

 

image

 

image

 

 

 

Let’s take a look how the policy is applied

  1. On the Windows 10 device, select the Windows icon > Settings > Accounts > Access work or school à under the account name select Info
  2. Sync with Microsoft Intune by selecting “Sync”
  3. Once the Sync as completed select “Create report”

 

image

 

  • Once the report is completed a folder will open containing an .html file
  • Open the .html report and search for “MDMwins”

 

image

 

GP Setting before the MDM policy takes place :

clip_image007

 

MDM setting after the policy is applied (note: Windows 10 1803 is required to override the GP):

image

 

 

Let’s take a look at a report in Intune regarding the policy and if it was successfully applied.  This useful to make sure the policies are actually applying or not.

 

image

 

 

Logging

Being able to investigate modifications to a device is extremely important, especially when troubleshooting. 

 

In event viewer we can access the event where the policy was applied as shown below.  However digging through events, especially across multiple devices, can be a difficult process.  This is where Microsoft Operations Management Suite (OMS) comes in.

 

 image

 

 

Logging with Microsoft Operations Management Suite (OMS)

Within OMS there is the Log Analytics solution to manage logs from devices with the OMS agent installed.  I won’t go into details about installing the OMS agent, however I will say it’s straight forward.  Once the agent is installed (which I have it installed on all my devices so I can look at label changes with Azure Information Protection (see my previous post) and other aggregated information) we’ll need to grab the proper even log source name and populate that in Log Analytics.

 

 

Find and copy the event log source or name: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider

 

image

 

image

 

 

Paste the event log path in Log Analytics to “Windows Event Logs under Settings > Data > Windows Event Logs” as shown below:

 

image

 

 

Give the logs a few minutes to sync from the device to OMS, then run the query below in log analytics analyzer and look for the MDMWinsOverGP policy created above:

 

image

 

For more details about Windows 10 MDM logging please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10

 

 

Evaluating existing Group Policies to determine migration to MDM

Use the MDM Migration Analysis Tool (MMAT) to evaluate which Group Policies have been set for a target user/computer and cross-reference against its built-in list of supported MDM policies.

 

Download the MDM Migration Analysis Tool (MMAT): https://github.com/WindowsDeviceManagement/MMAT

 

For additional details about creating custom ADMX policies please view the following two great videos:

 

Enable ADMX backed policies in Intune: https://www.microsoft.com/en-us/videoplayer/embed/bdc9b54b-11b0-4bdb-a022-c339d16e7121

 

ADMX backed policy import example: https://www.microsoft.com/en-us/videoplayer/embed/a59888b1-429f-4a49-8570-c39a143d9a73

 

Keep up to date with MDM policies and other features via What’s new in MDM enrollment and management

 

https://docs.microsoft.com/en-us/windows/client-management/mdm/new-in-windows-mdm-enrollment-management

 

That’s it, we’ve learned that there is a new policy added to Windows 10 1803 that will control if MDM policies win over Group Policies (where applicable, not all Group Policies are available via MDM or CSP), how to investigate policies via event viewer, and aggregate those logs using Log Analytics (OMS).

 

 

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 “”

    }