Creating App Protection policies in Microsoft Intune

Microsoft Intune provides a great service in managing devices, whether they are iOS, Android, MacOS or Windows (and yes, including Windows Mobile to an extent for the time being..), but what happens if you want a lighter way or providing security governance to corporate data without having to manage the whole device? Well.. that would be Microsoft Intune App Protection.

You can have app protection policies in-place even if you have fully managed devices by Intune - however the service supports an unmanaged device having managed apps with protection wrapped around the apps to provide corporate governance - so how exactly do we set this up?

Let's take a look.

In the Azure Portal, open Microsoft Intune. From here, let's drill down into 'Client Apps'

From here we have a variety of options from app configuration policies to pushing apps out to devices. What we are looking for in this instance however is 'App protection policies'

Select this and then select 'Add Policy'

We now need to name our policy, select what OS it is for (this example is for Android), provide a description if necessary (always a good idea!) and select the required Apps. In this instance I am creating a policy for Outlook, but in this example I have shown you can multi-select Apps into a single protection policy if you so wish. Be warned they'll all share the same protection policy configuration. If you need Apps with different configurations, create seperate policies.

There are a variety of options available to configure. In this example I am specifying that a device backup cannot back up any of the App data. I also have options to disable data transfer to other apps, as well as specifying user data transfer - I am specifying here 'Policy managed apps with paste in' here. The options available and what they mean are detailed below

Blocked: Do not allow cut, copy, and paste operations between this app and other apps.

Policy managed apps: Only allow cut, copy, and paste operations between this app and other restricted apps.

Policy managed apps with paste in: Allow data cut or copied from this app only to be pasted into other restricted apps. Allow data cut or copied from any app to be pasted into this app.

Any app: No restrictions to cut, copy, and paste operations to or from this app.

In 'Access Actions' I specify whether access requires a password or pin, you can see I can protect the app with a variety of security options, even enforcing full credential requirements if warranted. There is however a level or security versus productiy, so in this example I am specifying a 4 digit pin.

We can also set sign-in security requirements, we have the option at leaving them at the defaults or changing their values and actions. Actions are defined, and we select them from pre-defined capabilities. We can also delete each one if we believe they are not a requirement for our protection policy.

 Once you have saved the policy you'll see the policy under 'Client Apps | App protection policies

I will now assign this to a select Azure AD group I have created. I drill into the policy and select 'Assignments'

I specify my Azure AD Group and save it.

So my App protection policy is all set! Assuming my user has an Intune license assigned how does an App within the protection policy behave? Let's take a look.

I'm using Outlook as the example. I'll download it from the store and open it.

 Once I sign-in with my Office 365 credentials I am prompted I need to activate a device administrator

I select 'Activate' to continue the process

It will give me information on what device adminstrator will do - a collection of policies from my App protection policy.

It will then take me through setting up the requirements for access to the App.

For both Android and iOS there is a requirement to have the Company Portal app installed. The app doesn't have to be signed into or the device to become managed, but at this time it's needed. Select 'Keep Account' and we'll then download the App.

So that's it. So what happens when I open Outlook? The answer is I am asked to enter a 4 digit pin - just what I configured in the policy. On top of this my data transfer settings and app paste in options are also configured and honoured.

That's it - take care :)

Have fun!
@OliverMoazzezi

Creating Azure AD Groups with Azure Guest user exclusions

As Azure Guest access becomes more and more prevalent in an Office 365 tenant, certain Managers and Administrators are looking for a way to have 'employee only' Groups. Enter Azure Active Directory dynamic groups - a feature of Azure AD Premium P1 and above.

You can create a dynamic group in the Azure Portal, specifically | Azure Active Directory | Groups | + New Group. Let's take a look:

When creating the group, simply ensure the 'Membership type' is set to 'Dynamic User', you can then add your dynamic query, for example this one specifically looks for users with a mail add that contains 'wave16.com' - handy if you want to put users into groups based on primary SMTP address.

