Friday, 28 September 2018

Controlling access to the Outlook on the Web Beta Experience

Exchange Online customers are now having users being asked to trial the new Beta experience for the service once more. But what happens if this causes confusion in the work-place and introduces higher help desk calls? What happens if you are the IT Administrative function and you want to control when this experience is rolled out to your users?

Well the good news is we can control it with Outlook Web App policies and some Powershell..

Users are now getting asked to trial the new experience in the upper right area of their Outlook on the Web experience as Microsoft has pretty much rolled this out to all tenants in Office 365. Users will have been accustomed to the below experience for quite some time

The new 'beta' experience, introduces a look and feel that is almost exactly what consumer users of have been experiencing for the last 6 months.

We can control this by removing the option to users by utilising Powershell and editing the default Outlook Web App mailbox policy or creating a new one and assigning it to users. You may even have multiple policies already in place and need to make multiple changes. Here's what a user logged into Outlook on the Web looks like with the option removed.

So why do we need to use Powershell to modify this feature? This is because you cannot control the Outlook Beta Experience in the Exchange Administrative Center - the feature control isn't there.

So open a Powershell connection to your Exchange Online tenant and let's use Get-OwaMailboxPolicy to check the policies you have in-place. You will most likely just have the default policy, unless you have created additional ones in the past.

We're specifically looking for 'OutlookBetaToggleEnabled'

If you want to make the change against the default policy simply utilise this command

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-default -OutlookBetaToggleEnabled $false

And that's it we're done. If you have multiple policies in play then make sure you do it for each, or if you want to control roll out you can create a new policy with the feature disabled, then set it to specific users using the Set-CasMailbox cmdlet. For example:
Set-CASmailbox -Identity -OwaMailboxPolicy "Policy Here"

Don't forget though, this change is coming and will wholly affect Kiosk and F1 plan users - so don't remove the feature and forget about it. Utilise this to control the experience whilst you inform users of the change.

Until next time,


Thursday, 20 September 2018

The importance of Multi-Factor authentication with the prominence of phishing scams

Phishing scams are one of the largest threats to Office 365 user credentials out there. Why? Well it's one of the easist and yet most effective efforts hackers can do to obtain user credentials to provide access to corporate data. There have been a number of prominent phishing attacks targeted specifically for Office 365 in the last two years, most likely due to the huge success Microsoft has had with the platform.

I was alerted to a rather sneaky new phish yesterday, where a phishing emails were made to look as if they were coming from the Microsoft.

Message tracing immediately proved otherwise, but it took the user, should the user click on the link, to a sophisicated phishing site hosted on Azure asking the user to login.

You could alter the url to provide any username in the login box that you wanted

If a user fell to the phishing attempt it would fail login with a simple 'loading' screen

All together a clever attack, and one no doubt harvesting lots of Office 365 credentials. But what can they do with the credentials if there is no second factor authentication in-place? Well the answer to that ultimately lies in what security you have configured for your Office 365 tenancy - for example no second factor authentication but conditional access policies only allowing login from known locations or compliant devices would help - but an unlikely scenario! The most likely scenario is the attacker gains access to your Office 365 tenant through the compromised credentials.

The single biggest improvement you can make is enabling multi-factor authentication, whilst you can't fully control the behaviours of your users - one can only hope they listen and comply when potentially falling foul of phishing attempts - you can strengthen their login to Office 365 by enabling Azure MFA. This service comes in three flavours, the standard free service included with certain Office 365 SKUs, Azure Multi Factor Premium and then the MFA functionality in Azure Conditional Access. It's a no-brainer, implement MFA to protect your data and user identities - this stops phishing scams in their tracks.

User education is still a requirement however, users shouldn't be complicit in security just because they believe they are protected with MFA - they need to be versed in understanding attack types that could be launched against them. As should Administrators take advantage of reporting capabilities in Azure Active Directory to identify risky sign-ins and check sign-in locations, as part of daily or weekly tasks. Microsoft give you all of these features to help you protect your tenant - use them.

So what other improvements can we make to enhance security for Office 365? Well Secure Score is a great start, this will provide a variety of suggestions on improving the security of your tenant. From simple things such as disabling auto-forwarding on mailboxes, or setting OneDrive for Business and SharePoint Online sharing links with expiry limits as-well-as removing anonymous access to them; to suggestions that require greater planning such as just in time access and implementing granular access with RBAC.

Other improvements you can make is enabling ATP (Advanced Threat Protection), whilst this havesting website was still online I ran it through an ATP enabled tenant and ATP correctly flagged the site as malicious - note that if you are interested in ATP, this actual feature is called 'Safe Links', and needs to be manually enabled and applied.

Don't forget to enable the enhanced protection it provides to OneDrive for Business and SharePoint Online documents, and Office click-to-run.

Finally, with your user education initiatives in the fight against scammers, train your users to submit malicious sites or phishing scams and spam to Microsoft as well as alerting adiministrators so internal communication and technical checking processes can be completed.

Report for Office 365 here

Report for Windows Defender Security Intelligence here

Stay safe out there,

Wednesday, 12 September 2018

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!

Monday, 3 September 2018

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 '' - 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!


Tuesday, 31 July 2018

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 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  | 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!

Thursday, 26 July 2018

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,

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


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!