Wednesday 19 December 2018

Why does AzureAD advanced reporting and Azure Identity Protection give me conflicting alerts?

This is for any Office 365 Administrator that is using the advanced reporting features of Azure AD Premium P1 and also Azure Identity Protection as part of Azure AD Premium P2.

If you are using this reporting functionality from AADP1 and AADP2 you will no doubt be getting reporting conflicts where Azure Identity Protection is reporting suspicious activity even though you have ring fenced your networks and locations in the Azure Portal. This is a confusing and annoying anomaly that will frustrate you, but here's the answer to the issue. Azure Identity Protection, also known as the Cloud App Security Portal, doesn't honour any of the name locations or trusted locations you have setup in Azure Conditional Access | Named Locations.

Let's take a look!

Here you can see I am in the Azure AD Admin Center. Utilising the advanced reporting features of Azure Ad Premium P1 allows me to get more granular reporting capability from Azure on what is happening in my tenant and how users are authenticating and access Azure and Office 365 services. One of the great features here is adding 'known IP address ranges'. As shown below.

Selecting this takes me to Azure Conditional Access, where I can configure named locations. You can see I have configured my locations below as any good administrator should as this information is used to filter alerts and give information to the system to provide fine tuned alerting to you. When you add a named location in you also have the option of making it trusted - for example to bypass MFA requirements for 'trusted locations' rather than having to specify individual locations that come from this list.

So once I have populated all of this information my advanced reporting features of Azure AD Premium P1 will start to use them - and my alerts will take into account the configuration I have placed here. But what about Azure Identity Protection which is a feature of Azure AD Premium P2?

Well the truth is it doesn't use this configuration data at all - which is a crying shame. You have to configure it all over again. Let's log in and take a look.

You can see I am getting alerts for my Washington Office here, even though it's configured and trusted in the named location section of Azure Conditional Access in the Azure Portal.

So how do I remedy this so I have a unified advanced alerting capability and identity protection platform?

Well you need to add the locations into the Cloud App Security Portal. Specify the cog in the upper right area of the Cloud App Security Portal and select 'IP address ranges'

From here you will have to enter your locations once more.

Once entered, Azure Identity Protection will be able to use these locations in any of the pre-canned policies, or indeed any custom ones you create, to provide the same insight data that you are getting from the advanced reporting feature of Azure AD Premium P1.

And that's it. No more alert conflicts between the two systems where advanced reportings understands that a network is trusted and you get conflicted information from Azure Identity Protection.

The only downside is you will need to remember to update both until Microsoft ingest Azure Identity Protection fully into the Azure Portal (which I hope they will do!) and they share the same metrics and configuration data. Until that time, administer both.

Have fun!

Thursday 22 November 2018

Mitigating Azure MFA issues during outages for Azure MFA, Azure Conditional Access and Azure MFA Server

Microsoft suffered a very unfortunate Azure Multi Factor Authentication issue on November 19th which affected thousands of their customers for many hours. In a world where MFA is a must, even if most tenants still don't use this fantastic feature, and the service breaks, how do we mitigate the service issue that we experienced?

Well the first thing to understand is what version of Azure MFA are you using? There's effectively 3 versions in Office 365 which provide additional features and functionality via licensing: Azure MFA, Azure MFA Premium - although this cannot be purchased anymore as of October 2018, and Azure Conditional Access which allows MFA in it's workflows. On top of this there's also Azure MFA Server, an on-premises product to contend with as well - which was also affected by the outage.

So in a future scenario where we could have another Azure MFA outage, what steps as an Administrator can we take to gain access to our tenancy as well as mitigate user sign-in issues?

Let's take a look..

So from a user perspective, and we're just using the standard Azure MFA solution here, they won't be able to sign-in as MFA will be enforced. If you have legacy Azure MFA Premium licenses in play still or have Azure AD Premium licensing you'll find you can add trusted locations under 'service settings'.

So we now have two options, providing the service is still honouring trusted locations, which on the November 18th outage it was, we can setup some additional locations like the IP address of the user that's working from home. Or we can temporarily disable the user. Once the outage has recovered we can then go back and enable them once more. Remember to select 'restore multi-factor authentication on all remembered devices' so they won't have to re-register their device which can cause employee confusion.

If the users are logging into Office 365 and we have utilised Azure Conditional Access to create an MFA workflow, then the legacy Azure MFA page as shown above will show the users as disabled for MFA - but they will very much be enabled. To get this information on who is enabled you will have to dig through Azure AD Powershell.

In regards to getting the users access to their services again will require you to relax the MFA workflow in the Azure Conditional Access rule set, or disabling the rule altogether until the outage is over.

To relax the MFA requirement search under | Access Controls | Require multi-factor authentication

To disable the conditional access rule simply toggle it to OFF under | Enable policy

So your users sign-in issues are now resolved, what about your administrators? The answer here will lie somewhere above depending if you simply use the standard Azure MFA management page or if you manage an MFA workflow through Azure Conditional Access - however I would expect you to have a seperate conditional access rule for your Administrators, VIPs, Finance Teams etc.

If you are in the position where you cannot actually login to your tenant at all to make the above changes then you should have an account that allows Global Administrator access to your tenancy where it's details are unknown and locked into your BCS process. I recommend the standard * account here. If you are utilising Azure Conditional Access ensure you have setup an exclusion policy - which is actually Microsoft best practice for this very reason.

This is especially important if you have Customer Lockbox enabled - as Microsoft won't be easily able to help you gain access to your tenancy!

So finally that leaves Azure MFA Server. In the scenario encountered on November 19th how can we mitigate sign-in issues when Azure MFA Server is in use and users are enabled through it?

Simply open the Multi-Factor Authentication Server console, select Users | User and we can disable MFA altogether if we so wish until we want it enabled once more.

We also can utilise Trusted IPs and skip MFA requirements for them - just like in the Azure MFA service. We must however configure the IP addresses in the Multi-Factor Authentication Server console. Select | User Portal | Trusted IPs | and enter them here.

However there are other ways still. We could simply enable 'one time bypass' so MFA is still enabled but the user when they try and login to Office 365 during the outage will not get prompted for MFA.

Ensure you have an account that is a Portal Administrator

Once the admin is logged into the User Portal they can simply find the user and initiate 'one time bypass' and a time in seconds it will stay active before turning off the bypass. 300 seconds is the default. The next time the user logs in, MFA is not required, and then subsequently enforced once more.

So is there any other ways? Yes - and one from the outage that it is worth ensuring you keep enabled. Ensure under | User Portal | Settings | Use security questions for fallback | is checked. This will allow a standard security question response in the event of Azure MFA failure.

Take care,

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!