ASD's Blueprint for Secure Cloud

Enterprise Users

This section describes the design decisions associated with user identities, emergency access, and service accounts for system(s) built using ASD's Blueprint for Secure Cloud.

Estimated reading time: 7 minutes

The Blueprint leverages Microsoft Entra ID as the Identity and Access Management system. However in reality, identity management requires a number of systems which would include multiple other systems such as human resources and finance and have a central user directory such as Microsoft Entra ID at the centre for authentication and authorisation of users.

Microsoft Entra ID assigns each user a globally unique identifier (GUID) and a unique user principal name (UPN). The GUID is a 128 bit text string for the user identity. The UPN is a username in the form of an email address and can be derived from a synchronised on-premises Active Directory or assigned directly within Microsoft Entra ID.

Workload identities

Microsoft 365 workload identities are specific to individual services or workloads within the Microsoft 365 ecosystem, such as Exchange Online or SharePoint Online. Whilst the identities are tied to the user UPN the workload identities are created for specific purposes, such as sending emails in Exchange Online. Each workload requiring this additional layer is known as the workload-specific directory store. It is named after the related workload, for example: Exchange Online Directory Services (EXODS), and SharePoint Online Directory Services (SPODS).

Display name

When creating a new user, Microsoft Entra ID will assign the display name based on the user first name and last name. Microsoft 365 uses the display name within the global address list (GAL) for emails, Teams chats, and access control in various services. Microsoft 365 also displays user photos in a number of services. Where a user photo is not provided, it instead uses the initials taken from the display name to serve as a fallback. For example, the user photo for Joe User will display JU when there is no image. Within a hybrid configuration the display name is created and managed within the on-premises Active Directory.

Inactive users

ISM Security Control 1404 lists that inactive user accounts need to be in a disabled state after more than 45 days of inactivity.

This can be achieved via a custom script set to run on a scheduled basis. Below is the recommended logic that the script should use to determine if an account is inactive or not:

  • If user account is not disabled
  • If user has logged on
  • If user is not Break Glass Account
  • If last login is greater than 45 days
  • If all above are True disable account

Cloud-native implementation

Hybrid implementation

Service accounts

There are three types of service accounts native to Microsoft Entra ID: Managed identities, service principals, and user-based service accounts. Service accounts are a special type of account that is intended to represent a non-human entity such as an application, application programming interface (API), or other service.

For services hosted within Azure, Microsoft recommends using a managed identity if possible, and a service principal if not. Managed identities cannot be used for services hosted outside of Azure. In that case, Microsoft recommends a service principal.

User based service accounts are standard user accounts where the password and MFA methods are shared between multiple individuals. For this reason Microsoft does not recommend user accounts as service accounts because they are less secure. This includes on-premises service accounts synchronised to Microsoft Entra ID, because they aren’t converted to service principals.

Emergency access admin accounts

Emergency access or ‘break glass’ accounts are accounts used to restore access to an environment or tenant. Break Glass Accounts should be an option of last resort and should only be used when normal administrative accounts cannot be used to restore access. Example of this is where conditional access has malfunctioned and both users and administrative staff are unable to authenticate into the environment, or all privileged administrator accounts are comprised in another capacity.

Microsoft best practice recommends configuration of two Break Glass Accounts. Organisations should store these accounts according to Emergency Account/break glass procedures. Best practice is for these accounts to meet the following minimum requirements:

  • They are not to be associated with any individual user.
  • They will use a different authorisation mechanism than standard administrative accounts.
  • They are cloud only accounts that use the *.onmicrosoft.com domain.
  • The passwords to these accounts are set to never expire or be cleaned up or removed due to inactivity.
  • The accounts are to be given the Global Administrator role assigned permanently.
  • At least one of the accounts is to be excluded from Multi-factor Authentication (MFA).
  • At least one of the accounts is to be completely excluded from all Conditional Access policies.
  • The accounts should be stored on paper, in two or three separate parts, in secure, fireproof safes that are in disparate locations.
  • Use of these accounts is monitored and only used in genuine emergencies.

Emergency access account configuration

ConfigurationValueDescription
UsernameAny value that is not associated to a specific user.Accounts are not to be associated with any individual user.
Account typeAccounts are cloud only accounts that use the *.onmicrosoft.com domain.Only *.onmicrosoft.com accounts should be used as per Microsoft best practice.
Password ExpiryPasswords are set to never expire.Ensures the passwords for these accounts are valid in an emergency.
RolesEmergency access accounts will be assigned the Global Administrator role.The accounts are to be given the Global Administrator role assigned permanently.
Multi Factor Authentication (MFA)Both Emergency access accounts will be excluded from MFA.MFA device may not be available when the emergency access account is required.
Conditional AccessAt least one of the accounts is to be completely excluded from all Conditional Access policies.The emergency access account may need access to fix an issue and it would not be beneficial if a policy were to block access.
Physical access to account detailsAccount details will be stored on paper in an appropriate location.It is strongly recommended that the accounts are stored on paper, in two or three separate parts, in secure, fireproof safes that are in disparate locations.
Monitoring of accountsAccount usage will be monitored via Defender for Cloud Apps.Use of these accounts is monitored and only used in genuine emergencies.

Security & Governance

  • None identified

Design

References

Do you have a suggestion on how the above page could be improved? Get in touch! ASD's Blueprint for Secure Cloud is an open source project, and we would love to get your input. Submit an issue on our GitHub, or send us an email at blueprint@asd.gov.au

Acknowledgement of Country icon

Acknowledgement of Country
We acknowledge the Traditional Owners and Custodians of Country throughout Australia and their continuing connections to land, sea and communities. We pay our respects to them, their cultures and their Elders; past, present and emerging. We also recognise Australia's First Peoples' enduring contribution to Australia's national security.

Authorised by the Australian Government, Canberra