Just Enough

Administration in the cloud follows the paradigms and procedures of local infrastructures. Administrators log in with special, and specially protected, admin accounts and carry out their activities. To prevent theft, these accounts usually have particularly long passwords or need to be unlocked from secure systems before they can be used. Azure Active Directory (AAD) now also looks to offer this level of security.

Even the best cloud services usually require administrative tasks that are handled by internal administrators. Not all tasks are built into Software-as-a-Service (SaaS) offerings. Among other things, admins have to work on detailed service configurations, assign permissions, review logfiles, and assure data security.

These tasks are assigned to employees with administrative responsibility whose logon accounts in the SaaS applications have the appropriate authorizations. A number of practices are recommended for protecting these sensitive admin accounts to prevent them from falling into the wrong hands or from accidental misadministration.

Of primary importance is the use of separate accounts – accounts that are not used in daily work, such as email, phone calls, or internet searches – for administrative activities. By separating accounts, you can reduce the risk of administrators accidentally misusing their accounts or being exposed to an attack that compromises their account and spreads to other parts of the enterprise.

Thus, you will want each admin to have two accounts, one for daily work and one for administrative activities, that should be distinguishable by name (e.g., a prefix such as ADM_). This separation of accounts also forces admins to specify explicitly the administrative account when logging in to managed resources.

Targeted Admin Restriction

Admin accounts are traditionally configured to keep all permissions permanently. Only when admins leave the company or move to another department are the accounts deleted. The risk of an account being stolen without anyone noticing, and then being used arbitrarily, is always a problem. One approach to mitigating damage is just-in-time (JIT) privileges, wherein admins do not have permanent privileges but receive temporary privileges through an action that activates the admin account for special permissions (e.g., access to a portal and manual activation of permissions, which can be subject to approval and a dual control principle [1], also called the four-eyes or two-man rule). The JIT part of this is that even administrative accounts only have administrator powers if they have been previously enabled and approved. Microsoft refers to this process as "activation."

Time limits are another security mechanism; if the permissions expire automatically, no one has to worry about removing them. The duration can be set flexibly from a few minutes to a few hours, depending on which authorization is requested and how extensive the activities are.

Another dimension of the JIT function and the explicit activation of permissions for administrative accounts is that a plausibility check suddenly becomes possible. The company can see who regularly uses the administrative permissions that come with an account (and are explicitly activated), as opposed to wondering what admin accounts exist and when they are logged on.

When administrative accounts are defused by the JIT functions, but multiple roles are still concentrated on one account, privileged identity management (PIM) provides another approach: just enough administration (JEA). Assuming that admins are also a SharePoint Administrator and Exchange Administrator, in addition to their activities as User Administrators, only the roles that they actually need for the current activity are unlocked for them. The other roles retain their "authorized" status but are not permitted until explicitly activated (Figure 1). If such an account is compromised, the attacker cannot assume all roles at the same time but, instead, has to assume the roles individually, which can require approval and be subject to usage time restrictions.

Authorizing Admins

To become better acquainted with the concept, you should explore the functions in the AAD portal. The transfer of permanent authorizations to "authorized" roles has to be configured on a per-user basis so that the entire PIM function can be tried out first and later used across the board.

In the AAD portal, use All services to navigate to Privileged Identity Management. In the first step, you will be asked for permission to activate PIM. If the currently used admin account is not protected by Azure multifactor authentication (MFA), the corresponding configuration is now completed. You define the verification variant yourself for SMS, callback, or the Authenticator app. Then click on Consent in the AAD PIM part of the portal. The Admin account is automatically added to the AAD PIM administrators (Privileged Role Administrator), who can set the configuration of all privileges and JIT requirements.

By clicking on Azure AD Privileged Roles and Sign Up, you unlock the AAD part of PIM, which comes up with an overview of the administrative AAD users and a login overview. To see all your privileged roles in AAD, click on Role. Some of them may look familiar (e.g., Global Administrator, Exchange Administrator, Device Administrators). The Members submenu shows all roles and their respective members. In the menu above in Group, you can switch between viewing all admins and their groups, and all groups and their admins. The entire list is made available as a CSV download by pressing Export. In general, the rule still applies that the fewer admins you configure, the better.

You can finally get into action by clicking Wizard and following the three steps shown. First, all privileged roles are searched; second, all members are converted from permanent members to authorized members. Third, the results are validated. The wizard lets you change the membership of the admins in their admin groups: On logging in, they are no longer immediately members of the privileged group but have to activate access first.

When you select Convert members to eligible, the wizard displays all roles for which privileged admin users have been found. Selecting the individual users and pressing Next completes the conversion. The changes are described in detail in step 3, which you confirm with OK.

If, for example, Exchange Administrator Sarah wants to continue to use her administrative privileges, she first needs to activate them. In the AAD portal, she accesses Azure AD Privileged Identity Management | My roles to see an overview of all the roles, which she can then activate them by pressing Activate. A new blade opens above it, in which Sarah can set the required duration of the extra privileges. If she needs MFA, Sarah has to provide a reason before activation – and a reason if the PIM administrators also require this. If no approval is defined for the role, Sarah can start working with her Exchange privileges immediately. If the role needs to be approved, the selected admins will receive email notifying them that certain permissions require approval. The confirmation can also be found in the AAD PIM section in My Approvals.

Defining Role Settings

