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!

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
thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							New tools to block legacy authentication in your organization

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?

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!

How to disable Hybrid Azure AD Join

A device is said to be hybrid joined if it has both an AD object and an Azure AD (AAD) object, which allow users of that device to sign in with an AD user account, which provides access to resources which are protected by either the AD or the AAD user.

A hybrid joined computer is joined to both AD and AAD, but the AD join is primary because the device initially uses AD authentication. Only Windows devices can be hybrid joined. The benefits of having Hybrid Azure AD Join devices are

  • The computer has a device object in Azure AD, which enables a variety of capabilities including:
    • Microsoft 365 Apps device licensing is possible
    • Azure AD Conditional Access features based on device conditions are possible
  • There is a reduction in user sign ins because user sign in gets both an NETID AD token and AAD token

But what If you want to disable that Hybrid Join?

You can disable hybrid join by preventing one of the requirement elements from triggering hybrid join registration:

  1. Modify the Hybrid Azure ADJoin from the AADConnect (Recommended)
  2. Use the following registry in the computers to block: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: “BlockAADWorkplaceJoin”=dword:00000001
  3. Modify the Scheduled Task which triggers AAD device registration. See Task Scheduler > Microsoft > Windows > Workplace Join > Automatic-Device-Join. See the following 3 items for details:
    1. Deleting the Scheduled Task seems to work reliably.
    2. Disabling the Scheduled Task does not work reliably; the disabled task will still run after a user signs in.
    3. Modify both triggers from an Enabled status to a Disabled status; this works reliably.
  4. Add a firewall block for https://enterpriseregistration.windows.net, to prevent the computer from connecting to the Azure AD Device Registration Service (AAD DRS). See the following item for possible side-effects:
    1. This should only affect the ability to AAD join. If you have Office installed on the Windows device, this might have an undesirable impact on AAD device registration (different from AAD device join) which is required per user for Microsoft 365 Apps (was Office 365 ProPlus) sign-in.
  5. Add a firewall block for the UW ADFS server, sts.domain.com, to prevent the computer from getting an ADFS token to authenticate to the AAD DRS. See the following item for possible side-effects:
    1. Note: this option will only work for as long as you continue to have federated authentication for AAD, which is planned to be removed. This option may be undesirable if there is any interaction with Azure AD applications like Office 365 from the device–those interactions would be blocked.

Ok, that’s great but what if I want to unjoin a Hybrid AzureADDevice? For hybrid Azure AD joined devices, make sure to turn off automatic registration. Then the scheduled task doesn’t register the device again.

Next, open a command prompt as an administrator and enter dsregcmd.exe /debug /leave. Or run this command as a script across several devices to unjoin in bulk.

How to enforce Azure AD Connect to use TLS 1.2 only

To enforce Azure AD Connect to use TLS 1.2 only, run the following Windows PowerShell script in an elevated PowerShell window on each Azure AD Connect server:

$RegPath1 = "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"


New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

Hope it helps!

Monitor Azure AD Smart Lockouts with Log Analytics

Following my last post about Azure AD Smart Lockout, have you ever wonder, how to monitor those events? Of Course, we can do it with Log Analytics

HOW TO MONITOR SMART LOCKOUT?

Integrating the monitor and alerting of Smart Lockout is very simple, this post will explain you how to do it:

  1. In Azure Portal, Select Azure Active Directory > Diagnostic settings -> Add diagnostic setting. select Export Settings from the Audit Logs or Sign-ins page to get to the diagnostic settings configuration page.
  2. In the Diagnostic settings menu, select the Send to Log Analytics workspace check box, and then select Configure.
  3. Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
  4. Select one or both of the following:
    • To send audit logs to the Log Analytics workspace, select the AuditLogs check box
    • To send sign-in logs to the Log Analytics workspace, select the SignInLogs check box
  5. Select Save to save the setting.

Now, what we will need to do is wait, probably in 5-10 minutes we will start to have data into workspace.

The logs we are looking for are in the AuditLogs and SigninLogs tables in the workspace.

SigninLogs
| limit 50

and click on run to get the last 50 sign-ins listed. As we are interested into the actual Smart-Lockouts (ResultType 50053), we need to add a filter criteria to our query and we probably want to limit it to the last seven days only.

SigninLogs 
| where CreatedDateTime >= ago(7d)
| where ResultType == "50053" 

And because we like to get notified, we can also set an Alert Rule on this type of query. Click on New Alert Rule, which will bring you the next blade.

Then we need to reuse and Action Group or create a new one, this is used to be alerted when the signal occurs. we have to be aware that depending of the frequency of the alert, we will be charged in €€€

Another thing to keep in mind is that we will have a lag between the alert and the action when it happens, it’s not inmediately.

that’s all, have fun!

AzureAD Smart Lockout

Have you ever wondered how Microsoft prevents password guessing attacks or brute force attacks on Azure AD? Well, it is basically the same method as you would do on your on-premises User Directory! It is just smarter!

Azure AD Smart lockout is a feature being applied to every sign-in processed by Azure AD, regardless if the user has a managed account or a synced accounts using password hash sync or pass-through authentication.
The smart part comes from the ability to distinguish valid users from attackers. It locks out the attackers while letting your users continue to access their accounts and be productive.

smartlockout

If you still run ADFS, there is also a Feature available named Extranet Smart Lockout but this one is not as smart as the one in Azure AD. https://support.microsoft.com/en-us/help/4096478/extranet-smart-lockout-feature-in-windows-server-2016

The default lockout setting kicks in after ten invalid login attempts for one minute. The account locks again after each subsequent failed attempt, for one minute at first and longer periods in subsequent attempts. Also, smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password, basically, if the same bad password is entered multiple times, it will not cause another lockout.

Note: The monitoring of the same sign-in attempt is only available for the Password Hash sync scenario, as the Pass-Through password validation happens against your on-premise AD domain controllers.

Smart Lockout is always turned on for all Azure AD customers. If you want to modify the default behavior of 10 invalid attempts to trigger a one-minute lockout, then you require Azure AD P1 or P2 licenses for your users.