To specifically include or exclude Azure Guest Users - we're looking for 'UserType' where we'll match it, or not match it, or a variety of other options, with 'Guest'.

Once the Group is created it will take a while before you'll see the results of your dynamic group - more on that later, but drilling back into the Group we can confirm the dynamic membership rules query. We have the option of a simple rule or an advanced one, advanced allows us to join a variety or rules together to fine tune our dynamic membership

Once the dynamic group has had time to be processed it will show the objects contained within based on the rules you have created

So can we use Powershell to create Dynamic Groups? The answer is yes using the AzureAD Powershell module.

Once you have succesfully connected you can view your groups using Get-AzureADMSGroup 

 We can specifically look for dynamic groups by looking for the 'GroupTypes' attribute

Get-AzureADMSGroup |select DisplayName, GroupTypes 

And we can also actually create them, I find Powershell far easier creating a dynamic group when wanting to match multiple rules.

In this Powershell example I am specifically creating a Sales Group and also ensuring no Azure Guest users will be hiding within it. There's a few more considerations to bear in mind here as ww have to include -MailEnable -MailNickname and -MembershipRuleProcessingState

New-AzureADMSGroup -DisplayName "Oliver Test Dynamic Group" -GroupTypes dynamicmembership -MembershipRule '(user.userType -notMatch "Guest" -and user.department -eq "Sales")' -MailEnabled $false -MailNickname $false -SecurityEnabled $true -MembershipRuleProcessingState On

-MembershipRuleProcessingState states whether it will start processing the group or whether you want to pause the processing of the rule for the time being. The options available are 'On' or 'Paused' - Paused makes sense if you're using Powershell to script the creation of your on-premises dynamic groups to Azure AD, you may have a lot and want to slowly control which ones start processing.

More on understanding your on-premises dynamic groups and how to create them in Azure AD in my next post.


Have fun!
@OliverMoazzezi

 

Getting Azure AD Guest Users with the Azure AD Preview PowerShell module

Azure Guest access is a great concept primarily wrapped in the Microsoft Teams, SharePoint and Onedrive experience, however reporting and keeping a lid on Azure Guest access accounts can be a daunting task. Luckily there's a few ways to poll Azure Guest accounts, with PowerShell providing the best experience so far.

Accessing https://portal.azure.com and selecting Azure Active Directory | All Users | and then selecting 'Show: Guest Users Only'  will give you a list of the current Azure AD Guest Users in your directory. Unfortunately however, the UI is very limited in being able to get more information than what is presently shown.

Luckily the new Azure AD PowerShell Preview module can provide better insight to guest users for your Directory and we can utilise the shell to create a report for administrative purposes.

Let's take a look; once you have the module installed, utilise Connect-AzureAD, the module supports modern authentication by default so if you're looking to pre-enter credentials utilise the -credential parameter and $Credential = Get-Credential for scripting purposes.

We can simply list all users with Get-AzureADUser

We can get more information on a user by utilising -ObjectID and utilising the Azure AD User objects ObjectID GUID. For example Get-AzureADUser -ObjectID "object guid" |FL

What we see here is the parameter UserType - this is how we can differenciate a normal user to a Guest.

With a simple where statement we can specify all Guest users.

Get-AzureADUser |where {$_.UserType -eq 'Guest'}

The 'CreationType' attribute will also list if the account was created from an invitation from a user.

With a fairly simply PowerShell one liner we can retrieve all Azure Guest Users and format their most appropriate attributes easily.

Get-AzureADUser |where {$_.UserType -eq 'Guest'} |Select DisplayName, UserPrincipalName, AccountEnabled, mail |FT

We can utilise https://portal.azure.com  | Azure Active Directory | Users | Audit Logs to see who has invited the external users and also when an external user accepted the invite. Just filter on the activity and specify 'Invite external user' and 'Redeem esxtgernal user invite'.

Selecting the audit log will show you more information including the time and date of the activities.

If I check Azure Active Directory | Users | Sign-ins I can see audit logs for user sign-in. I can specify user search terms to get more detailed information on an Azure Guest User accessing my Office 365 tenant. Note I can get immediate access to Sign-in Info, Device Info and whether they had to have any 2nd factor authentication or conditional access rules apply.

