Automatically renew Android enrollment tokens using Power Automate

This month’s post is a continuation of automation with Intune data using Power Automate and Graph. When managing Android devices utilizing Device Owner enrollment (i.e. Android Enterprise) there are options for enrollment, NFC, QR Code, and Zero Touch. Each enrollment option requires an enrollment token as well and those are displayed in the Microsoft Endpoint Manager (MEM) admin center. With Android Device Owner dedicated (i.e. kiosk) enrollments, MEM Intune provides the option to create enrollment profiles where each has their own enrollment token. Organizations may choose to create multiple profiles for various reasons, however enrollment profiles may be utilized to automatically to add devices to Azure AD dynamic groups. This makes management of devices and targeting policy/apps seamless.

One point of feedback I’ve received is about the token lifetime of 90 days for Device Owner dedicated enrollment profiles. When an enrollment token expires no new devices may be enrolled until the token lifetime is extended (existing enrolled devices are not impacted). Token extensions may be completed in the MEM admin center or through PowerShell. However, why not automate the process? This is exactly what I do in this month’s post.

Let’s get started

Requirements

  • Microsoft Endpoint Manager Intune
  • Microsoft Power Automate (aka Microsoft Flow)
  • Azure Active Directory

Description of the process

The process of renewing token when they near their expiration is as follows:

  1. Introduce a recurrence trigger where the Flow processes every day.
  2. Set a timeframe to look for when tokens are about to expire.
  3. Make a graph call through HTTP.
  4. Parse the JSON that comes from the output of the Graph call.
  5. Look for any tokens that expire within 10 days.
  6. If successful, extend the token for another 90 days.
  7. Make another Graph call and parse JSON to get the tokens that were extended.
  8. Send a notification of which tokens were extended to Teams.

Here is the entire Flow we’ll walk through:

Power Automate

Log into Power Automate, i.e. flow.microsoft.com and create a new Flow.

Scheduled run

Insert a Recurrence trigger and modify to run every day at a specific time.

Add to time

We need to set a timeframe for when the token is set to expire. I chose 10 days, and later on we’ll use this value to look and see if tokens are set to expire within 10 days.

Register an app with Azure AD

To make Graph calls we need to register an app in Azure AD and grant it the following delegated permissions: DeviceManagementConfiguration.ReadWrite.All

We can pull all the information to build the query from: https://docs.microsoft.com/en-us/graph/api/intune-androidforwork-androiddeviceownerenrollmentprofile-createtoken?view=graph-rest-beta

POST https://graph.microsoft.com/beta/deviceManagement/androidDeviceOwnerEnrollmentProfiles/{androidDeviceOwnerEnrollmentProfileId}/createToken

Content-type: application/json

Content-length: 35

{

“tokenValidityInSeconds”: 7776000

}

This API is under /beta and may change, please make note of this.

Add a Redirect URI, I pull this from the connector I created in a previous post:


Create a client secret to utilize in authentication:

Grant proper API permissions:


Use Graph to query for all Android enrollment tokens

Add an HTTP action and configure as shown in the image below. This is a GET method.

Refer to the Azure AD app registration completed in the previous step to fill in Client ID and Secret.

Add a Parse JSON action so we can utilize the values that come back in the GET method.

Choose the “Body” of the HTML action and for the Schema, make a Graph call using Graph Explorer by doing the following:

Add a Condition action (this will turn into a Apply to each automatically)

In the first field add tokenExpirationDateTime (this will trigger the Apply to each action) > is less than or equal to > in the second field add “Add to time” output from the action created in the beginning of this post:

Add an “And” in the condition and in the first field add tokenExpirationDateTime > is greater than or equal to > and in the second field choose utcNow() from Expression.

What the condition is doing is checking to see if the date of the token expiration falls within 10 days, if not do nothing, if yes, we extend the token with actions under “If yes” which I cover next.

Extending the Android enrollment token

The fist step if the condition is true is to update the tokens that expire within 10 days. I created a custom connector as this is a POST method and I found the best method is to create a connector with variables that are exposed in the connector I can add in.

