Seven Essential Security Configurations for Microsoft 365

Security Essentials in Microsoft 365 are a must, probably, most of this recommendations are being followed by most of us, but just in case and as a reminder:

 

Are users configured with multi-factor authentication? Multi-factor authentication is necessary control for users that protects them from password attacks such as password guessing and credential theft. If a Microsoft 365 user account is compromised, an attacker may gain access to the user’s emails, files, chat history, and other sensitive data. So imagine if this happens to an admin… probably: GAME OVER

If the organization’s on-prem Active Directory is synchronized with Azure Active Directory, are only necessary objects synchronized? Organizations will commonly synchronize their on-prem AD with Azure AD. However, it is a best security practice to only sync those AD objects that require use within Azure AD

 

Is the number of users configured as administrators in Microsoft 365 appropriate for the size of the organization? Having more than one administrator in Microsoft 365 ensures that if one administrator is unavailable, another user can make changes to the tenant. as always my recommendation and Microsoft is that should be no more than five Global Admins (remember to have emergency access account as well)

 

Are dedicated administrative accounts used? Separate administrative accounts from personal accounts, and something important administrative personnel should use their privileged accounts only when it is required.

 

Are tenant Global administrators configured with working email addresses? Microsoft 365 Global Admins receive a variety of important email notifications that include service status, security events, and other information. So, it is important that organizations ensure that global admins use an email address that is configured to a working address.

 

Are Azure AD User Settings configured from non-default settings? By default, non-administrative users may access the Azure AD administrative portal and perform several different actions including:

• Register custom-developed applications for use within Azure AD

• Access the Azure AD administrative portal

• Allow user to connect their Azure AD accounts with their
LinkedIn account

• Invite external guest users

• Invited guest users can invite additional guest users

 

Each of these settings may have a security impact, depending on how the organization. If the your organization has not tackled any of these default settings to be more restrictive, you’ll need to do it, there are a lot of configurations to be done

 

Are users restricted from creating auto-forwarding rules within Outlook? When a user creates an auto-forwarding rule, emails sent to the account are automatically forwarded without user notification to an email box that the organization does not control. This may expose the organization to risk of loss of sensitive data.

 

As always, there a lot of best practices to follow, the previous recommendations are only a few of them, but it’s up to you to apply them or be in the risky way, stay safe!

 

Conditional Access Tips From the Trenches

I want to drop some lines about my experience deploying several projects of Azure Conditional Access

• Always exclude your emergency accounts from the conditional access policies (remember if you don’t have an Emergency Account, you’re late), this is something that I always tell to my customers and I will never give up
• Don’t enable new policies without communicate properly to the organization, and also to foresee the impact in the users (you will save a lot of tickets from the customer service)
• Don’t enable policies that requires compliant or hybridAzureAdJoin devices without verifying the state of the devices in the Azure Portal (same as before, you will save tickets and system interruption from the end users)
• Careful with including in the policies the application “all apps”, is it possible to have a disgusting surprise (in my case, it happened to me in Azure, I put some exclusions, but it seems that sometimes the portal calls randomly to other APIs that cannot be controlled (and do not exist in AAD), so the user received a block in the portal even if the policy makes sense for you)
•  If you go ahead with the policy with “All Cloud Apps” for the policies bases on devices, be sure to exclude in the policy the app “Intune Enrollment” or you won’t be able to enrol new devices in the portal
• It is very easy to include multiple cases in one policy, but if you want to troubleshoot of what is happening, is it easier to segment the policy in multiple policies. Eat the elephant bite by bite, we have to put in the balance having and managing several policies or be able to troubleshoot correctly.
• Is it recommended to include a naming convention in your policies, in a bird’s eye, you will be able to know what is the use for each policy (user, device, administrator, guest)

So, this is all, probably you’re following most of these recommendations, but if not, don be a fool 😉

Till next time!

OATH Hardware Tokens for AzureAD

As you probably have been reading in my previous posts, I’ve been talking about FIDO2 keys, and how it can be used as a secondary authentication when signing in AzureAD.

PassWordless Authentication with Fido 2 Keys – Part 2

PassWordless Authentication with Fido 2 Keys

Today, I want to talk about OATH hardware Tokens, known as Time-based One Time Password Tokens as well.

As you are aware, some authentication methods can be used as the primary factor when you sign in to an application or device, such as using a FIDO2 security key or a password. Other authentication methods are only available as a secondary factor when you use Azure AD Multi-Factor Authentication or SSPR.

The following table outlines when an authentication method can be used during a sign-in event:

But, OATH TOTP is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes. OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token.

In this post, I will show you how the OTP C200 token from Feitian can be configured in Azure AD and how it works.

First of all, what you have to do is to register the key in Azure AD, in order to do this, you will need the Serial Number from the Key, and the secret key provided by the manufacturer, and then you need to create a CSV file with all the information:

Once you have done this, these keys must be input into Azure AD: Multifactor authentication – Microsoft Azure

Upload the file, and activate the key in the portal, once it is have been done, it will show you a screen like the following:

If you have any error during the upload, it will be shown in the portal itself:

You must consider that you can activate a maximum of 200 OATH tokens every 5 minutes.

Also, as you probably figure out, users may have a combination or OATH Hardware tokens, Authenticator App, FiDO Keys, etc…

Be aware that users con configure their default sign in method in the security info web: My Sign-Ins | Security Info | Microsoft.com

So, once the key has been configured for the user, which is the flow to access to the account?

I have compared the Authentication flow with the Fido2 Key Flow, the difference that you can appreciate is with FiDO2 Keys is not necessary to include my password

Finally, check out the following table from Microsoft, where you can see different persona cases and which passwordless technology can be used for each one of them

IMHO, FiDO Keys are great, but thinking as an end user they have problem: the first setup: We must rely on end user about how they configure the key and associate it with azure AD (remember the previous table). FiDO keys has the advantage to be able to be used to sign in instead of using a password in the computer.

In the other hand, OAUTH keys are great, because you as an administrator, can configure the keys in the AAD Portal, and once have been activated provide them to end users, without necessity to do any other action from the end user perspective, and the most important part, are very easy to use

Thanks to Feitian for providing such amazing tokens

You should remove that basic authentication from Exchange…

Now more than ever, you should disable your legacy authentication in Exchange Online, last year Microsoft announced that they will remove that basic Authentication next October (https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-deprecation-in-exchange-online-may-2022/ba-p/3301866)

Did you know that:

• More than 99 percent of password spray attacks use legacy authentication protocols
• More than 97 percent of credential stuffing attacks use legacy authentication
• Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled
  

Disabling legacy authentication for users is a must-do on your identity security checklist

Why? becasue is a security gap and Microsoft took a lot of effor to promote Modern Authentication. So, you can disable now this basic Authentication in very simple steps:

If you don’t want to use this option, you can block the access to those protocols by using Conditional Access, understanding in a very simple way the impact of the policy.

What are you waiting for?

Secure your AzureAD Identity infrastructure

In the Global Azure I had the oportunity to talk about how to secure our Azure AD. Now Microsoft has published a new link about how to protect our AzureAD: https://docs.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity

So now, we have official documentation to support my recommendations 🙂

Idle timeout in Microsoft365

With the new feature Idle Timeout, you can protect your data from unauthorized access. This setting automatically times-out inactive users, making your data more secure and less prone to unauthorized access. You can enable it in 3 simple steps:

Meet Microsoft Entra

Microsoft Entra will verify all types of identities and secure, manage, and govern their access to any resource. The new Microsoft Entra product family will:

Protect access to any app or resource for any user across hybrid, multicloud, and beyond;

• Secure and verify every identity including for employees, customers, partners, apps, devices, and workloads;
• Provide only necessary access by discovering and right-sizing permissions, and managing access lifecycles for any identity; and
• Simplify the human experience with simple sign-in, intelligent security, and unified administration.

But, what it is really Microsoft Entra? A unified portal for securing and managing every identity – The admin center for Microsoft Entra facilitates identity and access management, multicloud permissions management, and administration of verifiable credentials, all in one place.

When Entra will take place? In May 31st

And what happens to my AzureAD? Azure AD continues to be the foundational infrastructure for all new products in Microsoft Entra family. Innovation and investment in Azure AD continues, including the popular Application Gallery, Conditional Access, multifactor authentication, passwordless, and more.

Will I still be able to access my Azure AD Admin portal? short answer yes, long answer see below:

1. The Azure AD admin center (aad.portal.azure.com) will continue to function for the next 12-18 months, and then redirect to entra.microsoft.com in 2023 after extensive customer notice.
2. The Azure portal at portal.azure.com will also continue to offer Azure AD for Azure customers.
3. The M365 portal Azure AD admin page will be redirected to entra.microsoft.com later this summer.

So, can I Buy Microsoft Entra? Microsoft Entra is a product family. Products within Microsoft Entra are available for sale but there is no Entra bundle to purchase

This new product family has an impact on licenses or billing? No, but if you’re interested in sing Microsoft Entra Permissions Management will need to obtain a license for the solution. Microsoft Entra Verified ID is a free service but some scenarios, integrated with Azure AD capabilities, may require an Azure AD P1 or P2 license as a pre-requisite.

More info at: Secure access for a connected world—meet Microsoft Entra – Microsoft Security Blog

Why you should block legacy authentication

Currently, we could say that Legacy Authentication is one of the most compromising sign-in, luckily for us, older protocols have been replacing with modern authentication services, taking the advantage that MA supports MFA, while Legacy Authentication refers to all protocols that use Basic Authentication, and only requires one method of authentication.

