Skip to main content

License requirements for administering Microsoft 365 services

Microsoft licensing is tough and vague but something we must deal with while implementing our solutions. I’m also aware that some of the features I describe on my blog are only available in the most expensive licensing options Microsoft provides, making some of the features I describe not usable for some of my readers.

If you administer Microsoft 365 services like Azure Active Directory (AzureAD), Exchange Online (EXO), SharePoint Online (SPO), Intune and many other products the license requirements for your administrative accounts are extra vague. I’ve asked Microsoft in December last year to clarify this, but until now no response was given.

There is some fragmented information available in the Microsoft documentation, that in combination with some other information to be found on the internet, like on twitter concludes that the license requirements are indeed very vague and could really use some official documentation from Microsoft to clear things up.

One thing in known, is that when asked about licensing requirements for the online services provided by Microsoft the statement returned is: “When the user benefits from the service, a license is required”

So let’s see what I found available online and see if it makes sense in some way…

Read More

Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?

On March 7, 2018 the Microsoft Exchange Team announced that on October 13, 2020 it would stop the support for Basic Authentication (also called Legacy authentication) for Exchange Web Services (EWS) in Exchange Online (EXO), the version of Exchange offered as a service part of Office 365. EWS is a web service which can be used by client applications to access the EXO environment. The team also announced that EWS would not receive any feature updates anymore, and suggests customers to transition towards using Microsoft Graph to access EXO.

One and a half year later, on November 20, 2019 the Exchange Team also announced to stop supporting Basic Authentication for Exchange ActiveSync (EAS), Post Office Protocol (POP), Internet Message Access Protocol (IMAP) and Remote PowerShell on October 13 2020 as well. Authenticated Simple Mail Transfer Protocol (SMTP) will stay supported when used with Basic Authentication.

Instead of supporting Basic/Legacy authentication Microsoft will move towards only supporting Modern Authentication for most of the methods used to connect to Exchange Online.

Read More

Stopping automatic email forwarding in your Exchange Online environment in a controlled way

Working as a modern workplace consultant also means that sometimes you have to go deep into Exchange Online options in order to make sure that (sensitive) data of your customer doesn’t leave the organization without the proper security measurements taken. In the Microsoft documentation titled: “Best practices for configuring EOP and Office 365 ATP“, the recommended settings for both Standard and Strict states that Auto-forwarding to external domains should be disallowed or monitored at least.

Automatic email forwarding is one of the possible and still most common way (sensitive) company data might leave the organization. Giving the users the ability to automatically forward emails using either mailbox forwarding or message rules to users outside the organization in that case can be very risky. I’ve seen many cases where corporate email accounts were configured to automatically forward all email to personal gmail.com or hotmail.com accounts. Also still enabled mailboxes which forward mail to users personal accounts while the user doesn’t work at the company anymore is common practice. 

It’s also commonly known that if a user somehow gets compromised, hackers usually put a forward on the mailbox of the user in order to gain knowledge about the user in order further continue with their attack methods, or to retrieve sensitive company data for their own gains.

Read More

Did you already enable DKIM and DMARC for your Office 365 domains?

When you host your email on the Exchange Online (EXO) platform part of Office365 you can implement several security measures to make sure that email send from your domain gets delivered to the mailbox of the recipient.

The most known solution for this is by implementing a Sender Policy Framework (SPF) DNS record. By creating a SPF DNS record in your DNS you provide receiving email servers the option to check if the originating IP of the email is also the authorized email server for the domain. If not the email can be considered suspicious and the email system from that point forward can decide to threat the email as spam, phishing and so forth. 

If you decide to make the nameservers of Microsoft authoritative, which allows you to manage your DNS settings from the Office administration portal, the SPF record needed can automatically be enabled for you.

Read More