Configuration Manager, Intune, and the Cloud – What’s your plan?

As I meet with organizations, I learn what their business goals are, what their end user goals are, and what their budgetary guidelines are. I also learn a lot about their endpoint management goals. What I’ve discovered is endpoint management has different meanings for each customer with a few common themes, user experience, simplification, and cost reduction.

The pace of change with technology is extremely rapid and organizations often struggle to keep up with all the updates across deployed technologies. When IT teams deploy technologies to help secure and simplify administration, they must provide evidence to the organization about the short- and long-term benefits of shifting to newer technologies, especially if they are duplicative of existing technologies. The evidence to rip and release a working solution is typically prioritized and is provided in the forms of cost reduction, end user benefits, and administrative simplification. Looking back in history, many would argue managing Windows in the enterprise has been a priority for most organizations. Many of these organizations today continue to manage Windows with a variety of technologies with one, (based on my interaction with hundreds of organizations) standing out the most, System Center Configuration Manager (ConfigMgr).

Configuration Manager has been around for a couple decades and for good reason, in my opinion it manages Windows best. For those familiar with ConfigMgr, you’re probably familiar with its history and the changes to the product over time. What I’ve seen is a blend of enhancing the client, infrastructure, and administrative experiences, including enhancements to reporting, management techniques, bandwidth controls, scale, performance, and more recently attaching Configuration Manager to the cloud. These advancements are critical to an ever-changing landscape of Windows computing and resource access.

Why write about this now?

There are a couple reasons:

  • Organizations are going through digital transformation and taking a hard look at existing endpoint management solutions.
  • Configuration Manager remains one of the most widely utilized endpoint management technologies across organizations today and I articulate the ongoing value of ConfigMgr in the content below.

Recently organizations have asked me the question if ConfigMgr is “dead” and my consistent answer is “no” is it not, ConfigMgr as of this post manages over 150 million endpoints, in fact there’s been continued investment in ConfigMgr year-over-year. Take a look at “What’s New in Configuration Manager” over the past several releases and you’ll see a growing list of exciting enhancements over each release.

You’ll also notice ConfigMgr has a release roughly every four months which provides a predicable release schedule for organizations needing to plan updates. Speaking of ConfigMgr updates, in console notifications of new releases provides an easy and informative method to update ConfigMgr to the next release by a click of a button. In addition, ConfigMgr technical previews allow organizations to test new features ahead of upgrading to the next service release of ConfigMgr. The servicing of ConfigMgr and technical previews are a win/win in my opinion.

I also receive questions such as “why stay with Configuration Manager, when I see Microsoft doubling down on efforts to enhance Intune toward feature parity?“. While partially true, there are clear advantages to continue utilizing ConfigMgr and leverage the cloud by cloud attaching ConfigMgr.

For example:

  • Preparing your infrastructure for cloud attach by extending ConfigMgr to Azure enables organizations to manage devices off the corporate network by utilizing Cloud Management Gateway .  By attaching ConfigMgr to the cloud, it allows organizations to simplify management of Windows devices and administrators will have the advantage of leveraging current processes built around endpoint management with ConfigMgr.
  • Organizations needing high availability in ConfigMgr can take advantage of site server high availability and SQL Always On.
  • Cloud attach Windows 10 clients to Intune by enabling co-management in ConfigMgr allows organizations to utilize ConfigMgr and Intune to manage Windows devices.  By enabling co-management, the organization benefits from the currently unparalleled strength of Configuration Manager as well as additional benefits cloud services such as Microsoft Intune and Azure Active Directory provide.
    For example, ConfigMgr client health will be reported directly to the device stats in Intune (shown below), remote actions may be initiated directly from the Intune admin console, as well as utilizing conditional access policies with Azure Active Directory to control access to company resources.

So why not move from ConfigMgr and manage all Windows devices with Intune?

Although managing devices may be viable for many modern management scenarios, there are scenarios where ConfigMgr remains as the preferred solution including:

  • Network controls for locations with low bandwidth
  • Down-level Windows 7/8 client management
  • Windows Server management
  • Devices that are network Air Gapped (isolated) and have no Internet access
  • OS deployment through network boot options
  • Complex application deployment scenarios
  • Third-party software updates
  • Etc.

Co-management provides methods for organizations running ConfigMgr to decide where they manage certain workloads. Currently, there are a number of workloads that may be managed by Intune when devices are co-managed, including:

  • Compliance policies
  • Device configuration
  • Endpoint Protection
  • Resource access policies
  • Client apps
  • Office Click-to-Run apps
  • Windows Update Policies

When utilizing co-management there are several advantages to utilizing Intune, for example in a co-managed scenario when moving “compliance policies” workload over to Intune, organizations can take advantage of Azure Active Directory Conditional Access. There are also immediate benefits of co-management such as executing remote actions directly from Intune including: Factory Reset, Selective Wipe, Device Restart, Fresh Start, etc. Intune compliance policies also play a significate role in controlling device health and access via Azure AD conditional access, for example Windows 10 compliance policies may require one or more of the following before accessing corporate resources:

  • Use a password to access devices
  • Encryption (e.g. BitLocker)
  • Firewall enabled
  • Installed Antivirus
  • Installed AntiSpyWare
  • Windows Defender version and signature is up-to-date
  • Minimum OS version required
  • Maximum OS version allowed
  • Valid operating system builds
  • Require the device to be at or under the Mobile Threat Defense level integrated with Windows Defender Advanced Threat Protection