So, it is important thar for security reasons we need to disable legacy authentication in our environments, why? Because enabling MFA isn’t effective if legacy protocols are not blocked. For example, the following options are considered legacy authentication protocols:

• Authenticated SMTP – Used by POP and IMAP clients to send email messages.
• Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
• Exchange ActiveSync (EAS) – Used to connect to mailboxes in Exchange Online.
• Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.
• Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
• IMAP4 – Used by IMAP email clients.
• MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
• Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
• Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
• Outlook Service – Used by the Mail and Calendar app for Windows 10.
• POP3 – Used by POP email clients.
• Reporting Web Services – Used to retrieve report data in Exchange Online.
• Other clients – Other protocols identified as utilizing legacy authentication

How can we monitor the usage of legacy authentication in Azure AD?

Thanks to Log Analytics, Insights and workbooks, we are able to monitor the use of those protocols, for instance:

And check the non-interactive sign-ins (be careful with ADConnect sync accounts):

What we can do to avoid this?

The best way to block or report legacy authentication for users is use Conditional Access policies (Does my organization need Azure AD Conditional Access? – Albandrod’s Memory (albandrodsmemory.com) & Enabling zero trust security in your environment – Albandrod’s Memory (albandrodsmemory.com)

But the best way is creating a CA policy:

My final advice

Legacy authentication must be disabled to protect our environments, but first, start small and analyse the impact in your organization.

Till next time!

PassWordless Authentication with Fido 2 Keys – Part 2

This is a second part of my blog about reviewing Fido2 Keys from Feitian (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

In this case, I am testing out the K33 and K44 products

The initial setup of the tenant is covered in my previous post, so I will skip the details of how to do it.

To configure the K33 key you will need to download the app “BioPass FIDO2 Manager” from the Windows Store:

And connect your K33 key via USB to the laptop (otherwise won’t be possible to configure), the configure your preferred PIN, and finally configure your fingerprints. The process to the K44 is similar, but in this case, I am using and Ipad, and the app to download is “iePassManager”

Once the two keys are configured, you’re ready to setup them in AzureAD MFA (https://aka.ms/setupmfa)

K33 process

I have explained the process of how to initially configure the K33 key, but I strongly recommend to follow the steps mentioned in K33_Microsoft_Services_Guide.pdf (ftsafe.com) to pair the key with your laptop.

Once the key has been paired, the process to configure it is simple, the only thing that you must take into account is that even it is Bluetooth Key, you must configure it as an USB key (but remember, it must be paired first with the device).

Authentication with K33

K44 Registration Process

Once again, it is needed to set up the PIN for the Key, in my case, it has been done with the Ipad, but the registration process, is easy as the video shows:

The sign in process is very similar as we’ve seen before, so I do not want to cover this, but as you can observe, the registration and use of Fido2 Keys is pretty simple.

Inclusion, MFA keys and particularly, Fido2 Keys from Feitian are great!! But now, something that you must consider when implementing Fido2 keys in your environment:

There’s no way to enforce PIN policy in Azure AD: Every user can set up their own PIN to use their key. There is no centralized way to manage PINs, but Windows Hello for Business blocks simple PIN codes by default.  The bad news is, if you add the key directly to your Azure AD account, these settings are overridden ☹

Feitian offers multiple options for connecting your key, so you’re sure to find one that works for you. Among the available connections are USB-A, USB-C, NFC, Bluetooth, PIN, biometrics, and more.

Biometrics requires app installation: you need to download the manufacturers’ application that enables fingerprint scanning, which is additional software that you must consider to install

Again, I want to thanks Feitian for providing the security keys to test out the use cases

Till next time!

My two cents for 2022

Nobody can doubt that 2021 has been the year to adopt the cloud (due to COVID of course), mostly because most of us needed to work from home. We can say that business has changed and “Probably” will never go back to was it was.

Remote work will continue growing, so in 2022 we will need to protect our assets much better, and for this, here are my predictions/concerns for the next year:

• Hacker will continue to try to breach in our systems and try to access by the weak link in supply chains. For this, we need to reduce privileges for internal and external accounts, and not forget about machine identities

• Every business needs to reduce his own Attack Surface, to reduce the blast radius of any exposure or incident. To achieve this, tools that provide visibility into identities and activities are essential, we need to be sure of what happened and respond quickly to those incidents

• Protect the data is your responsibility, try to plan and build security controls for your cloud migration roadmap

• Zero Trust will continue growing, but remember to keep in touch with all the components: network, identity, permissions, configurations… The need of tools that give visibility is essential here.

• Currently we put the focus on protecting our user identity with MFA controls, but what about machine identities? These identities and permissions are being exploited in every breach to make lateral attacks, so we will need to be aware of that during the next year.

For now, I think that it’s all, stay tuned to the blog and happy new year!