For each AAD role found, PIM supports a set of configurations that are used to activate the role by authorized users. The settings become visible when you select a role in Privileged Identity Management | Azure AD Directory Roles | Settings (Figure 2). Under the Activations section, administrators determine the duration of the authorization before it needs to be reactivated. Additionally, email notification is provided for admins during activation, and the requirement to supply a ticket number is enforced.

Enforcing MFA for non-critical roles is optional; for highly critical roles, the AAD portal hides the option and enforces MFA automatically. The last option is interesting if rigorous risk management is required and all actions need to be documented and are subject to dual controls. The ability to activate permissions can be made subject to optional confirmation.

Protecting Azure Resources

In addition to the obvious AAD and Office 365 roles in AAD, PIM offers the ability to protect privileged Azure resource admins. As for AAD roles, the respective Azure resources have to be added before they can be managed. In the PIM section of the AAD portal, you can do this by selecting Azure resources | Discover resources. PIM manages permissions for Azure resources at the subscription, resource group, or resource level, covering different types of administrators, from subscription administrators to infrastructure admins to owners of individual but critical virtual machines.

The selected resource can now be found in the Azure Resource Overview. The Resource filter drop-down lets you change the view of the resource types shown if you want to configure administrative roles at the resource group or resource level, rather than at the subscription level. The overview displays the available roles to be managed and the administrators who currently own the roles. A click on the resource opens the detailed view in which you define the role settings and authorized users for each role.

The configuration is similar to that of AAD roles. Roles lists all roles that Azure has defined for its resources as an overview, with active and authorized users. The detailed settings for each Azure role are stored in Role settings. To assign the Contributor role for a resource group to a user, click Azure resources in the PIM portal and select the appropriate resource type and target resource.

Once the Azure resource is loaded in the blade, click on Roles and select Contributor and + Add member. Follow the wizard and select the target user or audience for assignment. In Set membership settings, you then define whether the role assignment should be active or authorized. You can also specify start and end dates. For Azure resources, Microsoft specifies that active role assignments shall not last indefinitely. For Contributor, Microsoft defines a maximum period of one month if the role is permanently configured, and three months if authorized.

Below Role settings, you can define the settings precisely. The role settings are configurable per resource group, resource, and subscription. Settings for the Contributor role can therefore differ between resource groups. In addition to the reason for activation and MFA settings that are already known for AAD roles, you can time-constrain the authorized and active role assignments, if necessary.

Licenses

PIM is subject to a special type of license at Microsoft in Azure AD, which enforces and tracks permissions. Users who benefit from PIM must have an Azure AD Premium 2 or Enterprise Mobility Suite E5 license that includes AAD Premium 2. A license must remain available for each user who

• is subject to an admin role in PIM,
• can enable admin roles from PIM,
• approves or rejects requests for admin roles,
• obtains administrative privileges for Azure resources (JIT or directly), or
• can view the access reports.

The exact license requirements are best obtained from your Microsoft account team. However, so you can plan to use PIM, it makes sense to be aware of the financial framework and have an estimate of the required licenses. All administrators of AAD and the Office 365, Exchange, SharePoint, Skype, and Teams workloads need a license if you are rolling out the system across the board – as do the security and risk teams who need to check all administrative requests and read the reports.

Checking Authorizations

To ensure that employees continue to use and actually need their administrative authorizations, IT managers should review and confirm role definitions regularly. Access reviews in PIM are designed for this purpose. When administrators request the re-authentication of permissions, either manually defined reviewers need to confirm the correctness of each individual account (Selected users) or the owners of the accounts do this themselves (Members (self)).

Access reviews can be performed just once or weekly, monthly, quarterly, or annually. The reviews have an expiry date, after which automated actions are optionally possible: Unconfirmed admins can continue to exercise the privileges or be removed automatically from JIT authorization.

To create a review as the PIM administrator, select Azure AD directory roles in the PIM part of the AAD portal and then select Access reviews. In the overview of the existing reviews click New. After you have entered the name and description for the review, select the frequency and duration of the reviews. Especially for highly privileged roles, a periodic check of the permissions is recommended – quarterly is fine, especially for Global Administrators or Office 365 Service Administrators.

The length of the review indicates how much time the reviewers or members of the roles have for the confirmations. Especially if you want to enforce changes to the membership automatically further down in Upon completion settings, you should allow sufficient time for a review and an allowance for vacations or public holidays. You can select exactly one privileged admin role per review.

In Reviewers, a distinction is made as to whether the review and the approval should be carried out by the role owners (i.e., the admin users themselves) or auditors, which are certain selected individuals. The reviews can therefore be carried out by a third independent person or by the owners themselves.

All activities carried out in PIM are recorded in the audit log and stored for later traceability, including the activation of PIM, changes to role definitions, membership changes in roles, requests to activate authorized role members, information on the reasons for activation and approval, and details of who granted approval.

The audit logs are under Directory roles audit history and Resource audit and can be sorted by role, action, and time. A filter option lets you limit the entries to certain time periods and select only the desired roles from a selection list.

Bottom Line

Especially for larger enterprises in which cloud services are managed by a group of admins and security is a top priority, PIM is worth a look.

MFA for administrative accounts should always be the first step toward securing privileged accounts; however, MFA does not provide protection against "accidental" administration or an attacker that hijacks a session after an MFA prompt, which is also valid for a few hours. PIM in AAD expands JIT and JEA, giving organizations more control over changes in AAD services and Azure resources.

The time limit on permissions can provide protection against the disease from which many Windows AD deployments still suffer today: a static, excessively long list of domain admins that is never tidied up and, in the worst case, contains accounts that are used for daily work, such as email and PowerPoint.