To create a connector, in Power Automate expand Data and select Custom connectors and select new create from blank. I import from Postman and if you’re interested in how to do that, please refer my previous post on the topic.

Security tab

Use the same Client ID and secret from the Azure AD app registration step completed earlier. For the Resource URL, type in https://graph.microsoft.com (the redirect URL will auto generate once Update connector is selected, the URL should match what’s in the Azure AD app registration):

Definition tab

Add a “New action” and add some details as shown in the image below, the Operation ID is something you’ll make up:

For the Request, select import from sample, select POST, add in the URL below, and add in the JSON in the body and select Import:

https://graph.microsoft.com/beta/deviceManagement/androidDeviceOwnerEnrollmentProfiles/{ID}/createToken

We now have the parameters needed for the POST method (which will extend the token for x number of day, e.g. 90 days):

Select Update connector and test the connector by creating a new connection and filling in the blank fields with static data. ID will be the ID of a token.

Back in the Flow, add an action and select custom and choose the new connector. ID will be the ID from the JSON output and tokenValidityInSeconds is self-explanatory, 7776000 which translates to 90 days.

Next we want to validate the tokens that were extended by calling Graph. We do this by adding two actions, an HTTP action and a Parse JSON action.

The HTTP action is identical to the one we created earlier, however append it by adding the ID of the token from the dynamic content list. Use the same process for Parse JSON as we did in the previous step as well. This step will only pull the tokens that were extended.

Lastly I’d like to know when enrollment tokens were extended so I send messages to Teams.

The reason why we query for the tokens that were extended in the step above is because we need to utilize that output to populate the Teams messages.

I have a couple tokens I set to expire in 5 days (in fact you can set any expiration date within 90 days directly from the MEM admin center if needed. It’s good for testing as well.):

I ran the Flow and here are the results posted to Teams, however you can send to email, SMS, SharePoint, etc. if you prefer, just look for the diffrent templates in Power Automate:

And in the Intune console:

One last item

If you’d rather view and extend Tokens by hand in the UI, you can do so by selecting Filter then Inactive which shows all expired and active tokens.

That’s it, utilizing Power Automate and Microsoft Graph we have automated extending Android enrollment token expiration dates and posted the results to Teams.

Microsoft Endpoint Manager Intune, Power Automate, and Microsoft Graph

One of my passions is working with customers and I’m fortunate to be able to speak with customers every day. Another passion of mine is automating tasks. A piece of customer feedback I receive is how to automate certain processes using the data within Intune, Microsoft 365, and 3rd party services.  Currently organizations may automate programatically by using the Microsoft Graph, however if you’re not familiar with using PowerShell or a developer it may be difficult to create a solution in the timeframe you need it by. Fortunately, there are Intune Graph samples available and if you’re intersted in viewing and utilizing the samples please visit: https://github.com/microsoftgraph/powershell-intune-samples.

Additionally, and the goal of this post, Microsoft Power Automate provides a robust set of templates and connectors to automate processes across Microsoft 365 and many other solutions.

For this post, using Microsoft Graph and Power Automate, I have automated end user email notifications after an end user has enrolled a device. The Power Automate (aka Flow) runs every hour and will send a mail to the end user who enrolled the device within the hour (or timeframe of your choice) of the last time the Power Automate process ran. From a security and user awareness perspective, an organization may want to notify users after a device enrollment completes, and if it wasn’t the user who actually enrolled the device, they could report it to their security and MDM teams.

Let’s get started

Requirements

  • Azure Active directory
  • Intune
  • Power Automate
  • SharePoint Online
  • Postman

Azure Active Directory

Register an application in Azure and creating a Power Automate connector for Microsoft Graph

We need to do several things to register an app in Azure AD and create a Power Automate connector, however registering an app in Azure AD and granting it permissions is several steps as is creating a Power Automate connector (because I use Postman to create the auth flow and query to Graph then save it out and import it to Power Automate as a custom connector). So to keep this focused on the automation piece, I found an individual online who published the following video who has a great walk through of how to do this in the first 30 minutes: https://www.bing.com/videos/search?q=graph+api+microsoft+flow&docid=608006419082446884&mid=DDFFFEB586D6DA665B5DDDFFFEB586D6DA665B5D&view=detail&FORM=VIRE

