Azure ID / O365 break-glass accounts
What is an break-glass account?
These highly privileged accounts should only be used when normal administration accounts cannot log in.
Microsoft recommends at least two icebreaker accounts for an Azure AD tenant.
Icebreaker accounts should be kept secret and no administrator should know the entire password without “breaking the ice”. To achieve this, the password is divided into at least 2 parts.
How to create this type of account?
Here are some rules to follow when creating these accounts:
- Accounts can be created in Azure AD, Office 365 or PowerShell.
- An example script has been prepared to handle this creation.
What security to bring to this break-glass account
- Username must be complex, and difficult to guess
- The password should also be complex, preferably divided into two parts, stored (in envelopes) in two different places secured in fireproof (or virtual) safes.
- Only a list of administrators should be authorized to use these accounts. These administrators should, of course, also have the role of global administration under normal circumstances.
- It is very important to have enabled rules for monitoring the use of these accounts from Azure AD connection logs, audit logs and to act on any unforeseen activity. These rules should be tested BEFORE giving maximum rights.
What configuration for a Brise-Glace account
- The role of global administrator must be permanently assigned.
- The password must not expire.
- MFA must not be activated on this account.
- The account must be excluded from ALL conditional access policies.
- It should not be assigned to a specific person.
- This account should only be used for the cloud.
- You must use the default tenant domain “onmicrosoft.com” (to avoid all domain and federation problems).
- It should therefore not be federated or synchronized with the on-premises AD.
- This account must not be associated with mobile phones or hardware tokens provided by employees.
- 64 random characters for the name
- Password made up of 2 random complex chains of 64 signs recorded in 2 files
Of course, it is possible and quite easy to modify the different limits in the script (size of the account, of the password).
Create the alert strategy
Indeed, as long as this strategy is not created and verified, it is especially important not to give the rights of global administration to the icebreaker accounts.
This can be created in the “ Cloud Apps” portal :
- - Choose “ Investigate ” and “ Activity log ” in the menu.
- - Choose the last “ Log on ” type event in the activity
- - Click on the “3 points” and
- - Select “ View activity of the same type ”
- - Define strategy and parameters
- - Add the condition “member of group” and specify the group that contains all the “icebreaker” type accounts.
You can also create a strategy for each icebreaker type account (see example in Appendix 2). But, this requires testing the strategy and the alert on each account by "breaking" the ice. It is therefore advisable to test the group-based policy, by temporarily adding a standard user, which avoids having to combine the 2 parts of the password.
Please note that the groups you want to use must be added (and synchronized) in the tool before they can be used. It may take up to 2 hours before the group and then members are visible.
Note that the name of the chosen group could also be created randomly.
Choose the desired alert (s).
- o Message (email)
- o SMS (supposes a telephone credit and a connection)
- o Playbook flow
This strategy can be modified in the “control / policies” menu.
Test access and verify alerts :
Any connection to Office 365, for example on the portal (portal.office.com) will generate an alert at the slightest attempt to use:
If this is configured, the alert message arrives approximately 5 minutes after the event:
The addition of the role of global administration on Brise-Glace accounts:
An example add script is provided in Appendix 3 of this article.
If PIM (Privileged Identity Management) has been activated, there will be an alert like the one presented in Annex 3.
References
Scripts
Example of a strategy based on a single user
Example script to assign the role “Global admin ”
This script requires the "Msol" and AzureAD "snap-ins.
$ RoleName = "Company Administrator"
# $ roleTemplate = Get-AzureADDirectoryRoleTemplate | Where {$ _. DisplayName -eq $ roleName}
# Enable-AzureADDirectoryRole -RoleTemplateId $ roleTemplate.ObjectId
$ role = Get-AzureADDirectoryRole | Where {$ _. DisplayName -eq $ roleName}
$ user = get-MsolUser -userprincipalname FutureCompteBriseGlace@NomDuTenant.OnMicrosoft.com
Add-AzureADDirectoryRoleMember -ObjectId $ role.ObjectId -RefObjectId $ User.ObjectID