With the news at Microsoft Ignite that Teams is here to stay, and going to be the primary collaboration client in Office 365, it is going to be important for organisations to understand how to secure the data and conversations stored within Microsoft Teams.
Where is the data?
The first key thing to understand what types of data you are talking about, and where it is actually stored. Every “Team” is build on an Office 365 Group, and this is where the majority of the Team related data will be stored. Each Channel in the Team will provision a new folder in the Group’s Document Library, and this is where files shared in Group conversations will be stored. Each Group also has a Group Mailbox, and this is where conversations held within channels are stored.
However, users can also communicate directly via chat, and share files from this interface. In this instance, the conversations will be stored in the user’s mailbox, and the files they share will be stored in OneDrive.
That’s great, but what does this mean when it comes to compliance? Continue reading
Microsoft have announced that Azure Site Recovery (ASR) is now built into the virtual machine experience so that you can setup replication in one click for your Azure virtual machines. Combined with ASR’s one-click failover capabilities, its simpler than ever before to setup replication and test a disaster recovery scenario.
Using the one-click replication feature, now in public preview, is very simple. Just browse to your VM, select Disaster recovery, select the target region of your choice, review the settings and click Enable replication. That’s it – disaster recovery for your VM is configured. The target resource group, availability set, virtual network and storage accounts are auto-created based on your source VM configuration. You also have the flexibility to pick custom target settings. You can refer to the animation below for the flow.
If you have applications running on Azure IaaS virtual machines, your applications still have to meet compliance requirements. While the Azure platform already has built-in protection for localized hardware failures, you still need to safeguard your applications from major incidents. This includes catastrophic events such as hurricanes and earthquakes, or software glitches causing application downtime. Using Azure Site Recovery, you can have peace of mind knowing your business-critical applications running on Azure VMs are covered and without the expense of secondary infrastructure. Disaster recovery between Azure regions is available in all Azure regions where ASR is available.
You may have already heard about the Azure mobile app at the Build conference back in May 2017. The app lets you stay connected with Azure even when you are on the go.
Over the last few months, Microsoft have been working closely with customers to improve the Azure mobile app. Below are five more reasons why the Azure app is a must-have.
1. Monitoring resources
The Azure mobile app allows you to quickly check your resources status at a glance. Drill in, and see more details like metrics, Activity Log, properties and execute actions.
I’m excited to announce the release of Connect-365!
Connect-365 features a GUI that will prompt for your tenant credentials and then connect to various Office 365 services using remote PowerShell. The built-in prerequisite checker will check to ensure that the correct modules are installed and provide a download link for those that are not.
The current version of the script allows connectivity to:
Azure Active Directory (using v2 module)
Office 365 Security & Compliance Center
Skype for Business Online
This script will work natively in PowerShell 4.0+
There are no parameters or switches, simply execute the script: .\Connect-365.ps1
This script has been digitally signed and will run just fine under a “RemoteSigned” execution policy
Support Azure AD v1 and v2
Support for Exchange Online MFA (via module)
Derive SPO Admin URL
Recently there has been a lot of attention and a few different blog posts (references at the end of the post) regarding the use of Discretionary Access Control List (DACL) for privilege escalation in a Domain environment. This potential attack vector involves the creation of an escalation path based in AD object permissions (DACLs). For example, gaining “Reset Password” permissions on a privileged account is one possible way to compromise it by DACL’s path.
Although DACL permissions are not the easiest topic to cover in one post and should be digested slowly, there are examples of potential attack scenarios we want to share. The following blog tries to shed some light on the subject, present the possible escalation paths and suggest relevant mitigations.
Your organization can migrate email to Office 365 from other systems. Your administrators can migrate mailboxes from an Exchange Server or migrate email from another email system. And your users can import their own email, contacts, and other mailbox information to an Office 365 mailbox created for them. Your organization also can work with a partner to migrate email.
Before you start an email migration, review limits and best practices for Exchange Online to make sure you get the performance and behavior you expect after migration.
Migrate mailboxes from Exchange Server
For migrations from an existing on-premises Exchange Server environment, an administrator can migrate all email, calendar, and contacts from user mailboxes to Office 365.
There are three types of email migrations that can be made from an Exchange Server: Continue reading
As IT Professionals know, time is never on our side. Hence the reason PowerShell is so important. It provides a quicker way of completing tasks and can even provide some automation if harnessed correctly. This Step-By-Step will detail how to get started in harnessing PowerShell to manage an Azure Active Directory instance and detail day to day operation related commands to get you started.
In order to use PowerShell with Azure AD, first we need to install Azure Active Directory Module in local computer. there is two version of Azure active directory PowerShell module. One was made for the Public Preview and the latest one released after announces Azure AD GA. You can download module from http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx
It is highly recommended to replace it with the new version should you have already installed an older version.
Once installed let’s check its status. Continue reading
Microsoft provides some different options for securing Office 365 and Azure applications with multi-factor authentication (MFA). For your end users you can choose from:
MFA for Office 365, which provides basic MFA functionality for Office 365 applications only.
Azure MFA, which provides more advanced functionality, including the option to configure trusted IPs.
The trusted IP feature is attractive because it allows you to define IP address ranges, such as those of your corporate network, from which you will “trust” the logins and not prompt for MFA codes. This is useful for decreasing the annoyance factor of MFA for your end users, but doesn’t solve the problem for all types of organizations. For example, a staff of roaming sales people will frequently be accessing their applications from outside the corporate network, which will cause them to be repeatedly prompted for MFA codes. Yes there are some apps where you can “remember” the device and avoid repeated prompts, but not all apps provide that. App passwords, which are separate passwords for a user that bypass MFA, are also not practical in all cases as they become difficult to manage over time. Continue reading
Everybody knows that test environments are a very good idea, providing a safe place to try new features or configuration changes to products, develop scripts and tools, or provide training for your staff. Office 365 is no different, but a lot of customers that I talk to don’t maintain a test environment at all. And many of the IT pros that I talk to also don’t have their own person tenant for testing and training.
For traditional on-premises infrastructure the reasons for not running test environments are usually cost-related. Sadly, it is very common for IT teams to not have the resources such as hardware or virtualization capacity to build a separate environment that is a meaningful representation of their production environment. Continue reading