Security

Azvise

10 tips to improve your administrative accounts posture in Azure AD


General Introduction

As I speak to more and more customers about the matter, I notice that a lot of companies have a questionable security posture regarding their administrative accounts. For example, many admins are using their “daily-runner” account as privileged administrators for their tenants, or synchronizing their domain admins to privileged roles in Azure AD. In general, a lot of admin accounts aren’t getting the care they deserve.

Losing privileged access is a big deal and it’s happening more and more often. Clearly, attackers love targeting privileged accounts because they give them quick and broad access to a company’s important assets, leaving a lot of defences behind.

I decided to write this article to highlight some of the controls that should be implemented in our tenants to improve our admin accounts posture, as privileged access management should be one of our top security priorities. These points have been aggregated after a lot of discussions with colleagues and experts on the topic and with the help of best practices from Microsoft Docs.


The 10 tips list

As a best practice, administrator accounts should be: 

  1. Separate from your daily-runner account. Collaboration tasks should not be done from the administrative accounts. While it’s of course not convenient, admins should get used to handling multiple accounts for different permission levels.
  2. Cloud-only. Your Azure AD administrator accounts should be different to your on-premises admins, and should not be synchronized from the on-premises Active Directory. This is because if one’s identity gets breached, the attackers would have easy access to both Azure AD and AD.
  3. Mailbox-less. The easy way to implement this is by not assigning admins licenses. You should enable a forward from your admin account to your daily driver account, or a dedicated mailbox/distribution list assigned to an unprivileged user. 
  4. Using phishing-resistant authentication methods. FIDO2 keys should be your primary way of accessing your admin accounts. If FIDO2 keys or similar methods are unavailable to you, you should have at least MFA active on your account with number matching and additional details active. Ideally, you should also restrict access to your resources to only allow access from known devices.
  5. Reviewed periodically. Periodically analyse the list of admins, and remove excessive permissions. There are a lot of cool tools that can help you out with this, or you can script your own.
    Microsoft suggests analysing these roles first, then moving to the other administrative accounts: Global Administrator, Privileged Role Administrator (they are a click away from being Global Admins), Exchange Administrator, and SharePoint Administrator. Remove guest admins where applicable.
  6. Protected by Identity Protection. Identity Protection automatically scans your sign-ins and blocks the user if anything strange is going on. You can also configure it to force the user to do a self-service password reset.
  7. PIM-enabled. You should have administrative privileges only when you require them. Having admin privileges active on an account 24/7 without a specific reason is not the best idea. Moreover, whenever you enable your PIM roles, you get an email, to keep everything under control.
  8. Backed up by one or two emergency accounts. If bad things happen, you should still be able to access your tenant. Emergency access administrators help you with that. You should also consider activating a rule to alert you when this admin gets used. Here is a cool guide to create passwordless emergency admins with FIDO2 Keys: https://janbakker.tech/break-glass-accounts-and-azure-ad-security-defaults/
  9. Logged constantly. Configure logging for your tenant by exporting the Azure AD logs to a Log Analytics workspace. Alerts should be configured for risky actions (like modifying a conditional access policy). Also, check if you have enabled the Unified Audit Logs: https://azvise.com/2021/10/26/office-365-enable-unified-audit-logs/
  10. Protected with Conditional Access Policies. This is a very broad topic, but make sure that at least the following apply. Those policies can be created quickly using Conditional Access policies templates: Require phishing-resistant multifactor authentication for admins, Securing security info registration, block legacy authentication, require multifactor authentication for Azure management, Require compliant or hybrid Azure AD joined device for admins, Block access for unknown or unsupported device platform, No persistent browser session. Of course, before activating this policies, be really careful to test things out and exclude the emergency account(s).

Additional points:

  • Use precise Administrative roles. Of course, using highly privileged accounts it’s convenient, as you have only to activate one role to manage everything. But if you assign people the correct permissions they need for their daily job, a lot of headaches can be prevented. Check out this documentation page to ease the pain of finding the right role to assign:
    https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
  • Consider Privileged Access Workstations. Having PAWs for Admin roles can help a lot with your security posture. PAWs can be configured on Azure AD with device filtering rules in Conditional Access Policies. For example the CAP may require: When all admins, except for the emergency access administrator, access all apps, block access unless they are using specified devices, filtered by device ID.
    These PAWs should be AAD joined, and are usually for Global Admins and Privileged Role Administrators. Also, having Bitlocker on at least this machines is a must.
    Spoofing device IDs with Powershell is sadly possible at the moment, but it’s kinda hard and not one of the first things that attackers will do. As always, a lot of this depends on your security risk acceptance level.
    If you want to drill down on PAWs, this article might be useful: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
  • If you have an on-premises AD, you should really look into improving your AD security, as your AAD security and your AD security are tightly correlated. A tiering model for Active Directory is really useful to better manage your forests, and implementing Defender for Identity gives you a whole new level of analysis and reaction on what’s going on. This won’t be discussed here, but there are plenty of resources to get started with this. Also, again, don’t sync your on-prem administrators to Azure AD. You should have some level of filtering from on-prem to Azure AD, such as filtering by OU or by AD attributes.
  • Also not discussed here, as Azure permissions are a whole topic by themselves, but you should really be analyzing Azure privileged permissions and keeping everything under control.


Link to Microsoft docs, and additional reads:

Securing privileged access

Ensure separate user accounts and mail forwarding for Global Administrator accounts

Enterprise access model

Token Protection

Azvise

A vulnerability assessment solution should be enabled on your virtual machines – Azure

  1. General introduction
  2. Step-by-step guide
  3. Sources

General introduction

This is one of the more common alerts that may come up when you activate Defender for Cloud. This message comes up when a vulnerability assessment solution is not found in at least one virtual machine in your environment.

What happens behind the curtains? Azure virtual machine servers are constantly checked for infrastructure security misconfigurations by Defender for Cloud, which offers advice on how to fix them. Through integrated Vulnerability Assessment solutions or via agents and extensions, Defender for Cloud can also report on vulnerabilities found and the OS or application level. Since these “agents” must be configured for the process to work, you should configure the automatic provisioning of vulnerability assessment solutions on your virtual machines.

A valid VA solution is one of the following:

  • Microsoft threat and vulnerability management, included in both the Defender for Servers plans (P1 and P2). This is now the suggested solution, especially if you already use Microsoft Defender for Endpoint. You should not confuse this with the Microsoft Defender Vulnerability Management Add-on, which has a really similar name but is a different feature included with Defender for Servers Plan 2.
  •  The Qualys agent, also included in Defender for Servers, but just in Defender for Servers Plan 2. This used to be the default choice in the past.
  •  A Bring Your Own License Qualys or Rapid7 agent configured to integrate with Defender for Cloud. If you are looking at ways to incorporate them, follow this article: Integrate security solutions in Microsoft Defender for Cloud | Microsoft Docs

As we said, Microsoft threat and vulnerability management is the default solution to fix this recommendation. The only case I would use something else is if you already have Qualys or Rapid 7 in your environment and want to manage everything from a single pane. Defender for Endpoint will be onboarded in the VM through the MDE.Windows extension.

Step-by-step guide

To automatically enable a vulnerability assessment solution and resolve the alert:

  • Search Defender for Cloud from the Azure Portal (portal.azure.com)
  •  From Defender for Cloud’s menu, click on Environment settings from the left bar.
  • Click on the subscription the resource is in.
  • In the top bar, click on Settings & Monitoring.
  • Turn on (if it’s not already enabled) the vulnerability assessment for machines and select the solution you wish to use. I’ll enable Microsoft Defender vulnerability management.

Once you are done, wait for the check to be triggered again. The alert should go away automatically after 24 hours.

