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

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

Some quick notes:

  • 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.

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.

Get all users of an Azure AD Group and add them to another one – Powershell

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.

The source group will be called Group1 and the destination Group2.

# 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

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

Delete a user profile in Azure Virtual Desktop – AVD

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.

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

Online Mailbox cannot be created because an on-premise one already exists – Exchange Online

This issue is mainly present if you are trying to migrate from Exchange on-prem to Exchange Online and you’re not going with the hybrid route. The “double mailbox” way consists in having an online mailbox and a local one, and manually (or automatically using tools) migrating the content online.

The issue is that, if you are synchronizing your on-prem AD with Azure AD, you are most probably including your msExchMailboxGUID into the replicated fields. This attribute will tell Exchange Online not to create an online mailbox, as an on-prem one already exists.

Once you will have cleared this field from the online user, Exchange Online will be able to create another mailbox, populating the msExchMailboxGuid of the online user, leaving you with the possibility of exporting and importing data into your online mailbox.

Please note that this will also automatically clear the following attributes from the online user:

  • alias
  •  legacyExchangeDN
  •  msExchArchiveGuid
  •  msExchArchiveName
  •  msExchBlockedSendersHash
  •  msExchElcMailboxFlags
  •  msExchRecipientDisplayType
  •  msExchRecipientTypeDetails
  •  msExchSafeRecipientsHash
  •  msExchSafeSendersHash
  •  userCertificate

To proceed with the creation of the online mailbox, follow these steps:

  • Open your AD Connect server.
  • Stop the Sync with Powershell (launch it as admin and keep it open after this command): Set-ADSyncScheduler -SyncCycleEnabled $false
  • Open the Synchronization Rules Editor as an admin.
  • Select the In from AD – User Exchange rule, click Edit, then click on yes.
  • Under Precedence write 250 (or the first free one), then click Next until you arrive in the Transformations page. Here look for msExchMailboxGuid, then change the row’s settings to make them match with the image below:
  • Once you are done, click Save, then open the original rule. Note down the Precedence (usually it’s 108), then delete the rule. Go into your newly cloned rule and change the Precedence to the one you noted down.
  • Before you enable the scheduler and perform a full sync, you should test out the changes. This is the documentation link to test everything out without committing changes to Azure AD: Verify changes to AD Connect rules | MS Docs
  • Reenable the scheduler: Set-ADSyncScheduler -SyncCycleEnabled $true
  • Perform a full synchronization: Start-ADSyncSyncCycle -PolicyType Initial

You should now be able to create a second mailbox for your synchronized user by assigning a valid license.

Additional Context and Number Matching User Guide – MFA

I wanted to publish the following article, which is how I would notify my users of the upcoming activation of Additional Context and Number Matching in their MFA requests.

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

Feel free to use the message below as your own. The images are taken from a wonderful article by Tony Redmond. Please replace them with your own.

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

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 

                                                   

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.

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

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

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.

User blocked due to risk on home tenant – Azure AD

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 Unblock at-risk users – 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.

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.

Disconnect a user session in Azure Virtual Desktop (AVD) – PowerShell

Prerequisites: The Microsoft.RDInfra.RDPowerShell module, the Az PS module

First, install the RDInfra module:

Install-Module -Name Microsoft.RDInfra.RDPowerShell; Import-Module -Name Microsoft.RDInfra.RDPowerShell

Then proceed by installing the Az module and logging in:

Connect-AzAccount

Once you are logged in you can run the following script to disconnect a specific user session:

Get-RdsUserSession -TenantName "tenantname.onmicrosoft.com" -HostPoolName "HostPoolName" | where { $_.UserPrincipalName -eq "azvise\demouser" } | Invoke-RdsUserSessionLogoff -NoUserPrompt

Change AD account used in AD Connect connector

To change the user account set in Azure AD Connect follow these steps:

  • Log in to the AD Sync server
  • Run the “Synchronization Service” from the start menu
  • Go to the “Connectors” tab
  • Select the connector relative to your on-premise AD
  • Right-click it and select “Properties”
  • Click on “Connect to Active Directory Forest”
  • Here you will swap your credentials once the user is ready
  • Go into your AD DS environment and create a new user. It has to be part of the “Domain Users” group
  • Right-click the domain object (e.g. contoso.com) then “Properties”
  • Click on “Security”
  • Add the user account if not present
  • Click on the account added
  • Add the “Replicating Directory Changes” and “Replicating Directory Changes All” permissions
  • Click Apply
  • Any further permission will depend on which optional features you have enabled in your environment. To check any “special” permissions for the user refer to the following link: https://docs.microsoft.com/it-it/azure/active-directory/hybrid/reference-connect-accounts-permissions#create-the-ad-ds-connector-account
  • Swap the current user account with the new one we just created in the “Connect to Active Directory Forest” tab on the AD Connect server and click “OK”

Password Hash Synchronization won’t update any user password

If AD Sync won’t update any user password across a domain follow these steps:

  • Open Microsoft Azure Active Directory Connect
  • Click Configure
  • Click Troubleshoot
  • Click Launch
  • In PowerShell type 2 (Enter ‘2’ – Troubleshoot Password Hash Synchronization)
  • Type 1 (Enter ‘1’ – Password Hash Synchronization does NOT work at all)

Usually, the output on your local AD Connector is:

Last successful attempt to synchronize passwords from this directory partition started at: [long time ago]

If this is the case proceed as follows:

  • Open Synchronization Service Manager
  • Click on Connectors
  • Click on your local connector (ex. domain.com)
  • Right-click, then open properties
  • Under Connect to Active Directory Forest insert the password for the user and click ok
  • Run an initial Sync in PowerShell: Start-ADSyncSyncCycle -PolicyType Initial