I recommend going through the steps in the video above and supplementing the perms and Graph call with the following:

To access Graph in Power Automate we to register a new application in Azure Active Directory so we can use it to make Graph calls to Intune. Once the application is registered we need to provide it the following application permissions to access Intune device objects:

Note: I have more perms granted than needed for this particular process, however the three above should be enough:

We also need to create a client secret and save it for later use in Postman:

Postman and Graph Explorer

If you don’t have Postman you can download it from: https://www.postman.com/downloads/

Use Graph explorer to come up with the query you’d like to use by visiting: https://developer.microsoft.com/en-us/graph/graph-explorer For this post I’m pulling all the managed devices from Intune: https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/

For reference, here is the authorization for the Flow connector collection I created in Postman.

You’ll save the collection out and import as a custom connector in Power Automate. Refer to the video above and it walks you through all this minus the uniqness of my query and app.


SharePoint Online

We need a method to look up when the last time the Flow ran and to do this I store one list item in a SharePoint list. The item I store is just the date, however what I really care about is the created time the list item was created because I call that in the Flow and compare it to when the devices were last enrolled. For example, if the Flow ran on 2020-04-03T20:22:15Z, the date is stored in SharePoint and for any device registered after that time, an email will be sent to the end user. It’s a simple process, however it works well.

The following is my SharePoint Online list where I store a formatted date in the Title fiel, however it really doesn’t matter what is stored in the Title field as the Flow looks for the “created” date for the single item. After the flow completes, I have a process in Flow that deletes the record and adds a new one so the next time it runs it has new date to reference.


Power Automate

At this point you should have an app registered with Azure AD, a connector created in Power Automate, and a SharePoint list to reference.  Now we can move on to the next step.

Let’s create the Power Automate process now:

In Power Automate select Create, name it, and as the trigger select “Manually trigger a flow”. We need a trigger, and for testing I recommend creating the Power Automate process with a manual trigger. When you’re ready to go live, delete the trigger and replace it with the Recurrence trigger, more on this later.

Here’s the Flow in it’s entirety, however I break it down in the next few steps:

First step in the Flow, beyond the manual trigger, is pulling the item from the SharePoint list.  Do to this, add a new action and search for SharePoint the select “Get items”. I’m not doing anything special in Get items as I’m just looking for that one item in the list so there is no need to limit or filter items:

Next add another action, select “Custom” and select the connector you created earlier:

Now we need to parse the JSON that was returned from the custom action above. Do this by adding an action and search for Parse JSON, then add it. As you can see in the image below I have a perfectly formatted JSON output, however this needs to be generated. To do this select “Generate from sample” and go to either Graph explorer or Postman and copy all the JSON query output and paste into the sample payload.  Once you select done in the sample payload prompt, it will format properly and show something identical to what I have in the image below (provided you’re making the same Graph call).  You can also remove attributes from the JSON if you don’t want to show them in the dynamic content.

Next I want to select only devices that have a UPN because we can’t send email if there is no UPN to sent it to.  If the device record has a UPN and was created after the timestamp we stored in SharePoint, the user will receive a mail (sample mail shown later on in this post). To do this add an action and search for “Select” and add it. In the “From” field add the value from the Parse JSON step above, and in the Map section, select the txt icon on the far right then choose userPrincipleName from the dynamic list:

This next step is a cascade of actions so pay close attention please:

  • Add an “Apply to each” action and select the Parse JSON value (just like you did in the Select step above).
  • Now add an embeded “Apply to each” action and add the value from the SharePoint step above.

  • Add an embedded “Condition” action (this is where we compare dates), and in the first box find and select “created” from the SharePoint items and select “is less than” and in the far right box select “enrolledDateTime”:

What I’m doing is comparing the single item created date pulled from SharePoint to the enrollment dates pulled from Intune:

SharePoint item created date

Device enrollment dates

  • In the “If Yes” box, add an action, then search and add “Send an email (V2)”. Then select from the dynamic items to craft a mail. We don’t need anything for “If no”.

