Recommended Practices for your Hybrid Identity Admin accounts
By Sander Berkouwer as written on dirteam.com
I’ve been involved in quite some Microsoft Hybrid Identity implementations: Big and small implementations, with and without AD FS next to Azure AD Connect, with Azure AD Connect and 3rd party tooling.
One thing though, all these implementations had in common was the admin account(s) they needed done right.
You can dial a lot of knobs when implementing Hybrid Identity. One of the more important knobs is the one that turns on federated single sign-on to your organization’s on-premises Active Directory Federation Services (AD FS) implementation. This particular setting is changed using the Azure Active Directory PowerShell Module.
Many early adopters of Microsoft Hybrid Identity using AD FS have already experienced a common pitfall: when you’ve converted a DNS Domain in Azure Active Directory to federated, you need AD FS to authenticate. Even to change the setting from federated back to standard.
Note: The main reason to convert from federated to standard is because there’s something wrong with the AD FS implementation…
So, how do you cope with this challenge?
Global admins and/or on-premises admins
One of the first things, prospect admins learn during training is to use separate accounts for admin purposes and day-to-day usage, like e-mail and browsing. This is based on the principle of least (administrative) privilege. The same holds true for Azure Admins:
You don’t want to assign Global Admin rights in Azure Active Directory to your day-to-day account.
In most on-premises environments, admin accounts are prefixed with adm in their username or postfixed with a number. The latter number strategy allows for a quick overview of the impact of an account; when 1 represents print admin or account operator rights and 9 represents both on-premises Enterprise Admin and Azure Global Admin, the number quickly indicates how much impact deleting the account might have or what account to use for a specific task.
However, there is a dark side to this practice: a person with malicious intent, might quickly target accounts of the most interest.
Admin roles in Azure Active Directory
Azure Active Directory offers the following administrator roles
These roles can be the basis for number postfixing your Azure Active Directory admins.
Note: For Azure Resource Management (ARM)-based resources, you can additionally add your own Roles-based Access Control (RBAC) for finer-grained access management. While the users and groups would live in Azure Active Directory, none of the Azure Active Directory resources, themselves, are ARM-based, momentarily.
Azure Active Directory Privileged Identity Management
Azure Active Directory Privileged Identity Management (PIM) allows for non-permanent and more granular just-in-time admin roles. Auditing and reporting allows for insights on the actual usage of administrative privilege and accounts that no longer need administrative privileges. By acting on these insights, the attack surface of privileged accounts is minimalized
Authentication is the process of confirming the truth of an attribute of an entity – in short, confirming its identity. The most common attribute checked to confirm the identity of the person signing in with a user account (object) in networking environments is the password attribute. The password attribute is a value that the person sets. It is something the person (can prove he/she) knows. To make authentication more reliable and, thus, confirm the identity without a doubt, multiple authentication factors may be combined. For instance, something the person (can prove he/she) has in physical possession and/or something the person (can prove he/she) is are authentication factors that can be used for Multi-Factor Authentication beyond mere password validation.
Microsoft offers free Multi-Factor Authentication for Global Admins in Azure Active Directory. This solution offers reliable authentication for these accounts.
Note: Azure Multi-Factor Authentication for Admins is only free, when Azure Active Directory has not yet been configured with a consumption-based license (pey-per-authentication) for Azure Multi-Factor Authentication.
It is highly recommended to enable multi-factor authentication on each account that has the Global Administrator role assigned in Azure Active Directory. If your organization, utilizes other admin roles (either the pre-defined roles, Azure AD PIM roles and/or Azure ARM RBAC) MFA could be applied according to the combination of (some sort of) classification of the administrative privilege(s) and day-to-day burden.
For instance, you may decide not to enforce MFA for logins for User management administrators, as their privileges are not as high-impact as other privileges and these people may need to use their privileges often.
From a technical perspective, the tooling used, needs to support modern authentication. If you want to use multi-factor authentication for admin purposes, you will need to use at least the following versions of the admin tools:
Version 8362.1 of the Azure Active Directory PowerShell Module (released January 19, 2015)
Version 220.127.116.11 of Azure AD Connect (released February 2016)
The curse of the Microsoft Account
With Windows 8, Microsoft introduced the Microsoft Account. This account, formerly known as a Windows Live ID, can be used to log onto Windows devices ever since or provide single sign-on to consumer-based Microsoft services when logged on with a domain account (Windows Store, Cortana, etc.). The functionality is called the Connected Accounts feature. This was Microsoft’s solution to bridging the work-life divide. However, Microsoft accounts are not company-owned, but personally-owned.
Microsoft Accounts can also be used in Azure Active Directory. They can even be assigned admin roles (although some limitations apply).
You should really need to decide whether you want to assign roles to accounts your organization does not own and/or manage.
I feel strongly, that admin accounts with e-mail addresses like firstname.lastname@example.org are not that professional. When hiring a consultant, this kind of administrative practices might lead to some raised eyebrows.
To add to injury, several display and sign-in problems occur when admins use Microsoft Accounts with the same domain part (everything after the @-sign) as your organization does.
There are two ways to create an Azure Active Directory directory:
1.The Azure route
2.The Office365 route
Azure tenant names, created by default, when the Azure tenant is created from a Microsoft account might raise the same eyebrows: For the email@example.com Microsoft account you’ll end up with the joshaarbosoutlook.onmicrosoft.com tenant name. Again, think of when the person of the named account leaves, the tenant name will leave a permanent mark on the organization.
Note: When you take the Office365 route to create the Azure Active Directory tenant, the tenant name for Azure Active Directory is the same as the tenant name for Office365. This name is defined when you create the Office365 tenant.
To sync or not to sync admin accounts
In line with the principle of least administrative effort, you might not even want to assign Azure admin privileges to on-premises admin accounts, that are synchronized to Azure Active Directory.
Although this might result in a situation where an admin person needs to use six accounts, instead of having the benefit of single sign-on, like everyone else, it does provide a separation of administrative privileges and fault domains…
How to name these accounts? AdminHansWorst6@joshaarbosoutlook.onmicrosoft.com might not look very sexy and might possibly cause RSI, it does the job for a privileged account that is assigned the Service Administrator role in Azure Active Directory. A separate (default) vanity UPN Suffix might become a requirement when the person to which the original Microsoft account belongs, leaves the organization.
Note: Don’t forget to add other Global Admins and remove the original Microsoft Account from the Global Administrator role and/or your Azure directory.
To federate or not to federate admin accounts
When synchronizing accounts. another big question remains: To federate admin accounts, or not.
In my opinion, federation offers benefits for everyone. However, I don’t feel that strongly for admin accounts. Password Synchronization using Azure AD Connect offers a solution that is equally beneficial for admins, yet provides an exit strategy for when the on-premises Active Directory Federation Services (AD FS) implementation fails.
Since federation in Azure Active Directory is governed using DNS domains, a quick and dirty way of removing admin accounts from the scope of federation is by assigning a separate userPrincipalName (UPN) Suffix to admin accounts on-premises. For instance yourorganizationsadmins.com can be used for admins, while yourorganization.com is used for the day-to-day user accounts.
Converting child and parent domains
One of the reasons why I choose yourorganizationsadmins.com in the above example is because this introduces an entirely new DNS Domain, instead of a subdomain.
While you can use subdomains for your admin accounts, it is not recommended: When converting domains in Azure Active Directory (from standard to federated, and vice versa), by default, all subdomains will be converted too.
Note: The way around this, although unsupported, is to place the parent domain and the child domain in different Azure tenants.
Use these recommended practices for Azure Admins in Hybrid Identity scenarios:
Separate admin privileges from day-to-day accounts
Deploy Multi-factor Authentication
Deploy Azure AD Privileged Identity Management (PIM)
Use admin account and password synchronization for your convenience
Don’t use Microsoft Accounts
Don’t federate admin accounts
Assign admin accounts a separate UPN Suffix on-premises and/or in Azure AD