And whilst both the Audit Log and Sign-ins allow me to download reports, Sign-ins provides richer integration with Power BI once you've configured it (which i'll detail in a future blog post).

So, getting back to creating a nice list of Azure Guest Users, we can utilise the Azure AD Preview PowerShell module to get this data and wrap it up in an email to send to us as and when needed. I've written a script and uploaded it to the TechNet Gallery here.

You can use it to get a list of Azure Guest users in the session window

Or use the -email switch where you'll be able to use it as a scheduled task - be aware the password needs to be in the script, however a standard user will work as all they need is read access which they have by default.

Have fun!
@OliverMoazzezi

Configuring Azure Password Protection with Active Directory

Firstly apologies that this is a few days later than I originaly planned but my trip to Microsoft Inspire really messed up my spare time to get this out there - having said that, welcome to the final part of my Azure Password Protection Preview review where we'll take a look at how to configure this with an on-premises Active Directory.

Pre-requisites require AADConnect and Windows Server 2012 R2 or above Domain Controllers, as well as the member server that will be running the Azure Password Protection Proxy.

You can download both the Proxy and Password Agent at this link. As previously stated Windows Server 2012 R2 is needed as the minimum supported operating system. The Proxy agent will flat out refuse to start on a Windows 2008 R2 server, but I did have success with the DC Agent. However this is not supported - ensure you are at Windows Server 2012 R2 or above.


Firstly we need to install the Proxy service. You can have up to two Proxy services installed per Active Directory Forest, with the DC Agent installed on every DC in the Forest/Domain. Run the install, although you can perform a silent install with

 msiexec.exe /i AzureADPasswordProtectionProxy.msi /quiet /qn

However in this example I am using the UI. Deploy the agent

Simply accept the terms and select 'Install'

And that is it, the Proxy service is installed. However it is not configured with the service just yet. However you should be able to see it running in the Services snap-in.

What we now need to do is open a PowerShell session on the server, the install deploys a PowerShell Module called 'AzureADPasswordProtection' which we need to load.

Import-Module AzureADPasswordProtection, and then,
Register-AzureADPasswordProtectionProxy 

You must ensure at this point that the account that is running this elevated PowerShell session is both a Domain Admin AND also a Global Administrator for your Office 365 tenant. This is very important. If you have ADFS then you will not get further unless you have password hash synchronisation in place - then it will work.

As long as the account confirms to both a Domain Admin and Global Administrator the service registers succesfully without much fuss.

From here on in, if you are in a single Forest scenario you are done. You are supported to install a second Proxy but you do not have to register the service, the above step is a once per Forest scenario. If you are running a multi Forest Active Directory, then you repeat the registration process once per Forest - and each Forest can have two Proxy agents.

We can check the service is still running and also the configuration of the service using these PowerShell commands:

Get-Service AzureADPasswordProtectionProxy |FL

Get-AzureADPasswordProtectionProxyConfiguration

For this above command you'll see that we can configure a static port if you require this in extremely restrictive outbound Firewall scenarios. Having the port set at 0 means it is dynamic, if you need to set it to a specific port simply use:

Set-AzureADPasswordProtectionProxyConfiguration -StaticPort 'port number'

Using the above command and setting the -StaticPort parameter back to 0 will make the service use a dynamic range once more.

So now we have our Proxy in a healthy state we can deploy our DC Agents, again the installer is a extermely simple affair, accept the terms and then we're completed - note that you'll have to restart your Domain Controllers. This is because it installs a password listening DLL to allow Azure Password Protection to work with your on-premises Active Directory. Deploy the Agent to each Domain Controller in the Forest. We can again quietly deploy should you so wish using

msiexec.exe /i AzureADPasswordProtectionDCAgent.msi /quiet /qn

Now we are in a position to enable password protection for Windows Server Active Directory. Go to the Azure Portal and in Password Protection enable it, ensure you select Save to keep your changes.

