Table of Contents
The Mystery of the Invalid accountEnabled Property
While investigating some now-forgotten aspect of the Microsoft Graph PowerShell SDK, I started playing with different account disablement scenarios. During the testing, I discovered that a signed-in administrator cannot disable their own account with a very odd error.
Stopping an administrator disabling their account sounds entirely sensible because no rational person wants to disable the account they’re actively using. What surprised me was finding no Microsoft documentation explaining the behavior. I found nothing, perhaps because Microsoft considered the issue so ridiculous that it didn’t deserve to be mentioned.
In any case, someone might run into the same situation in the future, so here’s what I discovered.
Can a Global Administrator Disable Their Own Account?
My starting point was being signed in to a Graph interactive session with a Global Administrator account. It’s not best practice to use Global Administrator accounts for day-to-day work, but that’s where I happened to be when testing how quickly Entra continuous access evaluation worked when a critical event like account disablement occurs. We go into this kind of stuff in some depth before writing things up for the Microsoft 365 for IT Pros eBook.
Everything went swimmingly until I ran this code:
$User = Get-MgUser -Userid (Get-MgContext).Account Update-MgUser -UserId $User.Id -AccountEnabled:$false Update-MgUser_UpdateExpanded: Property accountEnabled is invalid.
I had recently upgraded the PC to use V2.39 of the Microsoft Graph PowerShell SDK and the first thought that went through my mind was that some error in cmdlet generation for the SDK Users module had omitted the AccountEnabled property.
Revoking account access is a well-known art. The Graph even has a dedicated permission to allow apps to disable accounts that was available in the session, and I had disabled other accounts, so that theory quickly went out the window
I checked with the Entra admin center and discovered that the same error occurred if I attempted to disable the signed in account and that account was a Global Administrator (Figure 1).
Reverting to the interactive session, running the same command with the debug switch reveals that the Graph request is properly formed with the expected request body:
Status: 400 (BadRequest)
ErrorCode: Request_BadRequest
Date: 2026-08-28T21:29:38
HTTP Method:
PATCH
Absolute Uri:
https://graph.microsoft.com/v1.0/users/eff4cd58-1bb8-4899-94de-795f656b4a18
Headers:
FeatureFlag : 00000003
Cache-Control : no-store, no-cache
User-Agent : Mozilla/5.0,(Windows NT 10.0; Microsoft Windows 10.0.26200; en-IE),PowerShell/7.6.5
SdkVersion : graph-powershell/2.39.0
client-request-id : fa8b753d-547c-4072-86f3-5b93f0f70667
Accept-Encoding : gzip,deflate
Body:
{
"accountEnabled": false
}
The response body revealed:
Body:
{
"error": {
"code": "Request_BadRequest",
"message": "Property accountEnabled is invalid.",
"details": [
{
"code": "GenericError",
"message": "Property accountEnabled is invalid.",
"target": "accountEnabled"
}
],
"innerError": {
"date": "2026-08-28T21:30:25",
"request-id": "5067ff21-b6be-4b6a-9d7b-5ceaba96f3d0",
"client-request-id": "fa8b753d-547c-4072-86f3-5b93f0f70667"
}
}
}
Despite everything appearing to be correct, the command failed. The error message is obviously misleading because the accountEnabled property exists and is correctly passed in the command. Something else was preventing the command from working.
Disabling Other Administrator Roles
The next step was to test with a different Entra administrator role. Because we’re updating user account details, the logical role to test is User administrator. I signed in to an interactive Graph session with an account holding the User administrator role and attempted to disable that account. The command failed, but this time the error was a simple 403 forbidden:
$User = Get-MgUser -userid lotte.vetler@office365itpros.com Update-MgUser -UserId $User.Id -AccountEnabled:$false Update-MgUser_UpdateExpanded: Insufficient privileges to complete the operation. Status: 403 (Forbidden) ErrorCode: Authorization_RequestDenied Date: 2026-08-28T21:24:53
The same error is displayed by the Entra admin center (Figure 2).
As before, the administrator could disable other user accounts, except administrator accounts. Assigning the permission to the account and then attempting to disable the signed-in administrator generates the same “accountEnabled is invalid” error.
The outcome suggests that Entra ID applies additional safeguards for privileged administrator accounts, including preventing administrators from disabling the account currently being used. Even when the account holds sufficient administrative permissions, Entra refuses the operation, including when the highest-level administrator role (Global Administrator) attempts to disable their own account.
After some digging, the situation is explained by the requirement to hold the Privileged Authentication Administrator role to revoke user access for administrator accounts.
Protecting Privileged Administrator Accounts
The administrator accounts protected in this manner are those holding roles deemed to be privileged (a preview feature), or as Microsoft notes, roles that can be used to “delegate management of directory resources to other users, modify credentials, authentication or authorization policies, or access restricted data.” Although Microsoft documents the permissions required to disable administrator accounts, I found no explicit documentation explaining why Entra refuses attempts to disable the account currently being used by a signed-in administrator.
Two different safeguards seem to be at work. One protects privileged administrator accounts from being disabled by lower-privileged administrators. The other prevents administrators from disabling the very account they’re currently using, even if that account holds sufficient permissions to manage other administrator accounts.
Both safeguards are enforced by Entra ID rather than by a specific client such as the Graph PowerShell SDK or the Entra admin center. The protection makes perfect sense. The error message does not. Reporting that the accountEnabled property is invalid sends administrators looking in entirely the wrong direction when the real issue is that Entra has decided the operation should not be allowed.
Microsoft 365 for IT Pros is a trusted source of technical insight that helps tenant administrators stay informed and productive. We update the content every month to reflect changes across Microsoft 365, and monthly update #135 is available now. Get your copy from Gumroad.com and stay up to date with the information that matters most for keeping your tenant secure, compliant, and running efficiently.