Announcement by Microsoft that they had removed the 16-character limit for passwords in Azure Active Directory had been coming for a while. It takes time for Microsoft to deploy such a fundamental change across all the places in their cloud systems where passwords can be changed. The first leaks that something was happening came in late April when people noticed that the user interface in components like the Azure AD portal and Office 365 Admin Center offered administrators the chance to set 256-character passwords.
The new password limit is also mentioned in the Microsoft 365 User Management blog for April 2019 (posted on 7 May). You can’t say that Microsoft didn’t give us hints that this was coming. Continue reading
Administrators have always been able to access user content and don’t need eDiscovery functionality to do this. Administrators can log onto someone’s mailbox or give themselves permission to access a user’s OneDrive account, or use the Search-Mailbox cmdlet to copy messages from user mailboxes to another mailbox. And they can run content searches to scan mailboxes, SharePoint, OneDrive, Teams, Office 365 Groups, and public folders and export whatever they find to PST files, ZIP files, or individual files. In short, many ways are available to an Office 365 administrator to poke around in user content if they so wish. Continue reading
Given the complex nature of cloud computing, Microsoft is mindful that it’s not a case of if things will go wrong, but rather when. Microsoft designed their cloud services to maximize reliability and minimize the negative effects on customers when things do go wrong. We have moved beyond the traditional strategy of relying on complex physical infrastructure, and Microsoft have built redundancy directly into the cloud services. They use a combination of less complex physical infrastructure and more intelligent
software that builds data resiliency into our services and delivers high availability to the customers.
This post describes data resiliency in Microsoft Office 365 from two perspectives:
1. How Microsoft prevents customer data from becoming lost or corrupt in Exchange Online,
SharePoint Online, and Skype for Business; and
2. How Exchange Online, SharePoint Online, and Skype for Business protect customer data
against malware and ransomware. Continue reading
A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. A hybrid deployment provides the seamless look and feel of a single Exchange organization between an on-premises Exchange organization and Exchange Online in Microsoft Office 365. In addition, a hybrid deployment can serve as an intermediate step to moving completely to an Exchange Online organization.
But one of the challenges some customers are concerned about is that this type of deployment requires that some communication take place between Exchange Online and Exchange on-premises. This communication takes place over the Internet and so this traffic must pass through the on-premises company firewall to reach Exchange on-premises.
The aim of this post is to explain in more detail how this server to server communication works, and to help the reader understand what risks this poses, how these connections are secured and authenticated, and what network controls can be used to restrict or monitor this traffic. Continue reading
My Office 365 admin portal displayed a new recommendation when I logged in last week. Microsoft is recommending that user account passwords be set to never expire. My tenant is currently set to an expiry period of 90 days, whereas a newer tenant I was doing some testing with last month has defaulted to 730 days. I am not sure whether a tenant created today will default to 720 days or to non-expiring passwords.
This recommendation has so far appeared only in tenants that I have access to that are configured with First Release for everyone, and that aren’t enabled for directory synchronization. I imagine that the recommendation is being rolled out slowly.
The thought of non-expiring passwords might raise a few eyebrows in some organizations. For a long time the accepted position for passwords was to change them regularly. This thinking comes from a time when passwords were the single factor of authentication for most systems, with multi-factor authentication being relatively rare. Times have changed though, and recent research has concluded that requiring users to change their passwords regularly will usually lead to them:
- choosing weaker passwords to begin with, because they don’t want to learn complex new passwords each time they are forced to change it
- choosing new passwords that are only a minor variation of their previous password, e.g. Monday01 changes to Monday02
So what should we do if we aren’t requiring our users to regularly change their passwords? Continue reading
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
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.