Traditionally, setting up device health posture for an on-premises requires additional services and hardware such as a Network Access Control (NAC) solution. Whereas selecting workloads by enabling co-management for Intune to manage, organizations can take advantage of access controls delivered from Azure AD and Intune, including for on-premises web applications published through Azure AD Application Proxy. Not only is device health posture evaluated, additional access controls may be enabled including multi-factor authentication.

Below is an example of a device managed with ConfigMgr and Intune where compliance is reported back and shows in the ConfigMgr Software Center.

Intune Portal – shows compliant

Software Center – shows compliant (reported back from Intune)

Windows Deployment

Now let’s talk about Windows deployment options. Traditional deployment techniques for Windows typically involves an image that requires updating and then a system to publish those images so when a bare-metal boot takes place an image can be accessed, downloaded, and installed. OS image management can be a time-consuming process as it requires a human resource to manage and update the OS, drivers, apps, agents, etc. Some organizations offload OS image management to an OEM where the OEM preloads the image on the device, however the images still need to be maintained, and offloading to the OEM comes at a cost.

By leveraging Microsoft Intune and Azure Active Directory, organizations can take advantage of Windows Autopilot. Autopilot is very exciting as it eliminates the OS image management process which in turn can reduce IT costs. By pre-registering devices with Microsoft Intune when a user receives a device from the OEM, upon boot and connecting to the internet, the device will see that it’s registered with Microsoft Intune and go through the Autopilot process.

When organizations continue to utilize ConfigMgr, the CM agent can be pushed from Intune and the device now connects directly to ConfigMgr (when on corporate network) or through the Cloud Management Gateway giving your organization the confidence of maintaining current processes. Additionally, utilizing task sequences in ConfigMgr, Windows 7/8 devices may be upgraded to Windows 10 and automatically enabled for AutoPilot thereafter. The Windows 7/8 to 10 upgrade process may be pushed automatically or manually executed by end users (see screenshot below).

What about running scripts and installing software?

Both ConfigMgr and Intune support running PowerShell scripts and deploying Win32 applications, however for complex scripting scenarios such as running in task sequences and complex application deployments (i.e. deep app dependencies, etc.), ConfigMgr is unparalleled in this space.

My colleague Danny Guillory (who is also a PM on the Intune team) provided the following comments about Win32 applications and Intune:

Win32 App Deployment in Intune is a great way to get those .exe applications deployed and installed on those Windows Devices. The Win32 Wrapping Tool wraps all the files within that folder (think of a zipped folder), then distributes and deploys those files to the endpoints. The addition of detection method and delivery optimization makes Win32 app deployment more robust, simplifies distribution of content, and makes Win32 apps a must to explore with Intune Application Deployment.”

Additionally, MSIX is a new app packaging format that can take existing Win32 applications such as APP-V, MSI, .exe, etc. and package them in the new MSIX format. Many partners already support MSIX as well and for more details on MSIX packaging please visit: https://docs.microsoft.com/en-us/windows/msix/

If you’re looking to simplify application deployment both ConfigMgr and Intune provide the tools needed to deploy applications.

Monitoring and Reporting

Finally let’s talk about monitoring and reporting. ConfigMgr comes with hundreds of built-in reports, in addition there are newer monitoring and reporting capabilities with co-managed devices and a new reporting feature called CMPivot that provides real-time state of devices (see screenshot below). If you’re looking to creating dashboards based on ConfigMgr data, look into the Power BI template for ConfigMgr.

Next Steps

There are many Ignite sessions covering the topics in this post as well, to watch videos and learn more about the services and features discussed in this post please visit: https://www.microsoft.com/en-us/ignite search for “configuration manager”, “MSIX”, “Intune”

In conclusion, as organizations plan for the future of modernizing Windows management processes, my message to those organizations is to continue to leverage your current investments in ConfigMgr and keep current with releases. In parallel, begin to look at the benefits of cloud attaching ConfigMgr and/or managing workloads with Intune.

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

 

 

Windows Information Protection – adding the Intune Company Portal for Windows as an exempt app

As of January 2019 this is no longer necessary as the Intune Company Portal app is now included in the default list of protected apps.



2019-01-03_12-52-07

Organizations using Windows Information Protection (WIP) may experience issues accessing the Intune Company Portal app.  Fortunately, exempting Intune Company Portal app and any other application from a WIP policy is straight forward.

 

To learn more about creating Windows Information Protection policies please visit: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure

 

 

Let’s get started

 

By exempting an application the following pertains:

 

