Guide: Auditing who can create app registrations and service principals.

A common yet often overlooked attack vector in cloud-native environments is the uncontrolled proliferation of application registrations and service principals. From a FinOps and security perspective, each of these identities represents a potential for privilege escalation, credential exposure, and—critically for cost management—unmonitored resource consumption. An application with excessive permissions can, either through compromise or misconfiguration, provision expensive resources without oversight. Therefore, the first line of defense in a cost-secure environment is controlling *who* can create these powerful identities.

In Microsoft Entra ID (formerly Azure AD), this control is not governed by a single, intuitive switch in the portal. Instead, it is managed through a combination of directory roles and user settings, which necessitates a thorough audit. The primary roles to investigate are:

* **Application Administrator**
* **Cloud Application Administrator**
* **Global Administrator** (which inherently includes all permissions)

However, the more nuanced and often missed setting is the **"Users can register applications"** toggle and its more granular successor, **"Restrict user access to Azure AD administration portal."** Even users with no administrative role can be granted the ability to register applications if the legacy setting is enabled.

To conduct a comprehensive audit, you must move beyond the Azure portal and utilize Microsoft Graph, either through PowerShell or the Graph Explorer. The following PowerShell script using the `Microsoft.Graph` module will enumerate users holding the key roles and check the relevant directory settings.

```powershell
# Connect to Microsoft Graph with necessary permissions
Connect-MgGraph -Scopes "Directory.Read.All", "RoleManagement.Read.All"

# Define the high-risk role IDs for application management
$targetRoleDisplayNames = @("Application Administrator", "Cloud Application Administrator", "Global Administrator")

# Get all directory roles and filter for our targets
$allRoles = Get-MgDirectoryRole
$targetRoles = $allRoles | Where-Object { $_.DisplayName -in $targetRoleDisplayNames }

# For each target role, get its members
foreach ($role in $targetRoles) {
Write-Host "`n--- Members of role: $($role.DisplayName) ---" -ForegroundColor Yellow
$members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
foreach ($member in $members) {
$user = Get-MgUser -UserId $member.Id -Select DisplayName, UserPrincipalName
Write-Host " $($user.DisplayName) ($($user.UserPrincipalName))"
}
}

# Check the critical tenant-wide setting
Write-Host "`n--- Checking Tenant-Wide Settings ---" -ForegroundColor Yellow
$settings = Get-MgDirectorySetting | Where-Object { $_.DisplayName -eq "Application.Configuration" }
if ($settings) {
$values = $settings.Values
$allowUserRegistrations = $values | Where-Object { $_.Name -eq "AllowUserRegistration" }
Write-Host " 'Users can register applications' legacy setting is set to: $($allowUserRegistrations.Value)"
}
```

The output of this audit provides the essential roster for review. The subsequent action is policy-based: you must decide if this list is appropriate. Best practice dictates that this capability should be restricted to a tightly controlled security group, not assigned to individuals. Furthermore, you should disable the legacy "Users can register applications" setting and ensure administrative portal access is restricted. This creates a controlled, auditable pipeline for identity creation, which is as vital for preventing cost sprawl as it is for security. Implement this control, and you have effectively gated one of the most potent pathways to ungoverned cloud expenditure.

- cost_cutter_ray