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 Outlook.com 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 firstname.lastname@example.org -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,
Posted by Oliver Moazzezi at 11:46 am No comments:
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,
Posted by Oliver Moazzezi at 11:11 am No comments:
Labels: ATP, Azure MFA, Oliver Moazzezi, phishing
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.
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
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 :)
Posted by Oliver Moazzezi at 4:44 pm No comments:
Labels: App Protection, Intune, Office 365, Oliver Moazzezi
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 '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.
Posted by Oliver Moazzezi at 4:42 pm No comments:
Subscribe to: Posts (Atom)