The next three steps in the Flow are fairly self-explanatory so I expanded them for reference:

What’s occurring  in the “Apply to each 2” is a SharePoint value is selected from the SharePoint Get items step, then I delete the item. Next step is up to you, all I’m doing is converting the current date/time then adding it to the Title field of a new SharePoint list item, however you can do what you want in the middle step, just make sure the last step creates a single SharePoint list item as the created date needs to be referenced in a previous step in this Flow.

Testing the Flow

Once the steps above are complete, run a test to create an item in SharePoint, then register a device and make sure it shows up in Intune under device, then run another test.  So you’ll run two tests, one to generate the SharePoint item, and other after the device is registered with Intune.

The following is the email Power Automate sends to the end user who enrolled the device:

When you’re ready to move this process into production, delete the manual trigger in the first step and replace it with the Recurrence trigger and run it on the interval that is best for your organization:

That’s it, we fully automated a process by using Power Automate to pull all enrolled device objects from Microsoft Intune, selecting only devices that have a UPN associated, and sending an email to end users who have enrolled their devices since the last time the Flow ran.

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

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

    }

 

 

Microsoft Flow and Azure AD – let’s automate!

 

When I speak with organizations we often discuss scenarios such as having an onboarding process that is in need of a front-end utility and automation.  Many organizations have cloud services and on premises applications where the user onboarding process in some cases is still a manual procedure.  To assist with these processes and many others, Microsoft offers as service called Microsoft Flow.  I’m always looking for creative uses of applications and Microsoft Flow offers just what we need to help automate processes such as account management across applications and services.  In addition, Microsoft Flow goes well beyond just automating a user management processes (e.g. onboarding) as discussed below.

 

What is Microsoft Flow?

“Microsoft Flow is a service that helps you create automated workflows between your favorite apps and services to synchronize files, get notifications, collect data, and more.”

Source: https://docs.microsoft.com/en-us/flow/getting-started

Microsoft Flow allows you to create workflows to automate tasks, for example, when files are added to a folder in a cloud storage environment such as OneDrive or Box, notify a user. Or create an approval workflow process to manage tweets before they’re posted to Twitter.

 

Microsoft Flow offers connectors to connect to either cloud applications or on premises environments.

To view a list of Microsoft Flow connectors, please visit: https://us.flow.microsoft.com/en-us/connectors/

 

In addition, there are many pre-defined templates that may be utilized such as starting an approval process when a new item is added to SharePoint or save tweets to an Excel file or sync files between cloud drives or a file server via FTP.  The list goes on and on…

To view a list of Microsoft Flow templates, please visit: https://us.flow.microsoft.com/en-us/templates/

 

Microsoft Flow Licensing

Some features are free and require premium Flow sku.  For more details about Microsoft Flow licensing please visit: https://flow.microsoft.com/en-us/pricing/

Microsoft Flow FAQ: https://docs.microsoft.com/en-us/flow/frequently-asked-questions

 

For this post, I will utilize Microsoft Flow to create users in Azure AD as well as provide custom bonus flows! so let’s get started…

As an administrator, the first thing we need to do is access Microsoft Flow and create a new workflow.

Navigate to https://flow.microsoft.com and sign-in.

Search for Azure AD in the search box provided as shown below:

image

 

From the results page, locate and select “Create Azure AD User From Button”

image

 

From there select “Continue” to add the template:

image

 

For more details about the Microsoft Flow Azure AD connector and templates, please visit: https://us.flow.microsoft.com/en-us/connectors/shared_azuread/azure-ad/

 

From here you can use the template as is and select Create flow, or you change the name and edit the steps in the template provided:

image

 

I chose to edit the “Send an email” step in the flow as I wanted a little more detail, I began the editing process by selecting “Send an email”:

image

 

The default template only offers a one-line sentence of info, however I changed it to add information the manager and the end user would need:

image

 

We can also edit each flow step or add more if necessary by deleting or adding fields (if the field is used downstream in the flow you’ll need to delete the field first downstream):

image

image

 

“Adding an Azure AD User” Flow in action

The great thing about Microsoft Flow is a flow may be run on a schedule, via an event or trigger, or manually from the web or the Mobile app. 

