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.
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:
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:
Requiring users to register for MFA using the Authenticator app. Users will have 14 days to comply before being required to do so.
Requesting MFA for both users and administrators, especially when a user accesses privileged portals.
Block legacy authenticationprotocols which can’t support MFA.
How to enable Security Defaults
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
Click on Manage Security Defaults at the bottom of the page
Set the Security Defaults to Enabled
Save
How to disable Security Defaults
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
Click on Manage Security Defaults at the bottom of the page
Set the Security Defaults to Disabled
Provide a reason for disabling Security Defaults
Save
Notes
If you wish to learn more about Security Defaults, refer to the following documentation page:
In Azure Kubernetes Service (AKS) on Azure Stack HCI, you can increase the resources available to your node pool by changing the size of virtual machines in a node pool or expanding the node count. The node count can also be increased with autoscaling methods.
The worker nodes can be scaled using the command Set-AksHciNodePool, while the Set-AksHciCluster scales the control plane.
I’ll be going over scaling both using PowerShell in the following guide. You’ll need to open a PowerShell session on one of the Azure Stack HCI nodes to follow along. Replace the parameter values as needed.
Notes
As of January 2023, the scaling of the management cluster (the one created by AKS HCI automatically) is currently not supported.
Now that we have scaled up the control plane, we can scale the control plane node count. The default is 1. If you scale up the control plane, it will become highly available and will not accept any scale down back to 1 node⚠️
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:
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.
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.
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:
Here is a small table that recaps what methods are available, based on device type.
Device
AD FS or Azure AD native certificate-based authentication
FIDO2 security keys
Windows Hello for Business
Microsoft Authenticator with compliant device CAP
Windows device
iOS mobile device
Not applicable
Not applicable
Android mobile device
Not applicable
Not applicable
MacOS device
Edge/Chrome
Not applicable
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.
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:
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
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:
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.
Targeted Intune deployment
To target specific device groups to enable the credential provider, use the following custom settings via Endpoint Manager:
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.
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.
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:
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:
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:
Requiring every user to register for MFA. Once enabled, users will have 14 days to register before being required to do so.
Requesting MFA for both standard users and administrators, especially when a user accesses privileged portals.
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:
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 JSONtemplates. 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:
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:
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
}
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:
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.
The following script will get all the members of an Azure AD group and add them to another group. You’ll just need to know the name of the two groups to make it work.
In the code shown below, the source group will be called Group1Name and the destination one Group2Name.
# Replace Group1Name with the name of your source group and Group2Name with the name of the destination one. Everything else will be done automatically
$Group1 = "Group1Name"
$Group2 = "Group2Name"
$group1ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group1'" | Select objectid -ExpandProperty ObjectID
$group2ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group2'" | Select objectid -ExpandProperty ObjectID
$membersGroup1 = Get-AzureADGroupMember -ObjectId $group1ObjectID -All $true
foreach($member in $membersGroup1)
{
$currentuser = Get-AzureADUser -ObjectId $member.ObjectId | select objectid
Add-AzureADGroupMember -ObjectId $group2ObjectID -RefObjectId $currentuser.objectid
}
Get-AzureADGroupMember -ObjectId $group2ObjectID -All $true
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 remove a user profile in Azure Virtual Desktop, you must first be sure that the user is logged off. If you are unsure on how to do it, follow the guide below.
After you’ve checked this, you got two options based on the type of profile architecture you chose to implement.
If the profiles are stored locally, you can proceed to remove them as you’d do in standard W10 machine.
If you are using FSLogix, which is the recommended way to handle them, you can proceed to remove the user folder from the Azure File Share.
If you are unsure about which type of user profile solution you use, you can log in to a standard user account (preferably the one you wish to remove) and follow the guide below.
If you fall under the first option, log into the AVD instance/instances with an admin user account, open “Run“, then type netplwiz.exe and click enter. This will open the Advanced User Accounts Control Panel. From there, you’ll get a list of all the users. Next, click on the user profile you’d like to delete and click “Remove”. You’ll have to repeat this procedure for all the AVD hosts in your environment.
If you are running FSLogix, log into the Azure File Share hosting your profiles, then locate the user folder you wish to delete. Usually, the format is either %username%%sid% or “%sid%%username%, depending on whether you have added the FlipFlopProfileDirectoryName registry in the FSLogix configuration (FlipFlopDirectoryName | AVD). Once you have found it, open it, and delete the VHD/ VHDX stored inside, as per the screenshot below. After the VHD deletion has been completed, delete the user profile folder.
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
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:
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.
Since the best practice in Azure AD is to configure Break-glass administrators to be excluded from a lot of conditional access policies, you probably want to receive an alert if this user logs into the tenant. This admin should not be used for day to day operations, and the authentication methods should be really strong.
How to guide
For this procedure, you’ll need Azure AD Premium P1 or P2.
To receive an alert on a user login you’ll need to export sign-in logs to a Log Analytics workspace, then set up the triggers. We’ll go over the steps in this guide:
Click on the user you want to get alerts for, and copy the User Principal Name.
Open your Log Analytics workspace.
Go to “Alerts”, then “+ Create”, “Alert rule”.
Under “Condition“, select “Add”.
Select “Custom log search”.
In the text box, insert the following code, personalizing it for your UPN:
SigninLogs
| project UserPrincipalName
| where UserPrincipalName == "demo@azdemoenv.onmicrosoft.com"
Under “Alert logic”, select “Operator” Greater than 0, with “Frequency of evaluation” 5 minutes.
If you want to get alerts as soon as possible, set the frequency of evaluation to 1 minute.
Click on “Next”.
Create an Action Group, or select your existing one.
To create one, click on “Add action groups”, select the subscription, resource group, and give the Action Group a name and display name.
Select the type of notification you want to get. In my example, I’ve selected an email and SMS.
Click “Ok”, and give the notification a name.
Click on “Review + create”, you will have the chance to test it out before pushing it in production.
Once you are happy with your rule, click “Create”.
If your tenant is not big, this alert will only cost a couple of bucks. However the bigger cost may come from storing all the sign-in logs. If the logs are under 5 GB, there will not be any charge, if it goes up from there you’ll have to pay for storage fees:
It’s been a long time since Microsoft released number matching and additional context for the Microsoft Authenticator. These features allow you to quickly improve your MFA posture, adding a new layer of security and preventing accidental approvals. This is also useful to lower the chances of being compromised by MFA fatigue attacks. The feature consists in a map shown on your MFA prompt on your phone that indicates where the MFA request is coming from, the name of the application requesting the MFA challenge, and a box to insert the number that will be shown on screen.
Image taken from the Microsoft Docs. Link in the notes
How to enable it
To enable these features follow this link, which will guide you into Azure AD > Security > Authentication methods:
Be sure to activate “Require number matching for push notifications“, “Show application name in push and passwordless notifications” and “Show geographic location in push and passwordless notifications“, then save.
You can scope the features to a selected group of users if you want to test them out and go for a gradual rollout. This is done by selecting “Select group” and adding the group for which you want to enable the feature.
Additional notes
Check out this article if you are looking for a communication to send out to users before rolling out the features:
Since Azure introduced the option to download the OS disk of a VM directly, you don’t need anymore to traffic around to download the unmanaged disk (or go with the snapshot route). Here are some easy steps to directly download the disk of your Windows / Linux VM. Please note that a Sysprep is advised if you need to use the disk as a template to create new VMs.
Go to the VM, and stop it.
Click on “Disks” then on he OS Disk.
Click on “Disk Export“, then in the field, enter a higher number (es. 30600) so that you have plenty of time to download the disk. Once done, click “Generate URL“.
When you transfer Azure resources between subscriptions, you might get the following error: “ResourceNotTopLevel“.
This is caused by the fact that you only have to select top-level resources for the move, and the dependencies will be moved automatically.
For example, say you selected both a Network Watcher Extension and the relative VM you want to move. You will just need to move the VM object, and the extension will come with the server.
Example of an error code:
{
"code": "ResourceNotTopLevel",
"message": "Identifier '/subscriptions/0000000000000000000/resourceGroups/MoveResource/providers/Microsoft.Compute/virtualMachines/VMtobeMoved/extensions/AzureNetworkWatcherExtension' is not a top level resource. Please include only the top-level resource for this child resource in the move request. A child resource would be moved along with its associated top-level resource.\""
}
From the error code, you’ll get that you just have to move the following resource, being the top-level one:
It’s good to remember that if dependent resources are distributed across different resource groups, you’ll first have to move them into one resource group and then attempt the migration.
Using Azure AD Access Reviews (available with Azure AD Premium P2), you can automatically remove guest users from your tenant who haven’t had access in a specified number of days. In this guide, we will implement the access review step by step.
This is a great way to clean up your tenant automatically and can be scheduled.
NOTE: The procedure used to clean up only users who didn’t have access in the last 30 days. This has now been expanded to support a variable number of days (ex. 60, 90, etc).
Step by step guide
As a prerequisite, you’ll need to create a dynamic group in AAD, which will contain all guest users who can log in to the tenant:
To create the group, go to AAD Groups, then click on “New Group”.
Select Group Type as “Security“, give the group a name, and select “Membership type” as “Dynamic User“.
Under “Dynamic user members”, click on “Add dynamic query“.
The query you will want to create is:
(user.userType -eq "Guest") and (user.accountEnabled -eq true)
You can create this group also using Powershell, and pasting this command after installing the Graph module.
The accountEnabled attribute lets you filter for users who can log in. Since the access review will deactivate the account for 30 days before deleting it permanently, this way we’ll filter only for the guest users active in the tenant and not the ones ready to be automatically deleted.
Once done, click on “Create”.
To create the access review, open this link, then follow the steps listed below:
Select “Teams + Groups” under “Select what to review”, “Select Teams + groups” under “Select review scope”, under “Group” enter your group, then click on “Guest users only” under “Scope”.
You can then filter only for the guest that did not had access in a specified number of days. This is accomplished using this part of the wizard:
Click on Next, and under “Select reviewers”, click on “Selected user(s) or group(s)“. The person or people that will manually review the users to delete should be selected just below. If not needed, insert an admin and go ahead. I always give at least 3 to 5 days for the reviewers to check if somebody should not be blocked or deleted. If some guest user should always be excluded from the review, you can add an exclusion in the AAD Group membership rules.
In the last paragraph, you’ll want to select auto-apply results to make the automation work. Under “If reviewers don’t respond”, choose “Take recommendations“. The recommendations will be based on whether the user has logged in recently or not. There are no other recommendations that I am aware of at this moment. Under “Action to apply on denied guest users”, select “Block user from signing-in for 30 days, then remove user from the tenant“. Be sure that “No sign-in within 30 days” is selected as reviewer decision helper, as per the image below.
If you want this to be fully automated, deselect “Justification required”.
Once done, click on “Review + create”, give the review a name and click on “Create”.
Now you will automatically have the guest users who haven’t logged in in the specified number of days blocked. After 30 days, the blocked user will be removed from the tenant.
Additional resources
Jef Kazimer wrote a really cool guide on how to remove unredeemed B2B guest from your Azure Active Directory:
If you are encountering issues with Azure File Sync, or you just want to force the process so that you can free some space now, follow the commands shown below:
#Import the commands
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
#Force the synchronization of the folder you have specified in the sync group
Invoke-StorageSyncCloudTiering -Path <sync_group_path>
If you want to get some logs out of the operation for troubleshooting, send these commands in a separate PowerShell window before launching the script above:
cd C:\
New-Item -ItemType directory -Path C:\AZfslogs
cd "C:\Program Files\Azure\StorageSyncAgent"
Import-Module .\AFSDiag.ps1
Debug-AFS -OutputDirectory C:\AZfslogs -KernelModeTraceLevel verbose -UserModeTraceLevel verbose
You can terminate the command once the sync is concluded and get the logs in the C:\AZfslogs folder.
If you are looking for the Exchange API to configure modern authentication for Veeam, you’ll find that it is no longer present under “Request API Permissions” -> “Microsoft API”.
Instead, what you want to do is go into “APIs my organization uses” under the “Request API Permissions”, then search for “Office 365 Exchange Online“.
It’s basically the same thing, only a bit harder to find, as the search doesn’t show up results if you look for “Exchange”.
To configure a VM for Azure Site Recovery we’ll need to configure the Microsoft Azure Linux Agent and enable the console. The VM will automatically get the DHCP network settings that it will need to get an IP from Azure.
If you get this error there is probably something wrong with the user profile. It’s usually either that the VHD / VHDx is locked, or the cached profile is broken.
In the first case sometimes the Windows Session closes down and doesn’t alert FSLogix to unlock the disk. Before you reboot the VM, consider adding the following registry entry:
At times a Windows Session may suffer an inelegant termination, in these cases FSLogix is not provided an appropriate event to trigger the dismount of the VHD(x) file for Profile Container and Office Container. By setting CleanupInvalidSessions to 1, additional FSLogix logic is triggered to make this scenario less likely. Setting CleanupInvalidSessions will cause the functionality to be utilized for both Profile Container and Office Container. KNOWN ISSUE: at this time CleanupInvalidSessions should not be used in conjunction with Cloud Cache when concurrent sessions (e.g utilizing ProfileType/VHDAccessMode) are in use.
If some kernel modules fail to load (such as in the example below) while installing the Mobility Service agent, please check:
If the kernel is supported in your Configuration Server version
If secure boot is enabled
#EXAMPLE using SUSE 15 SP2
exampleserver0:/tmp/ASR # sudo ./install -d /usr/local/ASR/ -r MS -v VmWare -q
All product pre-requisties are met.
Generating the certificate.
[...]
Filter driver kernel module is not loaded. Attempting to load it, please wait...
insmod /lib/modules/[kernelversion]-default/kernel/drivers/char/involflt.ko
Filter driver could not be loaded successfully.
Check the log file /var/log/ua_install.log for detailed diagnostic messages or installation success/failures...
Vx agent installation exit code : 208.
Check the log file /var/log/ua_install.log for detailed diagnostic messages or installation success/failures...
Installer exiting with code: 208
Check the following page to see if the kernel version is supported:
If you see the event “Data change rate beyond supported limits” in the ASR replicated items logs, you probably need to change the disk type of your managed disks for that Virtual Machine.
I would advise waiting a bit to check if the error disappears or remains consistent.
To change the disk size go to:
Disks
Select the disk specified in the error message above
Click on Configuration
Under Account type switch from “Standard HDD” to “Premium SSD” (or “Standard SSD”)
If they are supported, you can install manually the agent on the VM. If it doesn’t work, try checking if the VM in VMware is configured as “Other (64-bit)” in the guest OS version. If it is, you should change the version to the specific Linux distribution you got installed. Mind that the VM must be shut off to change the Guest OS version.
To install manually the agent follow these steps:
Go under %ProgramData%\ASR\home\svsystems\pushinstallsvc\repository in your ASR server and copy the “Microsoft-ASR_UA*_GA*.tar.gz” file specific to your distribution.
Copy the file to the VM. I would recommend creating a specific folder for the file under /tmp
Copy the Conf server passphrase to the server
Unpack the file: tar -xvf Micorosft-ASR_UA_yourfile.tar.gz
Run the following command as root: ./install -d /usr/local/ASR -r MS -v VmWare -q
Register the mobility service to the Conf server: /usr/local/ASR/Vx/bin/UnifiedAgentConfigurator.sh -i ConfserverIP -P /var/passphrase.txt
Azvise 