Within Azure there are many limits, some of them global and some of them assigned to individual accounts. One of the more poorly documented ones is a limit of 250 App Registrations/Service Principals that may be owned by the same user. In most organisations, this would be a perfectly reasonable limit, but if you’re hitting up against this error, a few things can be done.

Firstly though, this error will present whilst running commands such as –

az ad sp create-for-rbac

Which will present an error message similar to –

ERROR: The directory object quota limit for the Principal has been exceeded. Please ask your administrator to increase the quota limit or delete objects to reduce the used quota.

Solutions

Fixing this issue requires reducing the number of Service Principals and Applications that the user owns by reassigning ownership, or by creating a new custom role which allows us to lift the limit for the given user.

The first thing to check would be whether there are existing deleted App Registrations, which will eat into that users limit, the PowerShell commands below, which use the Graph API, will retrieve and then delete all currently existing deleted App Registrations (alternatively these can be found at Entra ID App Registrations followed by selecting “Deleted Applications”)

Connect-MgGraph
# Retrieve all deleted apps
$deletedApps = Get-MgDirectoryDeletedApplication

# For each app, remove them completely
foreach($app in $deletedApps) {
    Remove-MgDirectoryDeletedItem -DirectoryObjectId $app.Id
}

Disconnect-MgGraph

Once you’ve removed all the deleted applications the user can re-attempt the operation, however, you will still need to review all of the users active applications, which can be done quite easily by using the script below, which will export a list of all Apps owned by the user, you may wish to modify this to add various columns to the export –

# User ID to query - Can get this from Entra ID
$userId = "#############"
$reportLocation = "c:\temp\export.csv"

# Get all Applications
$apps = Get-MgApplication -All

# Filter applications owned by the authenticated user
$ownedApps = @()
foreach ($app in $apps) {
    $owners = Get-MgApplicationOwner -ApplicationId $app.Id
    if ($owners.Id -contains $userId) {
        $ownedApps += $app
    }
}

Write-Host "Located $($ownedApps.length) Applications owned by the user"
$ownedApps

# Export to CSV
$ownedApps | Export-CSV -Path $reportLocation -NoClobber

You will also need to review all of the users owned Service Principals, as the quota limit of 250 per user is made up of Applications + Service Principals. This can also be simply reported on using the script below, which is a modified version of the script above –

# User ID to query
$userId = "####"
$reportLocation = "c:\temp\export.csv"

# Retrieve all service principals
$servicePrincipals = Get-MgServicePrincipal -All

# Filter service principals owned by the authenticated user
$ownedServicePrincipals = @()

foreach ($sp in $servicePrincipals) {
    $owners = Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id
    if ($owners.Id -contains $userId) {
        $ownedServicePrincipals += $sp
    }
}

# Output the service principals owned by the authenticated user
Write-Host "Located $($ownedServicePrincipals.length) Service Principals owned by the user"
$ownedServicePrincipals

# Export to CSV
$ownedServicePrincipals | Export-CSV -Path $reportLocation -NoClobber

Once this process is complete and you’ve reassigned or removed relevant Applications and Service Principals the user should then be able to continue creating records.

Alternative Solution

A potential alternative solution is to create a new Custom Role which bypasses the 250 limit, this only impacts the limit used for creating Applications, rather than Service Principals, and it does so not by removing the limit but by simply creating Applications without the user as the Owner.

Full details on how to configure this new role may be found here – https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/quickstart-app-registration-limits

Effectively you create a new custom role with the two permissions shown below –
There are two permissions available for granting the ability to create application registrations, each with different behavior.

• microsoft.directory/applications/create: Assigning this permission results in the creator not being added as the first owner of the created app registration, and the created app registration won’t count against the creator’s 250 created objects quota. Use this permission carefully, because there’s nothing preventing the assignee from creating app registrations until the directory-level quota is hit. If both permissions are assigned, this permission takes precedence.
• microsoft.directory/applications/createAsOwner: Assigning this permission results in the creator being added as the first owner of the created app registration, and the created app registration counts against the creator’s 250 created objects quota.