Sources

https://learn.microsoft.com/en-us/azure/defender-for-cloud/auto-deploy-vulnerability-assessment

Azvise

Temporary Access Pass sign in was blocked due to User Credential Policy

General introduction

Temporary Access Pass is a time-limited passcode that allows users to register passwordless methods or recover access to their accounts without knowing their password. It is enabled via an authentication method policy that you can configure in Azure Active Directory. Apart from being time-limited, the TAP can also be configured for one-time use only. This can either be configured on the authentication methods policy so that every TAP created will be one time only (not the best idea at the moment) or at the creation of the TAP on the user authentication methods page.



The issue

The “Temporary Access Pass sign in was blocked due to User Credential Policy” issue is caused by the fact that the user has already used the TAP, and it was configured not to be valid for a second login. To fix this, modify the policy and allow for multi-use TAPs (if it’s not already enabled) then issue a new TAP.


While it makes sense from a general prospective to enable it for one-time use only at the policy level, this is usually impractical. For example, if you are using Autopilot, you’ll be requested to enter your credentials twice before configuring Windows Hello for Business. The first time, you’ll be asked for it at the enrollment phase, and the second time when logging into the user account for the first time. A one-time use TAP policy will create issues in this case. It’s also very common for users to mistakenly log off before configuring a passwordless method. If they do, you’ll need to issue a second TAP. For these reasons, it makes sense to allow a stricter lifetime but allow it to be used multiple times in that timeframe.

Modify the Temporary Access Pass policy:

  • Open authentication methods, then Temporary Access Pass. Authentication Methods | AAD
  • From here, go into Configure. If it’s already set to no, then proceed to the next step. If it’s set to yes then click on Edit.
  • From here, click on Require one-time use, and set it to no. Then save.

Issue a multi-use TAP:

  • Head into All Users | Azure AD, then select the user you want to issue the TAP to.
  • Click on Authentication Methods, then Add authentication method.
  • From the dropdown list, select Temporary Access Pass. Make sure One-time use is on No, then click on Add
  • Send the user the new TAP
Azvise

How to enable and disable Security Defaults



General introduction

Security Defaults are one of the ways to establish a fundamental identity security baseline for your tenant. Security defaults are a set of security settings to help you protect your organization from the most common security threats. They can be enabled on a tenant with just one click. Well, two, if you count the save button. These settings are aimed at small and medium businesses that might not have an IT team with the knowledge or resources to manually set the standard for their environment. 

If you are currently using Conditional Access Policies, Security Defaults are probably not for you. In more complex environments, going the Conditional Access way can be trickier to manage but provide more benefits, such as the ability to require access from known and compliant devices. Also, Conditional Access Policies require Azure Active Directory Premium P1, and only some organizations are licensed for it.

If you wish to learn more about Conditional Access, I wrote a post about it:

https://azvise.com/2023/01/03/what-are-conditional-access-policies-in-azure-ad/

Security Defaults are now activated by default in all the newly created tenants since October 2019, and Microsoft is rolling them out to existing tenants who don’t have Conditional Access Policies enabled.

What Security Defaults will do is:

  1. Requiring users to register for MFA using the Authenticator app. Users will have 14 days to comply before being required to do so.
  2.  Requesting MFA for both users and administrators, especially when a user accesses privileged portals.
  3.  Block legacy authentication protocols which can’t support MFA.




How to enable Security Defaults

  1. Access the Azure AD properties with an admin account by clicking on the following link, or navigating through the portal to Properties: Azure AD Properties | Azure Portal
  2. Click on Manage Security Defaults at the bottom of the page
  3. Set the Security Defaults to Enabled
  4. Save



How to disable Security Defaults

  1. Access the Azure AD properties with an admin account by clicking on the following link or navigating through the portal to Properties: Azure AD Properties | Azure Portal
  2.  Click on Manage Security Defaults at the bottom of the page
  3.  Set the Security Defaults to Disabled
  4.  Provide a reason for disabling Security Defaults
  5.  Save

Notes

If you wish to learn more about Security Defaults, refer to the following documentation page:

Security Defaults | Microsoft Docs

Azvise

How to configure passwordless in Azure AD connected environments

  1. General Introduction
  2. Windows Hello for Business and FIDO2 security keys
  3. Enable FIDO2 security keys
  4. Register a FIDO2 key
  5. Test the FIDO2 key
  6. Configure security keys as a sign-in option in Windows
    1. Enable with Intune for all users
    2. Targeted Intune deployment
    3. Enable with Group Policy
    4. Force sync on a single device
  7. Windows Hello for Business deployment for AAD joined devices
    1. For all users
    2. For specific groups
    3. Force sync on a single device
  8. Conclusion
  9. Sources and additional reads




General Introduction

As we all know, passwords are a weak link in our identity processes. But, contrary to what we believe, your password length is not the main enemy when talking about Azure AD, as long as your passwords are not simple. Instead, the main enemy is that passwords can be easily gathered and reused from phishing attacks or breaches. 

The most common attacks, for example, phishing, password spray and credential stuffing, all rely on the fact that your password is either given by the user to the attacker, guessed because it was really simple, or already exposed to attackers because of previous breaches in 3rd parties attacks. Also, in the case of password spray, Azure AD has functions in play to drastically reduce the speed of password spray attacks and increase the time attackers spend guessing a password.

Image from the Microsoft Docs

Regarding why your passwords mostly don’t matter, Alex Weinert, Director of Identity Security at Microsoft, wrote a wonderful article way back in 2019 that I suggest you read:

Your Pa$$word doesn’t matter | Tech Community

But, if you still need to start modernizing your application log-in processes, and most applications in your environment rely only on either Active Directory or Active Directory Federation Services, please still consider a more complex password. In this case, the standard is usually set at 15+ characters, as when a password is created of more than 14 characters, you don’t store the LM hash for it. Of course, you can also disable LM hashes with GPOs, but most places aren’t doing it.

The aim of this post, though, is to discuss Azure AD-connected systems, applications, and cloud-only environments. 

If you haven’t heard of it, you can either natively attach most applications to Azure AD or use Azure AD Application Proxy. Azure AD Application Proxy allows Azure AD to take the reins by letting it manage the authentication and access to the on-premises legacy applications.

MFA does put a patch on the issue of passwords. For now, if everyone had (preferably strong) MFA on their accounts, the compromises would go way down, as the attackers’ costs would go way up. But, as we said, MFA is a patch, not a permanent fix. 

For example, many companies still rely on legacy authentication methods, which do not support MFA, or there are cases where MFA gets “skipped” with the use of man-in-the-middle attacks (such as the ones that can be conducted using evilginx2). While it’s not really a “skip”, it’s functionally a bypass of MFA functions.

Image taken from https://github.com/kgretzky/evilginx2

While passwordless methods are more secure and convenient, you should know that there is a better and worse ranking. 

For example, adopting passwordless using the Microsoft Authenticator still puts you at risk of being phished with men-in-the-middle attacks, such as the ones we talked about before, and logging into Windows devices with the Authenticator is not supported at the moment. 

Suppose you have a Conditional Access Policy that requires devices to be compliant. In that case, the Authenticator makes more sense as a passwordless method, as you add an additional layer of verification before accessing your company data.

Image taken from Microsoft Docs

Because FIDO2 Keys are not supported on mobile devices, the Microsoft Authenticator is still the best passwordless option for iOS and Android devices. It’s also a very common method for MacOS and Linux users.

As a side note, most of the time, instead of signing in with the Authenticator, on mobile you’ll be able to select “Sign-in options” and be presented with the option of signing in from another device, such as a desktop, where you’ll be able to use FIDO keys.


You can check out the state of FIDO2 Keys support on mobile devices on this page: FIDO2 Keys compatibility | Microsoft Docs

We’ll discuss the other two passwordless methods in the next chapter.



Windows Hello for Business and FIDO2 security keys

Windows Hello for Business and FIDO2 keys directly communicate with the service you are authenticating to. As such, they can only initiate the login flow if you are connected to the right page. And while this is already placing them up in the ranks, they can also provide access to Windows devices from the lock screen.

It’s worth noting that while Windows Hello for Business needs setup on every machine, FIDO2 keys can attach directly to the Azure AD user, making it way easier to use if the user is not always connected to the same device, as it happens with front-line workers. This happens because FIDO2 security keys store the credentials on the key, unlike Windows Hello for Business, where the key pair is bound to the TPM.

It’s also worth noting that Windows Hello for Business can (with some complex deployment options) also integrate with on-prem resources. One such use case is using Hello for Business with certificates to allow integration with the RDP protocol:

Deploy certificates for remote desktop (RDP) sign-in | Microsoft Docs

Here is a small table that recaps what methods are available, based on device type.

DeviceAD FS or Azure AD native certificate-based authenticationFIDO2 security keysWindows Hello for BusinessMicrosoft Authenticator with compliant device CAP
Windows deviceCheckmark with solid fillCheckmark with solid fillCheckmark with solid fillCheckmark with solid fill
iOS mobile deviceCheckmark with solid fillNot applicableNot applicableCheckmark with solid fill
Android mobile deviceCheckmark with solid fillNot applicableNot applicableCheckmark with solid fill
MacOS deviceCheckmark with solid fillEdge/ChromeNot applicableCheckmark with solid fill


While we are on the topic, you can configure users with a one-time-use Temporary Access Password to make users passwordless from day one, but the topic will be discussed further down.

A very useful page to plan your passwordless implementation is the following. It guides you through a wizard that proposes the best options for your use case depending on what your users use.

Passwordless Setup | Microsoft Admin Center

While not discussed here, Azure AD Certificate-based authentication is also a strong and phishing-resistant passwordless method. Since it's now natively integrated into Azure AD, it makes a lot of sense for companies that used to rely on ADFS to achieve the same passwordless result.



Enable FIDO2 security keys

To enable users to use FIDO2 keys, first sign in to the Authentication methods page, then click on FIDO2 Security Key:

Authentication Methods | Entra

From the menu, select “Enable“, then either “All users” if you want the entire organization to be able to use FIDO2 keys or scope the deployment to a specific group. You may also scope the feature to “All users” but exclude a specific group of people.

Under “Configure“:

  • You’ll generally want to leave “Allow self-service set up” set to “Yes“. This allows people to set up their keys.
  • “Enforce attestation” to “Yes“, as it allows to verify the quality and certifications of the key.
  • Enforce key restrictions to “No“, as it allows you to set which FIDO keys are allowed by the org and what keys are not.  

Save and end the setup.



Register a FIDO2 key

Before registering a FIDO2 key, the user will be prompted to setup MFA. If you want the user to directly use FIDO2 keys as an authentication method, you can create a Temporary Access Password for them. This will skip the MFA prompt and let the user configure directly the key.
To create a TAP, follow this guide: Configure a Temporary Access Password | Entra

For this tutorial I’ll be using a YubiKey 5 NFC.

  • Log in to https://mysignins.microsoft.com/security-info. Logging in Private Mode might mess up some of the process. Ensure you are using a normal browser page.
    • If you are using Temporary Access Passwords, the user will be prompted to use it to authenticate.
    • If the user had MFA configured, the user will be able to configure the FIDO2 keys directly
    • If the user is authenticating with password-only, the user will be prompted to configure MFA as an additional step.
  • Click Security Info. In this case the user had MFA configured, so we can go straight to FIDO2 keys.
  • Click on “Add method“, then “Security key”.
  • Click on either “USB device” or “NFC device”. In my case, using a YubiKey 5 NFC, I’ll select USB, since I have it attached to the device. Note that this is just for registration, any method can be used for signing in after registration.
  • Insert the key, then press “Next“.
  • You will be redirected to a browser prompt, asking you to create a passkey. Select “External security key or built-in sensor“
  • If prompted, accept the following pop-up.
  • Create a PIN for your Security Key, then perform the gesture, such as touching the sensor.

  • Now give the key a name, so that you may recognize it. I generally suggest the ” Vendor + model” naming convention.
  • Click Done.
  • Now if you log-off, you’ll be able to test out the new key.

Test the FIDO2 key

Once you are done with the setup, try signing in with the key. To do that:

  • Access office.com or any other portal, then select “Sign-in options“.
  • Select “Sign in with Windows Hello or a security key“. This might come up as just “Sign in with a security key“.
  • Attach your Security Key, then insert your PIN
  • Perform the gesture, such as touching the sensor.

If all went well, you’ll access the portal.



Configure security keys as a sign-in option in Windows

Before starting, please be aware that for sign-in in Windows, you’ll need the machine to be at least version 1903. There are no requirement on the join type, as FIDO2 keys can be used for both Azure AD Joined devices and Hybrid-AAD Joined devices.

Enable with Intune for all users

To use FIDO2 keys on Windows devices for all users in your tenant:

  1. Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
  2. Click on Use security keys for sign-in, and set it to Enabled.

Targeted Intune deployment

To target specific device groups to enable the credential provider, use the following custom settings via Endpoint Manager:

  • Open the following link, or go into Devices, then Configuration Policies. Configuration profiles | Intune
  • Select Create a profile, then click on Windows 10 and later, Templates, Custom.
  • Name it however you prefer, preferably specifying FIDO Keys in the title.
  • After clicking Next, configure the next as follows:
    • Name: Whatever you want, I chose FIDO2 for Windows Sign-in
    • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
    • Data Type: Integer
    • Value: 1
  • Once you are done, configure the Assignments, then complete the wizard.

Enable with Group Policy

If you are not using Intune, you can enable the feature using GPOs. In this case only Hybrid Azure AD Joined devices are supported. Once you have created the GPO, the setting is located under Computer Configuration \ Administrative Templates \ System \ Logon. Next, click on Turn on security key sign-in, and set the policy to Enabled.

Force sync on a single device

If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune. 

Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask



Windows Hello for Business deployment for AAD joined devices

An option for configuring WHfB is by using Intune device enrollment. The settings are placed under Windows enrollment settings and only allow scoping to all users.

If you want to do it more granularly, you can deploy a configuration policy that will do the trick. Note that the configuration policy has more options, such as “PIN recovery” and “Certificate for on-premise resources”.

For reference, you can also create GPOs and configure hybrid and on-premises services to deploy Windows Hello for Business, but that won’t be discussed in this article as it would be worth a dedicated article.

For all users

  • Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
  • Click on Use security keys for sign-in, and set it to Enabled. Enabled will configure WHfB for all devices. Not configured will be used if you still want to use the feature but you don’t want Intune to manage it.
  • Review the image below and use it freely as a template for the settings. This is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards. One note, it’s generally a good idea to require TPM if your devices support it.

For specific groups

  • Open the following link, or go into Devices, then Configuration Policies. Configuration profiles | Intune
  • Select Create a profile, then click on Windows 10 and later, Templates, Identity protection.
  • Give the policy a name, then click Next
  • As before, this is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards.
  • Once you are done, configure the Assignments, then complete the wizard.

Force sync on a single device

If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune. 

Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask

Conclusion

I hope this post was useful to you. If you spot any mistakes, feel free to reach out to me on Twitter or Linkedin.

Sources and additional reads

Various Microsoft Docs, in particular:

https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key

https://learn.microsoft.com/en-us/azure/active-directory/standards/memo-22-09-multi-factor-authentication

https://learn.microsoft.com/en-us/mem/intune/protect/windows-hello

The Yubico reference guide:

Click to access User_Enablement_Guide.pdf

Azvise

What are Conditional Access Policies in Azure AD


What are Conditional Access Policies?

Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources based on certain conditions. We can summarize them as if statements that govern what will be requested, enforced or blocked. As identity has become a key focus for security efforts, it’s essential to manage it in the best way possible.

All policies “think” at the user level and are enforced after a user has completed the first form of authentication, such as entering their username and password. As such, an attacker could understand if the credentials are correct even if there are blocks dictated by CAPs that might block access based on various signals.

Conditional access policies are implemented using Azure Active Directory, which is the cloud-based identity and access management service that is part of Microsoft 365. As of right now, Azure Active Directory (or Azure AD for short) is being integrated into the newly created Entra product family.

It’s important to note that Conditional Access Policies will manage not only native Microsoft apps such as SharePoint, Teams, the Azure Portal, etc. but also all SaaS applications connected to Azure AD and all on-premises applications managed through Azure AD Application Proxy.

This can simplify the management of identities, as, for example, the user will have their MFA methods set in Azure AD, and they’ll be requested on all connected apps in Azure AD for which you have set Azure AD as the identity provider.

In most organizations, the CAPs enforce requirements such as the enforcement of MFA, the block of logins using legacy protocols and requiring a compliant device to access company resources.

It is advisable to create or make changes to CAPs only if you have a basic understatement of the service and always operate with caution since you could risk blocking access to the tenant for all users.

Please consider implementing an emergency administrator before starting with Conditional Access, and exclude it from all the policies. Read more regarding this here:

Manage emergency access accounts in Azure AD

All Conditional Access policies must grant a user access before they can access a cloud app. If one of the CAP blocks the sign-in, the request will be denied. Note that if in the same policy you both include and exclude a user, the user will be excluded.

I wrote a post on how to check which policy is blocking a user sign-in. If you are curious, you can check it out here:

https://azvise.com/2022/05/24/how-to-check-which-conditional-access-policy-is-blocking-a-user-log-in/

If you are creating a new policy, it can be set to “Report-only” mode first. This will allow you to use insights and reporting workbooks to evaluate the impact of the policy before you go on to apply it to everyone in the organization by turning it “On”. Alternatively, you can keep the policy inactive by setting it to “Off”. Please note that a certificate request might pop up on Macs or mobile devices if you require a check for Intune compliance in the policy, even if it’s in report mode.


Licenses and Security Defaults

As Conditional Access Policies require Azure Active Directory Premium P1, only some organizations are going to be able to use them. If you are not licensed for it, you use Security Defaults to establish a basic security baseline for your tenant. Security Defaults are now activated by default in all the newly created tenants. What Security Defaults will do is:

  1. Requiring every user to register for MFA. Once enabled, users will have 14 days to register before being required to do so.
  2. Requesting MFA for both standard users and administrators, especially when a user accesses privileged portals.
  3. Block legacy authentication protocols which can’t support MFA.


Templates and JSON

There is currently a set of recommended policies that you can deploy right away by clicking on “New policy from template” at the following link:

Conditional Access Policies | Azure AD

The templates are categorized in:

  • Secure foundation
  • Zero Trust
  • Remote work
  • Protect administrator
  • Emerging threats

While the templates are a very quick and easy way to start with CAPs, please exercise extreme caution. Even though they are created in report-only, they will not, for example, create a break glass admin and exclude it by default. If you mess up, you might end up locked out. Also note that it’s best to exclude users from CAPs using groups so that you don’t have to modify the policies constantly, which might end up in errors.

A cool new feature is the ability to implement CAPs using JSON templates. You’ll be able to export the policies you have created and be able to import them back in case anything happens.

To learn more, refer to the following documentation:

Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn

Azvise

What’s SMS Authentication and how to enable it in Azure AD


What’s Text Message Authentication

SMS-based authentication allows users to log in without needing to remember their username and password. After enabling the feature for an account, users can enter their phone number at the login prompt instead of their username. They will then receive an authentication code via text message that they can use to complete the login. 

This service is often mistaken for SMS-based Multi-factor Authentication, but they are not the same.

This authentication method makes it easier for frontline workers to access applications and services. It’s not recommended to enable this feature for users who could use other passwordless methods or a combination of credentials + MFA. It’s also important to note that the desktop Office apps do not support SMS-based auth. Therefore, you can only use the web app version of the apps and only by logging in via office.com. You also cannot use the mobile version of the apps, except for Teams, Company Portal and Microsoft Azure.

If you decide to enable the feature, you should consider limiting and standardizing the frontline worker’s permissions to what’s necessary.

If you are curious why you should prioritize other methods over phone-based auth, consider reading this always relevant article by Alex Weinert:

It’s Time to Hang Up on Phone Transports for Authentication – Microsoft Community Hub


Critical Considerations

  • SMS-based authentication isn’t compatible with Azure Multifactor Authentication.
  • The only mobile apps that support SMS-auth are Teams, Company portal and Azure.
  • The users will need to use the web version of the Office apps and log in via office.com.
  • You’ll have to set up phone numbers for each account before the users can sign in.
  • A phone number can only be associated with one user.
  • If you have alternatives to phone-based auth methods, use them.


General Requirements


PERMISSIONS:

  • Being a Global Admin for the tenant

LICENCES:

  • Each user enabled for the feature must have one of the following:
    • Microsoft 365 F1 or F3
    • Azure Active Directory Premium P1 or P2
    • Enterprise Mobility + Security (EMS) E3 or E5 or Microsoft 365 E3 or E5
    • Office 365 F3


Tips

  • You can assign phone numbers to users using PowerShell for an easier setup experience.


How to enable the feature

  • Create a group with the users that’ll need to authenticate using SMS.
  • Open Authentication Methods | Azure AD
  • Click on SMS (Preview). The feature is not in preview anymore, even if the portal states so at the moment of writing this guide.
  • Click on “Yes” under “Enable”, then “Select groups”, and select the group you created in the first step. Complete the step by clicking “Select” and “Save”.
  • To set a phone number, go into All Users | Azure AD, then select a member of the group you created in the first step.
  • Go into “Authentication methods”, then click “Add authentication method”. From there, select “Phone number” and insert the phone number the user will use to sign in, then click “Add”.
  • You can also add an authentication method via PowerShell: 
# Replace the variables with the user you wish to add the auth method to and phone number you wish to assign

$User = "user@example.com"
$PhoneNumber = "+1 111111111"

Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta

New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber

# Get the phone number of the user

Get-MgUserAuthenticationPhoneMethod -UserId $User

If you need to script this for multiple users, you can refer to the code below.

This script assumes you created a CSV file in “C:\” named contacts.csv, and that the CSV file has a column named UserName and a column named PhoneNumber. If your CSV file has different column names, you will need to update the script accordingly.

# Install the modules and login to Graph

Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta

# Import the CSV file containing names and phone numbers

$contacts = Import-Csv -Path "C:\contacts.csv"

# Loop through each user and add their phone number for authentication
# If you changed the column names, replace these placeholders with the actual column names from the CSV file


foreach ($contact in $contacts)
{
    $User = $contact.UserName
    $PhoneNumber = $contact.PhoneNumber
    New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber
}



To learn more, refer to the following links:

SMS-based Authentication | Microsoft Docs

SMS-based Authentication – Supported apps | Microsoft Docs

Azvise

What is Microsoft Purview Customer Key?

Microsoft Pureview Customer Key (or Customer Key for short) is an encryption service mainly aimed at resolving regulatory issues with the adoption of Microsoft 365. This is the product you need in the Microsoft Cloud environment if you have a regulatory requirement to have ownership and control over the keys used to encrypt data at rest.

Microsoft 365 already provides volume-level encryption through Bitlocker and Distributed Key Manager (DKM), but you have no control over the encryption keys used. Customer Key can encrypt with your keys data from Exchange Online, Skype for Business, SharePoint Online, OneDrive for Business, and Microsoft Teams. The Microsoft services will use your key to make the various systems work.

You’ll have the option to let Microsoft generate your RSA Keys or upload your own. All the key management capabilities are done through Azure Key Vault. Once Microsoft checks that everything is going well, Microsoft 365 uses your keys to encrypt data at rest.


While Customer Key adds additional security against unauthorized access to data, it’s not intended to restrict Microsoft employees’ ability to access your data. Instead, that feature is provided by Customer Lockbox. Customer Lockbox ensures that Microsoft can’t access your data without your consent.


Critical Considerations

  • Once you encrypt SharePoint Online, OneDrive for Business, and Teams, there is no going back to Microsoft Managed Keys.
  • The loss of the root encryption keys can have catastrophic consequences. Various precautions can be taken to avoid common errors but keep this in mind.
  • Microsoft keeps an availability key, which functions the same as your two keys. This key is used by automated processes and aims to provide recovery capabilities from the loss of the root keys you manage. To learn more follow this link: Availability Key in Customer Key | Microsoft Docs


Features limited by this service

  • None that I’m aware of


General Requirements

PERMISSIONS:

  • Being a Global Admin for the tenant

REQUIRED LICENCES: (One of the following types)

  • Office 365 E5
  • Microsoft 365 E5
  • Microsoft 365 E5 Compliance
  • Microsoft 365 E5 Information Protection & Governance SKUs
  • Microsoft 365 Security and Compliance for FLW

AZURE:

Generally, the ability to create Subscriptions and an Owner role in those subscriptions. The subscriptions will host the Azure Key Vaults that will contain your keys.

  • Ability to create Azure Subscriptions and Resource Groups
  • Ability to modify permissions on Azure Subscriptions and on resources
  • Ability to create and manage Azure Key Vaults and related keys


Tips

  • You can leverage the Hardware Security Module (HSM) key protection by using a Premium Key Vault


To learn more, refer to the following link:

Customer Key Overview | Microsoft Docs

Azvise

Add or remove a user from a Conditional Access Policy (CAP) – Azure AD


What are Conditional Access Policies?

Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources. We can summarize them as if statements that govern what will be requested, enforced or blocked.

In most organizations, the CAPs govern the enforcement of MFA, the block of logins using legacy protocols, and requiring a compliant device to access company resources.

All policies “think” at the user level.

It is advisable to make changes to CAPs only if you have a basic understatement of the service, since you could risk blocking access to the tenant for all users. In order to learn more, refer to the following documentation:


Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn


General considerations

  • It’s a good idea to manage exclusions using Groups. This way, you won’t have to directly modify the policy every time.
  • Since many policies are scoped to include all users, you’ll have to handle exceptions with the “exclude” feature.


How to add or remove a user

  • Log in to Conditional Access – Microsoft Azure
  • Select the desired policy
  • If you intend to add a user to the policy, click on the blue link under “Users or workload identities”, then “Include,” and click the blue link under “Users and groups”.
  • Select or search for the desired user, then click “Select.”
  • If you want to exclude a user, click on the blue link under “Users or workload identities”, then “Exclude,” and click on the blue link just below “Users and groups.” The same user selection screen shown in the previous step will open. Search for and select the user, then click “Select.”

Once done, save using the “Save” button at the end of the page. If the policy is in “Report-only” or “Off“, the flow is not active.

Azvise

Enable file monitoring for Office 365 in Defender for Cloud Apps – DCA

Before enabling file monitoring in Defender for Cloud Apps, be sure to have the appropriate licensing assigned. To follow these steps, you’ll need the following:

  • An Information Protection licence
  • A full Defender for Cloud Apps licence. A Microsoft Defender for Cloud Apps Discovery license is not enough.

Please note that you’ll have to create a file policy as soon as you enable the feature. If you don’t create a file policy in the first seven days, the feature will be disabled.

First, log into the Defender for Cloud Apps portal:

Defender for Cloud Apps Portal

Then, click on Settings in the top right corner

Go into Files under the Information Protection tab. If you don’t see this section, please check the license you have applied to your user.

Enable file monitoring, then save. Once done, click on “Connected Apps”

Click on the three dots at the right of Office 365. If the application is not there, add it.

Click edit settings, then check “Office 365 files”. Finally, click “Connect”, then close the panel to finish up.

Azvise

Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. – Azure AD

Suppose you or a user reset a password, and one of the following errors comes up. In that case, it means that either you are using a guessable password or that somebody in your organization has enabled Password Protection in your environment, and you are using a banned word.

  • Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. Please try again with a different password.
  • “Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.”

If you are a user, please try a more complex password to circumvent the error. Substituting @ with A, 1 with I, and other widespread ways of changing up a common word will not be counted as “not including a common word”.

If you are an admin, please note the following about this feature. Users often create passwords that use common words based on personal interests or easily rememberable things (e.g. cities, sports teams, celebrities, months, etc.). These passwords are strongly vulnerable to dictionary-based attacks. Azure AD Password Protection, which works either in a “cloud-only” mode or can also synchronize to on-prem, provides a global and custom-banned password list. The global one is maintained directly by Microsoft; the custom one can be modified by the Microsoft 365 / Azure AD admins.

To access the feature settings, click on this link: Password Protection settings | Azure AD

Azvise

This application contains sensitive information and can only be accessed from devices or client applications that meet management compliance policy – Azure AD

This error message results from the application of a Conditional Access Policy on your tenant that blocks users from accessing cloud resources using a non-compliant device. The compliance state of a device is evaluated by Intune. To check which compliance policies you have active in your environment, head to:

Compliance Policies | Intune

To resolve the issue, either fix the device’s compliance state or exclude the user from the Conditional Access Policy.

To fix the compliance state, head into All Devices | Intune, click on the impacted device, and then “Device Compliance“. From there, you can see which policy makes the device not compliant and which setting is “at fault”.

If you are looking to understand which Conditional Access Policy is blocking the user, check out this guide:

How to check which Conditional Access Policy is blocking a user log-in – Azure AD

To learn more, visit: Get started with device compliance | Intune 

To drill down on this type of Conditional Access Policy control, check out this link:

Conditional Access: Require compliant or hybrid Azure AD joined device

Azvise

This application contains sensitive information and can only be accessed from domain joined devices – Azure AD


General information

This error message results from the application of a Conditional Access Policy on your tenant that blocks users from accessing cloud resources without a hybrid-joined device. A Hybrid-joined device is an AD-joined client which gets synchronized to Azure AD via Azure Active Directory Connect (AD Connect).

Another version of this error is:

Try signing in another way
To access your service, app, or website, you may need to sign in to Microsoft Edge using XX account

If you are looking to understand which Conditional Access Policy is blocking users, check out this guide:

How to check which Conditional Access Policy is blocking a user log-in – Azure AD


How to fix

  • If the user is trying to access with a personal device, switching accounts (as suggested in the error message) won’t fix the issue. You’ll need a company owned device.
  • If the user is trying to access it with a company device, then it’s either:
    • Using a personal account, or using the wrong company account. Click on Sign out and sign in with a different account, then sign in with the correct account.
    • Using the right company account, but using Chrome. If this is the case, follow the steps below.
    • Using the right company account on Edge (or on Chrome with the proper extension installed), but the device is not synchronized. To fix this, check if you are synchronizing said device and consider adding it to the right OU / add the right attribute to let it sync.

If you are using Chrome, you’ll either need the Windows Accounts or the Microsoft 365 extensions. These extensions allow Chrome to pass device-specific details. You can deploy the extension automatically using this registry key:


Additional notes

Please note that the “Hybrid join check” type of access control is usually paired with a device compliance check. So expect a possible further block related to this.
To learn more, visit Get started with device compliance | Intune  or read my article on the related error:

This application contains sensitive information and can only be accessed from devices or client applications that meet management compliance policy – Azure AD

To drill down on this type of Conditional Access Policy, check out this link:

Conditional Access: Require compliant or hybrid Azure AD joined device


Sources

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-conditions#chrome-support

Azvise

Restrict access to Azure Management apps – Azure AD

If we want to restrict access to the Azure management services for non-privileged users, we can now create a Conditional Access Policy that allows us to do so.

To create a Conditional Access Policy, we’ll need Azure Active Directory Plan 1 or higher, which is either bought standalone, or can be found most notably inside Microsoft 365 Business Premium, or the Microsoft 365 Enterprise plans (E3, E5)

On the other hand, if we just need to restrict access to Azure AD, we have the option to do so from the User Settings in the Azure AD portal:

User Settings | Azure AD

By creating the following Conditional Access Policy, we will restrict users from accessing these apps:

  • Azure portal
  • Azure Resource Manager provider
  • Classic deployment model APIs
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Azure Data Factory portal
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio subscriptions administrator portal

First, open the following link, or go into your Conditional Access Policies:

Conditional Access Policies | Azure AD

Then, under “Users or workload identities“, select all users, and exclude the admin roles you currently use in your organization. You could also create a security group with all admin users as members and then exclude it from the policy.

Under “Cloud apps or actions”, click on “Selected apps”, then “Microsoft Azure Management“.

Finish up by selecting “Block access” under the Grant Access Controls.

From now on, all users except the admins will be blocked from accessing Azure management services.

Azvise

Additional Context and Number Matching User Guide – MFA

General introduction

In this article I want to illustrate how I would notify my users of the upcoming activation of Additional Context and Number Matching in their MFA requests.

If you are looking for a guide on how to enable Additional Context and Number Matching, follow the guide linked below.

Enable number matching and additional context with Microsoft Authenticator – Azure AD

Feel free to use the message below as your own. The images are taken from the Microsoft Docs.

─────────────────────────────────────────────────────────

User guide

From [replace with activation date] forward, you will be asked to enter additional details in your MFA (Multi-factor authentication) prompts. 

On your PC screen, you will be presented with a number, and you will be asked to enter this same number inside of your MFA request on your phone to complete the approval.  

You will also get a map that will show the location where the request was made from. This must be taken as a general indication and it’s not always going to be your exact location, since Internet providers are not bound to route your connection from a point closest to you.  

Please deny and report immediately to the IT department if you receive a request that was not done by you, or you do not recognize the location you are being shown. 

PC Screen view and smartphone view 

                                                   

Azvise

Find stale Enterprise Applications – Azure AD

If you just blocked users from registering applications, or you are just analyzing your Enterprise applications, you may find that there is a lot of work ahead of you.

First, you may want to find if there are applications with no user assigned. Then you may wonder if there are applications without sign-ins in the last 30 days.

To ease your work, you may find it useful to query all applications for these fields and get the output in a CSV.

This script is freely based on Ravenswood PoC code, with the intent of helping out and refining it a bit.

First, head to Enterprise Applications | AAD and click “Download (Export)”, then download the CSV.

This is done via the portal and not via PowerShell for practicality, since at the moment, to get the same exact filters (e.g. “Microsoft Applications”, “Enterprise Applications”, etc.) that you get on the portal, you would have to query Graph.

Then save this script:

	$AllApplications=Import-Csv .\EnterpriseAppsList.csv
	$applications=$allapplications | where {$_.applicationtype -ne "Microsoft application"}
	ForEach($Application in $Applications){ 
   #Retrieve the objectid and signin logs, format the user assigned to the app 
	$app=Get-AzureADServicePrincipal -all $true | where {$_.objectid -eq $application.id}
    $Log = Get-AzureADAuditSignInLogs -All $true -filter "appid eq '$($App.AppID)'" 

	$userassigned = Get-AzureADServiceAppRoleAssignment -ObjectId $App.ObjectId | Select ResourceDisplayName,PrincipalDisplayName
	$format=$userassigned.gettype()
	if($format.basetype.name -eq "Object"){ 
	$userassigned=[string]$userassigned	
	}
	

    #Create a custom object for output 

    [PSCustomObject]@{ 

        ApplicationName = $App.DisplayName 

        ApplicationID = $App.AppID 

        SignIns = $Log.count
	 
	Users = $userassigned.count
    } 
    Start-Sleep 5
}

And finally, launch it: 

.\StaleApplicationAnalysis.ps1 | Export-csv StaleApplicationCleanup.csv

The output will be along these lines, with an additional column for the App ID:

If you happen to find any optimization, feel free to let me know, and I’ll update the post.

Azvise

Microsoft Secure Score not updating

The Microsoft Secure score is a useful page to get an idea of the general improvement areas you should monitor and approach in your tenant.

When you make a change to reflect one of the improvement actions, you might have to wait up to 48 hours to get the points in the portal.

If you have waited the 48 hours (generally, it’s 24 hours, but the job might fail), check that the policies you created were configured as recommended in the “implementation” tab, then try the following.

First, check if there is some degradation with the service.

If there isn’t degradation, try changing the Conditional Access Policy (or the security policy you enabled) and see if the secure score catches up.

If it didn’t, or you are in a hurry, click on the recommended action, “Edit status & action plan”, and resolve the suggestion as risk accepted, then wait for the score to update. Once you see that the full points are awarded, revert the change. This procedure should “force” the sync to grant you full points, then change it with the actual value.

If the above failed, contact Microsoft Support and request a manual restart of the job.

Either that will solve it, or in some cases, just waiting a couple more days will fix it.

Azvise

Secure Teams, a step by step hardening guide

This is a brief and introductory guide on what you may want to configure and change in a basic hardened Teams environment. Please consider that these are just general recommendations, and what works for a company may not be the best for another one. This is especially true when it comes to setting up collaboration services. Keep in mind that your Teams security is only as good as your identity security. 

It’s helpful to note that some companies require that users should not be able to create new teams, depending on your internal policies. This is done by limiting the creation of Microsoft 365 groups using the following setting: Groups – Microsoft Azure – Users can create Microsoft 365 groups in Azure portals, API or PowerShell. The same is also available via PowerShell in a more complete way. 

Before diving into the settings, you may consider the following, that will not be discussed further, but are non the less important:

  • You should already have a basic hardened Azure AD environment (or AD + AAD if you are in an hybrid scenario). Your Teams security will be only as good as your identity security. For example, if you don’t have MFA set up yet or you are not blocking legacy authentication protocols, you might be better off starting from there.
  • You should consider setting up retention and expiration policies for Teams, especially if you will let users create teams freely.
  • DLP and sensitivity labels should be created and applied.
  • You should monitor user activity often via the Teams portal.
  • Enhanced encryption policies should be evaluated on a company by company basis since it disables recording and transcription.
  • You should start using and configuring Cloud App Security
  • Live event policies should be evaluated based on whether your company uses them.
  • Voice settings should be evaluated on a customer by customer basis, depending on what you have to implement and your general infrastructure.

Follow along by opening the Teams Admin center and evaluating these settings.

Teams -> Teams settings:

  • Turn OFF all external file sharing and cloud file storage options in the Files tab if they are not company approved.
  • “Users can send emails to a channel email address” should be set to OFF, or only specified domains should be allowed
  • “Scope directory search using an Exchange address book policy” controls how users find and communicate with other people in their organization. This may help users out, but it’s not a “must set”.

Teams -> Teams Policies:

  • Consider creating new policies for more granular management. The settings could be left all on if no specific stricter need arises.

Teams -> Teams Update policies:

  • You may want to consider setting “Show Office Preview” as not enabled. This is, however, not critical.

Teams -> Teams Upgrade settings:

  • Coexistence mode should be set to Teams Only if you are not using Skype for Business.

Users -> Guest access:

  • “Make private calls” should be set to OFF since there is mostly no need for a guest to make calls “using” your tenant.
  • “Meet Now” should be set to OFF.
  • “Edit sent messages” should be set to OFF.
  • “Delete sent messages” should be set to OFF.
  • “Delete chat” should be set to OFF.

Users -> External access:

  • Here, you can either allow all external domains, allow only specific domains or only block specific ones. This setting is very dependent on your organization and your risk acceptance level. Most SMBs are blocking specific domains.
  • Allow users in my organization to communicate with Skype users should mostly be set to OFF. The same goes for “People in my organization can communicate with Teams users whose accounts aren’t managed by an organization”.

Teams apps -> Permission policies:

  • You either go for a restrictive global policy or create tailored policies later. Whatever is best for your use case.
  • Third-party apps should be set to Block all apps if you are not using any.
  • Custom apps should be set to Block all apps if you are not using any.

Meetings -> Meeting policies:

  • You either go for a restrictive global policy or create tailored policies later. Whatever is best for your use case.
  • “Let anonymous people join a meeting” should be set to OFF.
  • “Let anonymous people start a meeting” might be set to OFF.
  • “Who can present in meetings” should be set to “Organizers, but users can override”.
  • “Automatically admit people” should be set to “Invited users only”.
  • “Dial-in users can bypass the lobby” should be set to OFF.

Meetings ->Meeting settings:

  • Anonymous people can join a meeting should be set to OFF
  • Anonymous users can interact with apps in meetings should be set to OFF
  • “Insert Quality of Service (QoS) markers for real-time media traffic” is usually set to ON. Not a deal-breaker, but it’s sometimes helpful to get insights.

Meetings -> Messaging policies

  • Owners can delete sent messages should be set to OFF if you don’t need moderation in Teams.
  • Delete sent messages may be set to OFF, if the need arises.
  • Delete chat should mostly be set to OFF.
  • Edit sent messages may be set to OFF, if the need arises.
  • Read may be set to “Turned on for everyone”, but it’s not a priority.
  • Giphy content rating should be set to “Moderate”.

You should set rules under “Notifications & alerts”, as they are more free insights that you get.

If you use Skype for Business, you may want to configure the policies found under Other settings -> Skype for Business.

Azvise

Unblock at-risk user – Azure AD

If a user can’t access your tenant and forwards the following message to you, here are the steps on how you can solve it.

Your account is blocked

We’ve detected suspicious activity on your account.

Sorry, the organization you are trying to access restricts at-risk users. Please contact your admin.

The unblock is done by either resetting the user password or clearing the user risk once you have assessed that the risk is resolved.

  • If you have AAD Premium P2 (you can check it on the overview page of Azure AD), remediate the user risk by following this link Identity Protection | Risky users. A password reset is usually suggested and will also clear the user’s risk.
  • If you do not have AAD Premium P2, you can reset the user’s password or let them do it by themselves by using Self Service Password Reset (SSPR) if you have configured it. Alternatively, you can also go on this page, and ignore the user risk, once you have assessed that everything is resolved: AAD Risky Users. All these methods will clear the user risk.

Allow 10 – 15 minutes before the user can access again without getting the error reported above.

Azvise

How to check which Conditional Access Policy is blocking a user log-in – Azure AD

General Introduction

If you have Conditional Access Policies in place to block certain log-ins, you might get that a user will contact you because their sign-in request is being blocked. Probably both you and the user don’t know which policy is making the log-in fail, since it’s not specified in the error message.

The usual error message is something along the lines of: “Your sign-in was successful, but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app or location that is restricted by your admin.” and the standard error code is “BlockedByConditionalAccess” error 53003

How to solve

To get more details:

  • Click on the failed log-in request
  • Click on “Conditional Access“
  • The Policies that have as a result “Failure” and “Grant Controls” set on “Block” are the ones blocking the user.

Azvise

User blocked due to risk on home tenant – Azure AD

General Introduction

If you just enabled Azure AD Identity Protection for your entire tenant, you might get some complaints from guest users, saying that their sign-in was blocked.

If you got a similar issue, but the user is not a guest but a member of your organization, follow this guide:

https://azvise.com/2022/05/25/unblock-at-risk-user-azure-ad/


You cannot remediate the user risk of a guest. If you try to look for a guest user in Identity Protection | Risky users, you won’t find any.

The user risk is calculated in the “home” tenant, where your user was created, not in the tenant you have guest access / are trying to access. This is also done so that the system may have more insights into user behaviour to calculate the risk.

How to resolve

Now going forward, there are two ways of solving this issue:

  • If the home tenant administrators have AAD Premium P2, they can remediate the user risk by following this link Identity Protection | Risky users. A password reset is usually suggested and will also clear the user’s risk.
  • If they do not have AAD Premium P2, they can reset the user’s password or let the user do it by themselves by using Self Service Password Reset (SSPR), if configured. Alternatively, they can also go on this page, and ignore the user risk, once you have assessed that everything is resolved: AAD Risky Users. All these methods will clear the user risk.

Of course, if you wish, you may disable the user risk policy for guests. This is done by creating a dynamic group in Azure AD containing all the guest (Dynamic security group with a dynamic query of usertype equals guest) and excluding it from the policy.

Azvise

Enable idle session timeout for Microsoft 365

In the last few days, Microsoft implemented a timeout feature for the Microsoft 365 portal and the Office web apps. The aim is to disconnect a user if no activity is received. This will go on to become a global setting: “Idle session timeout for Microsoft 365 web apps will eventually replace current idle timeout settings in Outlook Web App (OWA) and SharePoint Online (SPO)”. This feature is not tab specific, so if you interact with Word (web app), you won’t be signed out from Outlook (web) that you have open in another tab.

You can check out the roadmap here:

Office App: Idle session timeout for Microsoft 365 web apps

I’ve noticed some inconsistencies in the practical application, which will be probably ironed out during the next months.

To enable this feature, open the following link, or go to Settings -> Org setting -> Security & privacy -> Idle session timeout (Preview).

Idle session timeout (Preview)

Click on “Turn on to set the period of inactivity for users to be signed off of Office web apps”, then set the timeout period and click “Save”.

Once you are done, users will get the following prompt if they do not interact with the Office tabs for the configured period.

There is no way of removing the “Stay signed in” option for now, which lets the user keep the sessions from disconnecting.

The GA is expected by June 2022.

Azvise

Outlook requires app password for connecting to Exchange Online

Even if most people use modern authentication for connecting with Exchange Online, some users still have to use app passwords to enable connections from Outlook.

For tenants created after August 2017, modern authentication is enabled by default, but some admins have it turned off.

To enable modern authentication for Exchange Online, follow these steps:

  • Let all the basic authentication protocols selected.
  • Click “Save“.

You should aim to disable all the basic authentication protocols as soon as possible.

To enable modern authentication on Outlook 2013, click on the following guide:

Enable Modern Authentication for Office 2013 on Windows devices

Azvise

Apple Mail not working after disabling Legacy Authentication – Exchange Online

If just enabled a Conditional Access Policy blocking legacy authentication to Exchange Online, enabled Security Defaults, or Microsoft disabled it for your tenant, you might see some Apple Mail clients not connecting anymore.

This issue is happening because the profile might be still configured to use Exchange ActiveSync to connect to Exchange Online, and EAS (along with other legacy protocols) will be retired in October 2022.

Apple supports an automatic switch to modern authentication for its profiles, but only if it was freshly configured after iOS 12.

Unfortunately, it seems that backing up and restoring profiles does not trigger the switch to modern auth, so if you moved to a new iPhone and didn’t reconfigure the profile manually, you’ll need to remove and recreate it.

UPDATE 16.06.2022:

Apple will add support for the automatic migration to modern auth in iOS 15.6. Once you update your Apple device, the Mail app will use the saved credentials to establish a new authentication flow. From that moment onward, you’ll authenticate to Azure AD (Microsoft online Identity Provider) and get a new OAuth access token. The “old” stored credentials will then be removed. The process is fully transparent to users.

Read the full announcement here: Microsoft and Apple Working Together to Improve Exchange Online Security

Azvise

Scan now is greyed-out in Azure Information Protection – AIP

If you just installed the Azure Information Protection on-premises scanner and you are trying to start your first Content Scan Job, you might get that the button “Scan now” is greyed out.

Before attempting to troubleshoot, check that you selected the job below. If you did, try restarting the service “Azure Information Protection Scanner” on the SQL server and refreshing the Azure Content scan job page.

If you still cannot start the scan, try executing the following command on the SQL server, and insert the credentials of the service account:

$scanner_account_creds= Get-Credential
Start-AIPScannerDiagnostics -onbehalf $scanner_account_creds -Verbose -VerboseErrorCount 50

For further information refer to the following articles:

Troubleshooting your unified labeling on-premises scanner deployment

Start-AIPScannerDiagnostics

Azvise

Automatically apply Sensitivity Labels to files and libraries – Microsoft Pureview

There are a couple of ways to enable an automatic classification of files in SharePoint. The first one, more complete from a customization point of view, is to use a File Policy in Defender for Cloud Apps. The second one (the newer and less recommended one, to be fully released Q3/Q4 2022) is to use a Default Sensitivity Label in SharePoint Online.

If you are looking at how to enable file monitoring and file policies, follow this guide:

Enable file monitoring for Office 365 in Defender for Cloud Apps – DCA

File Policy in Defender for Cloud Apps

To create a policy that automatically matches and labels files in the root folder and the subfolders, follow the steps below:

  • Open the MDCA portal.
  • Create a new file policy.
  • Create a broad filter. I’ve set it as “App equals SharePoint Online” for this example.
  • Under “Apply to”, specify the root folder where the policy should start to apply.
  • Apply the governance action “Apply sensitivity label”, and select your label. Check the box below if you wish MDCA to override all user-defined labels. This will override older labels set on docs in the site and new ones defined at document creation.
  • Save the policy

Suppose you would like a policy to automatically apply labels to all the files and subfolders recursively from a root folder onward in SharePoint or OneDrive. In that case, you might think you can use the “Files matching all of the following” filter. Unfortunately, this won’t work, as it will not match recursively on the files contained in the subfolders.

Default Sensitivity labels in Sharepoint Online

Once you enable SharePoint to process labels, you can configure a default label for document libraries. This will ensure that any new or newly modified files get the specified label.

The feature will not apply to documents not opened since setting the default label or if the file has a higher priority label applied. Therefore, I would recommend, for the moment, using PowerShell or MDCA (as shown above) before setting the default label.

The feature will also not work if you have “User access to content expires” set anything other than Never or if you use Double Key Encryption.

Also, please note that PDFs are not currently getting labelled using this method, but I expect this to change before Q4 2022. Please refer to the docs for further updates, depending on when you are reading this:

Configure a default sensitivity label for a SharePoint document library | MS Docs

Here you can find a cool summarization table, taken from the official Docs:

Existing labelOverride with library default label
Manually applied, any priorityNo
Automatically applied, lower priorityYes
Automatically applied, higher priorityNo
Default label from policy, lower priorityYes
Default label from policy, higher priorityNo

If you wish to enable this feature:

  • Go to Information Protection | Pureview
  • Click on Labels, then “Turn on now” under “Your organization has not turned on the ability to process content in Office online files that have encrypted sensitivity labels applied and are stored in OneDrive and SharePoint. You can turn on here, but note that additional configuration is required for Multi-Geo environments.”
  • Open your SP document library, then on the top right corner click settings (the “gear” icon), then “Library settings“.
  • Select your default label, then click “Save“.

Allow some time between enabling the feature and looking for the library setting, as you probably won’t find the feature right away; you’ll have to wait up to 24 hours.

Azvise

Enable Unified Audit Logs – Office 365

Unified Audit Log is one of the essential features for tracking down every action done across the tenant.

The logs are kept for 90 days by default, but you can extend them using special addons.

If you want to check whether the logging is enabled on your tenant, connect to Exchange Online with PowerShell. Once connected, you can check the status.

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName yourupn@domain.com
Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled

If you get “True” as a result, the logging is enabled. If you get “False”, follow the steps below to enable it:

PowerShell way:

Using the PS tab, you opened before to check the Audit Log status, send the following command: 

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

You might be asked to run “Enable-OrganizationCustomization” before relaunching the command. You must wait 30 to 60 minutes after sending “Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true” to see it enabled in the portal.

Portal way:

Go to https://compliance.microsoft.com/, then click on “Audit” on the left pane. When you get to the page, click on “Start recording user and admin activity“, then check the status after 30-60 minutes. If it fails, try with PowerShell.

Azvise

Add / remove the requirement to apply a sensitivity label to documents and emails – Microsoft Information Protection

When you select “Require users to apply a label to their email and documents” inside a label policy in Microsoft Information Protection, users will be required to classify the documents they create/modify.

To add this requirement, access the compliance portal and select a label policy you created.

https://compliance.microsoft.com/informationprotection?viewid=sensitivitylabelpolicies

Then click “Edit policy” and go straight into “Settings”. Select “Require users to apply a label to their emails and documents”, then save the label policy.

Just follow the steps listed before and unselect “Require users to apply a label to their emails and documents” from all the label policies to remove the requirement.

Be aware that the policy may take a while to replicate.

Azvise

Project Freta

Project Freta is a newly announced offer from Microsoft, which aims at discovering any malware or rootkit running on Linux systems, by conducting memory forensic analysis automatically. The analysis is conducted at no cost and is very easy to extrapolate the data, democratizing the forensic process.

Project Freta was designed and built with survivor bias at its core. It is a security project designed from first principles to drive the cost of sensor evasion as high as possible and in many cases render evasion technically infeasible.

Mike Walker
https://www.microsoft.com/en-us/research/blog/toward-trusted-sensing-for-the-cloud-introducing-project-freta/

At the moment there are more than 4,000 supported kernel versions.

The process is very useful because the malware cannot “hide” himself, since the image processing system is non-intrusive to the VM, giving analysts a complete view on what’s running and potentially bad for the server.

The supported memory images formats are the following:

  • vmrs
  • lime
  • core
  • raw

The memory can be captured using various tools, such as:

  • vmss2core (VMware)
  • Hyper-V Manager
  • AVML 

The tool works by analyzing an image uploaded on the cloud. Once the image has been acquired, you can let the program scan it.

This image has an empty alt attribute; its file name is image-1.png

Please refer to this guide to extract the images: https://docs.microsoft.com/en-us/security/research/project-freta/how-to-capture-an-image

Read the full announcement: https://www.microsoft.com/en-us/research/blog/toward-trusted-sensing-for-the-cloud-introducing-project-freta/

Documentation: https://docs.microsoft.com/it-it/security/research/project-freta/