If you’re running into compatibility issues where your app is incompatible with WIP, but still needs to be used with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won’t include auto-encryption or tagging and won’t honor your network restrictions. It also means that your exempted apps might leak.

Source: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure#add-apps-to-your-allowed-apps-list

 

Since the Intune Company Portal App doesn’t store any sensitive company data, exempting it shouldn’t be an issue, however always check in with your security team to make sure.

 

The first step to exempting the Intune Company Portal App for Windows is to locate the app in the store.  I’ve done this for you below and even though the app may be accessed from the consumer and business store, all we really care about is the AppID at the end, i.e. “9wzdncrfj3pz”. 

As we can see, the AppID is the same regardless of what portal it was accessed from:

 

Windows Store Intune Company Portal app: https://www.microsoft.com/en-us/store/p/company-portal/9wzdncrfj3pz

Windows Store for Business Intune Company Portal app: https://businessstore.microsoft.com/en-us/store/details/company-portal/9wzdncrfj3pz

 

 

Creating the WIP exemption policy

To create an app policy within Intune to exempt the Intune Company Portal app navigate to portal.azure.com à Intune à Mobile Apps à App protection policies à Add a policy

 

  1. Give the policy a name and select Exempt apps
  2. Select Add apps
  3. From the drop-down menu select Store apps

 

At this point you’ll need to have some information handy about the app.  Fortunately, there is an easy method of extracting this data using the URL below.  I’ve already accessed the URL below; however, you can do this for any store app to find the name, publisher info, and product name.

 

Access following and replace the ID with the ID of the app you’d like to exempt, in this case, the Intune Company Portal app ID: 9wzdncrfj3pz

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfj3pz/applockerdata

For more details about accessing app package info please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/get-product-package 

The following is the output you’ll see in the browser in JSON format:

 

{

  “packageFamilyName”: “Microsoft.CompanyPortal_8wekyb3d8bbwe”,

  “packageIdentityName”: “Microsoft.CompanyPortal”,

  “windowsPhoneLegacyId”: “0b4016fc-d7b2-48a2-97a9-7de3b5ea7424”,

  “publisherCertificateName”: “CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US”

}

 

Now that we have the JSON information about the Intune Company Portal store app (using the URL above), we need to add that data to the policy as shown below. 

Once finished adding the information, select OK and assign the policy.  On the Windows device, either wait for your devices to sync with Intune of force a sync from Settings à Accounts à Access work or school.

 

image

 

 

Once the policy updates you’ll be able to access the Intune Company Portal app:

 

image

 

If you’re interested, I go into detail about WIP a previous post: https://blogs.technet.microsoft.com/cbernier/2017/05/19/windows-information-protection-explained-windows-10-creators-update/ 

That’s it, if you’re not utilizing Windows Information Protection today, I highly encourage everyone to look into the benefits of protecting corporate information across personal and corporate owned devices with Intune, including Windows, iOS, and Android.

 

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

Azure AD Connect Pass-Through Authentication – tracking sign-on activity with event viewer and Microsoft OMS

 

Quick post today around Active Directory sign-on auditing when using AAD Connect Pass-Through Authentication.

 

Azure AD Connect Pass-Through Authentication (PTA) provides the ability to pass authentication off directly to domain controllers. When passwords are reset or changed they’re reflected in Azure AD immediately via Azure AD Connect sync. Additionally, self-service password reset (SSPR) may be enabled in Azure Active Directory and those resets are written back to the domain controller as well.

To learn more about the available sign-on options please visit: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-user-signin

Many organizations already have extensive auditing set up to track sign-on activities and need to continue to track sign-on activity in across all services and need to maintain tracking no matter what services or applications are in use.  To continue the auditing practice with Azure AD Connect PTA let’s walk through how this is achieved.

 

Requirements

  • Active Directory Auditing is enabled via Group Policy.  Look under Audit Policies –> Logon/Logoff and Account Logon and enable auditing there.
  • Azure AD Connect with Pass-Through Authentication and Password Write Back enabled.
  • Optional: an additional Pass-Through Authentication connector deployed for high availability.

 

Example of my Active Directory audit policies:

image

image

 

Lets take a look at what to look for when using Azure AD Connect PTA.

As a user sign’s on to O365, or a federated SaaS app, or an internal application published to Azure AD, there are three events that are logged, two events to the domain controller: 4768, 4769 and one event to the server where ADD Connect is installed and PTA is enabled: 4624 (if additional PTA connectors are deployed for high availability look on those servers for 4624 as well).

 

On the domain controller look for events 4768 and 4769:

clip_image001

clip_image002

 

On the server where AD Connect is installed (and or additional PTA connector servers) look for event 4624:

clip_image004

 

Additionally, we can roll up these events to a SIEM for further aggregation of sign-on events and auditing. In my case I chose to use Log Analytics within the Microsoft Operations Management Suite:

clip_image006

 

To learn more about Azure AD Connect Pass-Through Authentication please visit the following links:

AAD Connect PTA: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication

AAD Connect PTA w/Desktop SSO: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso

AAD Connect PTA TS Guide: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso