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.

Figure 1: As soon as a role admin has confirmed temporary permissions, the work for Exchange Administrator Sarah can start.

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.

Figure 2: The audit log provides information on all changes to the system as well as the requested and approved role uses by users.

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.