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

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

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). This process enables you to make the device visible to Azure AD and lets you manage it with Intune.

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

If this block has been triggered, you are probably synchronizing AD-joined devices to Azure AD. If the user is accessing the portal from an on-premise joined device, check if you are synchronizing said device and consider adding it to the right OU / add the right attribute to let it sync.

Once you are done, and the device is hybrid joined (or you’ve excluded the user from the CAP), the user will be able to access the resources.

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:

To drill down on this type of Conditional Access Policy, 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.

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.

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 

                                                   

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.

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.

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.

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

It’s been long since Microsoft released number matching and additional context for the Microsoft Authenticator. These features allow you to quickly improve your passwordless or MFA approach, 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.

To enable these features follow this link, which will guide you into Azure AD, Security, then Authentication methods:

Authentication methods | AAD

From here, click “Microsoft Authenticator“.

Click “Yes” under “ENABLE“, then on “Configure“.

Be sure to activate “Require number matching for push notifications (Preview)“, “Show application name in push and passwordless notifications (Preview)” and “Show application name in push and passwordless notifications (Preview)“, then save. You can also scope the features to a selected group of users if you want to test them out.

Check out this article if you are looking for a guide to send out to users before rolling out the features:

Additional Context and Number Matching User Guide – MFA

Automatically clean up inactive Guest users – Azure AD

Using Azure AD Access Reviews (available with AAD P2), you can automatically remove 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.

WARNING: 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).

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.

Import-Module Microsoft.Graph.Groups

$params = @{
	DisplayName = "Guest_review_dynamicgroup"
	MailEnabled = $false
	MailNickname = "fb7kk308-6"
	SecurityEnabled = $true
	Description = "Group used for the automatic guest removal process"
	GroupTypes = @(
		"DynamicMembership"
	)
	MembershipRule = "(user.userType -eq "Guest") and (user.accountEnabled -eq true)"
	MembershipRuleProcessingState = "On"
}

New-MgGroup -BodyParameter $params

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:

Identity Governance | Access Reviews

  • Click on “New access review“.
  • 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.

Exchange API missing for Veeam modern auth in Azure AD

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

IdFix – Pre AdConnect assessment for your on-prem AD

IdFix is a tool to discover and remediate identity problems pre synchronization to Azure Active Directory.

To use IdFix you will need:

  • A domain joined computer / server
  • A user account with at least read access to the AD objects

The process is really straightforward.

Get IdFix from here:

Install and open IdFix, then click on “Query”.

After the process has been completed you will be shown all the problems you might have with your environment, if any.

Screen shot of the tool running
Image from https://microsoft.github.io/idfix/operation/

If no errors are shown, or you are confident you can work around them, you can begin the synchronization.

Links:

Set up synchronization:

https://docs.microsoft.com/en-us/microsoft-365/enterprise/set-up-directory-synchronization?view=o365-worldwide

Microsoft guide on how to use IdFix:

https://microsoft.github.io/idfix/operation/