Governing Azure Active Directory service accounts

There are three types of service accounts in Azure Active Directory (Azure AD): managed identities, service principals, and user accounts employed as service accounts. When you create service accounts for automated use, they're granted permissions to access resources in Azure and Azure AD. Resources can include Microsoft 365 services, software as a service (SaaS) applications, custom applications, databases, HR systems, and so on. Governing Azure AD service account is managing creation, permissions, and lifecycle to ensure security and continuity.

Learn more:

Note

We do not recommend user accounts as service accounts because they are less secure. This includes on-premises service accounts synced to Azure AD, because they aren't converted to service principals. Instead, we recommend managed identities, or service principals, and the use of Conditional Access.

What is Conditional Access?

Plan your service account

Before creating a service account, or registering an application, document the service account key information. Use the information to monitor and govern the account. We recommend collecting the following data and tracking it in your centralized Configuration Management Database (CMDB).

Data Description Details
Owner User or group accountable for managing and monitoring the service account Grant the owner permissions to monitor the account and implement a way to mitigate issues. Issue mitigation is done by the owner, or by request to an IT team.
Purpose How the account is used Map the service account to a service, application, or script. Avoid creating multi-use service accounts.
Permissions (Scopes) Anticipated set of permissions Document the resources it accesses and permissions for those resources
CMDB Link Link to the accessed resources, and scripts in which the service account is used Document the resource and script owners to communicate the effects of change
Risk assessment Risk and business effect, if the account is compromised Use the information to narrow the scope of permissions and determine access to information
Period for review The cadence of service account reviews, by the owner Review communications and reviews. Document what happens if a review is performed after the scheduled review period.
Lifetime Anticipated maximum account lifetime Use this measurement to schedule communications to the owner, disable, and then delete the accounts. Set an expiration date for credentials that prevents them from rolling over automatically.
Name Standardized account name Create a naming convention for service accounts to search, sort, and filter them

Principle of least privileges

Grant the service account permissions needed to perform tasks, and no more. If a service account needs high-level permissions, for example a Global Administrator, evaluate why and try to reduce permissions.

We recommend the following practices for service account privileges.

Permissions

Get-AzureADDirectoryRoleMember, and filter for objectType "Service Principal", or use
Get-AzureADServicePrincipal | % { Get-AzureADServiceAppRoleAssignment -ObjectId $_ }

  • Use OAuth 2.0 scopes to limit the functionality a service account can access on a resource
  • Service principals and managed identities can use OAuth 2.0 scopes in a delegated context impersonating a signed-on user, or as service account in the application context. In the application context, no one is signed in.
  • Confirm the scopes service accounts request for resources
  • Ensure you trust the application developer, or API, with the requested access

Duration

  • Limit service account credentials (client secret, certificate) to an anticipated usage period
  • Schedule periodic reviews of service account usage and purpose
    • Ensure reviews occur prior to account expiration

After you understand the purpose, scope, and permissions, create your service account, use the instructions in the following articles.

Use a managed identity when possible. If you can't use a managed identity, use a service principal. If you can't use a service principal, then use an Azure AD user account.

Build a lifecycle process

A service account lifecycle starts with planning, and ends with permanent deletion. The following sections cover how you monitor, review permissions, determine continued account usage, and ultimately deprovision the account.

Monitor service accounts

Monitor your service accounts to ensure usage patterns are correct, and that the service account is used.

Collect and monitor service account sign-ins

Use one of the following monitoring methods:

Use the following screenshot to see service principal sign-ins.

Screenshot of service principal sign-ins.

Sign-in log details

Look for the following details in sign-in logs.

  • Service accounts not signed in to the tenant
  • Changes in sign-in service account patterns

We recommend you export Azure AD sign-in logs, and then import them into a security information and event management (SIEM) tool, such as Microsoft Sentinel. Use the SIEM tool to build alerts and dashboards.

Review service account permissions

Regularly review service account permissions and accessed scopes to see if they can be reduced or eliminated.

The free PowerShell sample collects service principal OAuth2 grants and credential information, records them in a comma-separated values (CSV) file, and a Power BI sample dashboard. For more information, see Microsoft Azure AD Assessment, Assessor Guide.

Recertify service account use

Establish a regular review process to ensure service accounts are regularly reviewed by owners, security team, or IT team.

The process includes:

  • Determine service account review cycle, and document it in your CMDB
  • Communications to owner, security team, IT team, before a review
  • Determine warning communications, and their timing, if the review is missed
  • Instructions if owners fail to review or respond
    • Disable, but don't delete, the account until the review is complete
  • Instructions to determine dependencies. Notify resource owners of effects

The review includes the owner and an IT partner, and they certify:

  • Account is necessary
  • Permissions to the account are adequate and necessary, or a change is requested
  • Access to the account, and its credentials, are controlled
  • Account credentials are accurate: credential type and lifetime
  • Account risk score hasn't changed since the previous recertification
  • Update the expected account lifetime, and the next recertification date

Deprovision service accounts

Deprovision service accounts under the following circumstances:

  • Account script or application is retired
  • Account script or application function is retired. For example, access to a resource.
  • Service account is replaced by another service account
  • Credentials expired, or the account is non-functional, and there aren’t complaints

Deprovisioning includes the following tasks:

After the associated application or script is deprovisioned:

  • Monitor sign-ins and resource access by the service account
    • If the account is active, determine how it's being used before continuing
  • For a managed service identity, disable service account sign-in, but don't remove it from the directory
  • Revoke service account role assignments and OAuth2 consent grants
  • After a defined period, and warning to owners, delete the service account from the directory

Next steps