Microsoft recommends deploying in Audit mode only and that's what I have initally done. We'll enforce the policy later in this post.

 I have found during testing this can take up to 60 minutes before it starts pushing the policy out and the on-premises agents reporting they are recieving a policy from Azure. Microsoft states it may sometimes take a lot longer than that, but we can check Event Viewer on the on-premises Domain Controllers to see when the policy has pushed down. More on that later.

We will now be in a scenario - even if the Azure Password Protection policy hasn't been pushed to on-premises that you'll be able to see a summary report of password changes. Use the PowerShell command Get-AzureADPasswordProtection SummaryReport -DomainController 'DC' (where DC is the Domain Controller you want to check)

If you check Event Viewer under | Application and Services Logs | Microsoft | AzureADPasswordProtection | you'll see either DCAgent, ProxyService, or both depending on how you have built your Proxy and Agent infrastructure. To confirm the Azure policy has pushed to your on-premises infrastructure check the DCAgent log and search for Event ID '30006', you'll get a nice notice telling you that your Azure Password Policy is now being enforced. All DC Agents should get this at roughly the same time as communication comes from the Proxy.

As we're in Audit mode we can now see Azure Password Protection working without explicitly denying users password changes. This is a great way to get an undersanding of the service, get a confidence it is working and perform testing of password changes whilst looking at the audit logs. Look for Event ID 10025 or utilise the previous Get-AzureADPasswordProtection SummaryReport - but the Event Logs will give you a richer report experience.

Once you are happy the Proxy and Agents are working as expected and your testing in Audit mode confirms the Azure Password Protection service is working as expected, we can take the service out of Audit mode and push for Enforcement. Go back into Azure and simply select 'Enforced'

I found I have to wait around an hour or so for the service to come out of Audit mode and Enforcement come into play. You can of course restart the DC Agents to immediately pick up policy change but if the Azure Password Policy hasn't been pushed to the Proxy yet from Azure it won't make a difference. You'll need to sit and wait and check for Event ID 30006. Once out of Audit mode, the event will show 'AuditOnly: 0' - interestingly 'Enforce tenant policy' is always at 1.

So what happens if we now change a password of the user? Well you'll not only going to get all of the auto-protection from Azure of their default password protection policies but your custom banned password policy is also invoked. If we now try to change a password we'll see the below:

And Event ID 10017 will show the Enforcement at work.

And of course back in PowerShell we can again use the summary reports. We'll now see numbers against password changes rejected or password sets rejected depending on the password change type.

I have to say I am impressed with the solution and look forward to it coming out of Preview. I do hope they'll add a few improvements to the service however.

Firstly from a user experience point of view when Azure Password Protection blocks your password change you are not informed, you just get the usual 'your password does not meet the complexity requirements' jargon. I've been informed that this is going to be improved so it can give a more granular informational alert experience.

Secondly pushing the audit log experience into Azure as well would also be great - akin to the Azure Self Service Password Experience with Password Writeback and AADConnect.

Lastly I think the registration experience can be improved, including visibility that both the Proxy and DC agents are online and working as expected. Pushing this visibility into the Azure Portal - something similar to Azure Pass-through Authenticaton when you can see your PTA agents being online and the FQDN of the DC/AADConnect box would be a welcome additition, along with notifications to administrators if an agent goes offline.

Have fun!
@OliverMoazzezi

My 4 days of Microsoft Inspire!

I recently got back from Las Vegas for my first Microsoft Inspire event. I took a wash-up video each day and posted them on Twitter. I've added them here as a nice single place to find them all.


I signed up to attend the pre-day on the Sunday - this was a great opt-in benefit I suggest you sign up for if you can in the future.

Day 1 - my day revolved around Skype to Teams roadmaps and Azure

Day 2 - I spent a lot of time on GDPR functionality enhancements in Office 365

Day 3 - A great final day, with a fantastic keynote. I doubled down on Azure incentives for SQL and Windows server migrations to Azure.

Have fun!
@OliverMoazzezi