Additionally, Flow templates may be shared out to other users to access as well, so administrators don’t always need to be in the process.  Ultimately a Flow template configuration is up to you and what works best for your processes within your organization

 

Flow Web App

To manually start the newly created Flow template, when in the Flow template select “More” from the top and then select “Run now”

image

 

From there the template with a list of fields will open for a user to manually fill in:

image

 

Once all the fields are filled in properly, select “Run flow” and a new user will be created in Azure AD.  I show more details and results below using the mobile app.

 

Mobile App

I find the Microsoft Flow mobile app very easy to use, especially when on the go.  In fact, flows may be created and edited directly from the Microsoft Flow app.

Download the Microsoft Flow app from your favorite app store, in my case I have the iOS app installed on my device.  The first time Microsoft Flow app is launched you’ll need to sign into your Azure AD tenant (be sure that user has rights to create users, groups, access apps, etc.).

 

Select “Buttons” at the bottom of the app:

SNAGHTML4c3e814e

 

Locate the the button that will create the Azure AD User:

image

 

Fill out the form and submit:

image

 

Here are my inputs from my Flow template process, when finished select “Done” at the top of the app and the Flow will run:

imageimage

 

Once the Flow has completed, we can look at the run history and the details of each flow process (great for troubleshooting as well):

imageimage

 

Expanding the “Send an email” flow we see the following:

image

 

Below is the customized email received by a user or manager after the user is created (including a randomly generated password):

image

 

Lastly, below is the user that was created by the Flow process in the Azure AD admin portal:

image

 

Dynamic groups

Once users are created, dynamic group memberships may be used to automatically assign users to group, for example, any user may be dynamically assigned to Group A. Group A can also be assigned to licenses, SaaS applications or assigned to SharePoint Online/OneDrive, so as soon as a user is assigned to a group they’ll have access to the licenses and apps assigned to it.

Dynamic group membership eases the management process of adding and removing users to applications. Simply assign a group to the application permission and use dynamic group rules to automatically assign and remove users. You can even use attributes such as employeeId, mail, or companyName as attributes to look for, however there are many more attributes to choose from and depending where the users originates from, you may want to get creative.  Finally, for applications that support provisioning, users may be automatically provisioned and provisioned to SaaS applications which provides full user lifecycle management.

For more details about Azure AD Dynamic Groups please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-dynamic-membership-azure-portal

 

BONUS FLOWS 

Need to disable or enable sign-on for a user quickly in Azure AD (i.e. O365, Dynamics365, etc.) from your mobile device?  I created Flows to do that.

 

Current sign-in state of the user shown in Azure AD and O365 Portals (it’s the same setting btw) shown below:

imageSNAGHTML13b5bc02

 

I created a button in Microsoft Flow and filling out the following fields in red:

image

 

When the flow is run, type in the UPN (email address) of the users and flow will disable sign-on for that user.

image

image

 

New sign-in state of the user shown in Azure AD and O365 Portals (it’s the same setting btw) now blocked shown below:

imageimage

 

Enable sign-on for an Azure AD user

Follow the Flow creation process above to create a Flow to enable a user to sign-on, however change the “Account Enabled” setting to “Yes”.  Note: Flows may be copied, to copy a flow select Save As for the flow you’d like to copy in the Flow portal and modify from there.

As a result we’ll end up with two flow as shown below:

image

 

And the flow buttons on my mobile device:

SNAGHTML14328189

 

Delete Azure AD Users

Now a question you may have is “can we delete Azure AD Users using a button?”  You could, however there is nothing built in with Flow or connectors today.  A custom app would need to be developed with the proper permissions to the Microsoft Graph to delete an account then added to flow.  So this would be more of a custom development approach that what I demonstrated in this post.  As a result, using Microsoft Flow we can create a custom connector that will call into the app registered with Azure AD to make calls to delete users using a button flow in Microsoft Flow.  Same holds true for resetting user passwords.

With Microsoft Flow, the possibilities are endless with the predefined templates and built-in connectors to services, you don’t have to be a developer to automate processes and workflows!

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