10 tips to improve your administrative accounts posture in Azure AD


General Introduction

As I speak to more and more customers about the matter, I notice that a lot of companies have a questionable security posture regarding their administrative accounts. For example, many admins are using their “daily-runner” account as privileged administrators for their tenants, or synchronizing their domain admins to privileged roles in Azure AD. In general, a lot of admin accounts aren’t getting the care they deserve.

Losing privileged access is a big deal and it’s happening more and more often. Clearly, attackers love targeting privileged accounts because they give them quick and broad access to a company’s important assets, leaving a lot of defences behind.

I decided to write this article to highlight some of the controls that should be implemented in our tenants to improve our admin accounts posture, as privileged access management should be one of our top security priorities. These points have been aggregated after a lot of discussions with colleagues and experts on the topic and with the help of best practices from Microsoft Docs.


The 10 tips list

As a best practice, administrator accounts should be: 

  1. Separate from your daily-runner account. Collaboration tasks should not be done from the administrative accounts. While it’s of course not convenient, admins should get used to handling multiple accounts for different permission levels.
  2. Cloud-only. Your Azure AD administrator accounts should be different to your on-premises admins, and should not be synchronized from the on-premises Active Directory. This is because if one’s identity gets breached, the attackers would have easy access to both Azure AD and AD.
  3. Mailbox-less. The easy way to implement this is by not assigning admins licenses. You should enable a forward from your admin account to your daily driver account, or a dedicated mailbox/distribution list assigned to an unprivileged user. 
  4. Using phishing-resistant authentication methods. FIDO2 keys should be your primary way of accessing your admin accounts. If FIDO2 keys or similar methods are unavailable to you, you should have at least MFA active on your account with number matching and additional details active. Ideally, you should also restrict access to your resources to only allow access from known devices.
  5. Reviewed periodically. Periodically analyse the list of admins, and remove excessive permissions. There are a lot of cool tools that can help you out with this, or you can script your own.
    Microsoft suggests analysing these roles first, then moving to the other administrative accounts: Global Administrator, Privileged Role Administrator (they are a click away from being Global Admins), Exchange Administrator, and SharePoint Administrator. Remove guest admins where applicable.
  6. Protected by Identity Protection. Identity Protection automatically scans your sign-ins and blocks the user if anything strange is going on. You can also configure it to force the user to do a self-service password reset.
  7. PIM-enabled. You should have administrative privileges only when you require them. Having admin privileges active on an account 24/7 without a specific reason is not the best idea. Moreover, whenever you enable your PIM roles, you get an email, to keep everything under control.
  8. Backed up by one or two emergency accounts. If bad things happen, you should still be able to access your tenant. Emergency access administrators help you with that. You should also consider activating a rule to alert you when this admin gets used. Here is a cool guide to create passwordless emergency admins with FIDO2 Keys: https://janbakker.tech/break-glass-accounts-and-azure-ad-security-defaults/
  9. Logged constantly. Configure logging for your tenant by exporting the Azure AD logs to a Log Analytics workspace (https://azvise.com/2023/06/21/export-azure-ad-entra-logs/). Alerts should be configured for risky actions (like modifying a conditional access policy). Also, check if you have enabled the Unified Audit Logs: https://azvise.com/2021/10/26/office-365-enable-unified-audit-logs/
  10. Protected with Conditional Access Policies. This is a very broad topic, but make sure that at least the following apply. Those policies can be created quickly using Conditional Access policies templates: Require phishing-resistant multifactor authentication for admins, Securing security info registration, block legacy authentication, require multifactor authentication for Azure management, Require compliant or hybrid Azure AD joined device for admins, Block access for unknown or unsupported device platform, No persistent browser session. Of course, before activating this policies, be really careful to test things out and exclude the emergency account(s).

Additional points:

  • Use precise Administrative roles. Of course, using highly privileged accounts it’s convenient, as you have only to activate one role to manage everything. But if you assign people the correct permissions they need for their daily job, a lot of headaches can be prevented. Check out this documentation page to ease the pain of finding the right role to assign:
    https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
  • Consider Privileged Access Workstations. Having PAWs for Admin roles can help a lot with your security posture. PAWs can be configured on Azure AD with device filtering rules in Conditional Access Policies. For example the CAP may require: When all admins, except for the emergency access administrator, access all apps, block access unless they are using specified devices, filtered by device ID.
    These PAWs should be AAD joined, and are usually for Global Admins and Privileged Role Administrators. Also, having Bitlocker on at least this machines is a must.
    Spoofing device IDs with Powershell is sadly possible at the moment, but it’s kinda hard and not one of the first things that attackers will do. As always, a lot of this depends on your security risk acceptance level.
    If you want to drill down on PAWs, this article might be useful: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
  • If you have an on-premises AD, you should really look into improving your AD security, as your AAD security and your AD security are tightly correlated. A tiering model for Active Directory is really useful to better manage your forests, and implementing Defender for Identity gives you a whole new level of analysis and reaction on what’s going on. This won’t be discussed here, but there are plenty of resources to get started with this. Also, again, don’t sync your on-prem administrators to Azure AD. You should have some level of filtering from on-prem to Azure AD, such as filtering by OU or by AD attributes.
  • Also not discussed here, as Azure permissions are a whole topic by themselves, but you should really be analyzing Azure privileged permissions and keeping everything under control.


Link to Microsoft docs, and additional reads:

Securing privileged access

Ensure separate user accounts and mail forwarding for Global Administrator accounts

Enterprise access model

Token Protection

Force Azure File Sync tiering

If you are encountering issues with Azure File Sync, or you just want to force the process so that you can free some space now, follow the commands shown below:

#Import the commands
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"

#Force the synchronization of the folder you have specified in the sync group
Invoke-StorageSyncCloudTiering -Path <sync_group_path>

If you want to get some logs out of the operation for troubleshooting, send these commands in a separate PowerShell window before launching the script above:

cd C:\
New-Item -ItemType directory -Path C:\AZfslogs
cd "C:\Program Files\Azure\StorageSyncAgent"
Import-Module .\AFSDiag.ps1
Debug-AFS -OutputDirectory C:\AZfslogs -KernelModeTraceLevel verbose -UserModeTraceLevel verbose

You can terminate the command once the sync is concluded and get the logs in the C:\AZfslogs folder.

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