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

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

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:

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

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.

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

ResourceNotTopLevel error when trying to move resources – Azure

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:

/subscriptions/0000000000000000000/resourceGroups/MoveResource/providers/Microsoft.Compute/virtualMachines/VMtobeMoved

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.

Repair / troubleshoot a Linux VM – Azure

If you encounter a boot or disk error with a VM, you need to get the OS disk into another VM to troubleshoot the issue.

The command we will run into Azure Cloud Shell is az vm repair create. To create a troubleshooting VM, follow these steps:

  • Open Azure Cloud Shell in bash or install Azure CLI in your bash environment.
  • Run the following command: az vm repair create -g “resourcegroupname” -n “VMname” –verbose
  • Insert admin credentials for the newly created VM into the bash shell
  • Connect to the newly created server and start analyzing the problem

Move resources request is blocked by an Azure Backup job.

Error message:

The move resources request contains resources like “*OsDisk*” that are being backed up as part of a Azure Backup job. Browse the link https://aka.ms/vmbackupmove for information

If you encounter this error check if the VM’s backup is stopped. If it’s stopped you need to remove the istant snapshot that has been created by the system:

  1. Find the location of your virtual machine.
  2. Find a resource group with the following naming pattern: AzureBackupRG_<location of your VM>_1. For example, AzureBackupRG_westus2_1
  3. In the Azure portal, check Show hidden types.
  4. Find the resource with type Microsoft.Compute/restorePointCollections that has the naming pattern AzureBackup_<name of your VM that you're trying to move>_###########.
  5. Delete this resource. This operation deletes only the instant recovery points, not the backed-up data in the vault.
  6. After the delete operation is complete, you can move your virtual machine.

List source: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/move-limitations/virtual-machines-move-limitations#portal

VM has reported a failure when processing extension ‘joindomain’ – AVD

If you encounter this error while creating a new VM from the host pool wizard, try following these suggestions to solve the issue, or at least drill down on the problem:

  • Check whether you can resolve your domain from your VNET
  • Check what DNS Servers are configured on your VNET, correct accordingly (follow this guide: Change VNet DNS Servers)
  • Check if you have permissions to join the domain using the credentials you provided
  • Check if the specified credentials are correct
  • Check if the domain to join (and the OU), specified in the wizard, is correct (parameters in the JSON: domainToJoinouPathexistingDomainUPNexistingDomainPassword).
  • Try to join a VM to the domain from the same network and subnet

If all the above are met, you should be able to join the VM successfully to the domain. If not, at least you should have more context to further troubleshoot the issue.