Enterprise Baked Privileged Access for Microsoft Cloud (no-Hybrid)

by greg.spyra


Many organizations in order to comply with information security standards keep some baseline security safeguards what includes privileged access management (PAM) and monitoring. In legacy pre-cloud environments, many PAM vulnerabilities i.e. weak passwords or creeping privileges, were identified with rather low/medium risk. With emerging cloud computing legacy security boundaries like firewalls, on-premisses directories etc does not reduce the risk of weak or simply missing PAM processes. Microsoft Cloud has attracted maybe not all but definitely majority of customers with large and complex environments. Some of the customers decided to move maintain Hybrid solution with Azure Active Directory Connect (AADConnect) synchronizing on-premises Active Directory Domain Services (AD DS) with cloud-based Azure Active Directory (Azure AD or WAAD). However, there are companies that decided to manage Azure AD as a separate target system, a security boundary with no on-premises systems impact (i.e. AD DS). These companies use pure-cloud (no-Hybrid) solutions (see Microsoft Cloud – Azure AD: doing it right) where legacy PAM processes are absent.

Cloud Privileged Access

In MS Cloud there are several activities related to privileged access. Easiest way to initially identify privileged access assignments in Office 365 is listing of all Directory Roles and Directory Role Templates. These give identities specific privileged rights across all MS Cloud systems.

Currently there are several directory roles and the number still grows:

  • Company Administrator
  • Exchange Service Administrator
  • Helpdesk Administrator
  • Device Join
  • Customer LockBox Access Approver
  • Security Reader
  • User Account Administrator
  • Directory Writers
  • Application Administrator
  • SharePoint Service Administrator
  • Billing Administrator
  • AdHoc License Administrator
  • Power BI Service Administrator
  • Directory Readers
  • Device Managers
  • Device Users
  • Privileged Role Administrator
  • Application Proxy Service Administrator
  • Device Administrators
  • Lync Service Administrator
  • Partner Tier2 Support
  • Service Support Administrator
  • Guest Inviter
  • Application Developer
  • Security Administrator
  • Compliance Administrator
  • CRM Service Administrator
  • Directory Synchronization Accounts
  • Partner Tier1 Support
  • Intune Service Administrator
  • Workplace Device Join

Security engineer may decide to use groups as another privileged access entities and dynamically provision various objects with these custom groups given higher permissions over newly provisioned objects. This approach might be used to control PAM over some privileged cloud resources (e.g. mailboxes) in different geographical locations and legal jurisdictions.

Creeping Privileges

First and the most important thing every security engineer does is assigning privileged roles to different operators so they can now continue doing they daily tasks same as in a legacy on-premises world …

eeh… let’s say this is the past and also not everywhere.

First of all security processes that aim to protect the on-premises systems have to be improved and adapted for cloud systems. It is important to remember that security boundaries protecting accounts with elevated rights are not the same or simply are absent in the cloud. Unprotected on-premisses privileged accounts with various rights over sensitive systems, productive servers and various highly privileged assignments had no direct exposure to attacker. Now adversary obtaining cloud privileged credentials can immediately access and manage O365 systems online.

This problem could be solved or the risk of compromising MS Cloud tenant could be reduced in context of creeping privileges. Most often corporate technical processes consist of change windows where operators roll-out system changes into productive environments strictly during scheduled change hours. This reduces visible failure impact and simplifies roll-back scenarios. Between change windows there are no individuals performing any operations requiring privileged rights in MS Cloud unless there is a security incident requiring emergency rights. Privileged or personal accounts having elevated rights assigned permanently fall into creeping privileges security vulnerability. Temporary access using either Temporary Privileged Access (TPA) or Break-Glass (BG) processes ensures that no single active account is exposed outside of a change window.

Temporary Privileged Access

By automating Identity and Access Management (IAM) for MS Cloud there are several processes that could be leveraged to govern access in more secure way. Great feature present in many off-the-shelf IAM systems are temporary requests or scheduled transactions. Temporary request behaves like two transactions Create – scheduled earlier or now and Delete – scheduled in the future.

Temporary Privileged Access (TPA) consists of two actions, granting and revoking privileged rights. This could be a group membership, a role assignment, or even a temporarily enabled privileged account.

Privileged Assignments

Access granted for a short time, i.e. 3 hrs – 14 days, after privileged resource, i.e. directory role or group assignment request (see Figure 1.). In O365 Company Administrator, Exchange Administrator, SharePoint Administrator, Lync Service Administrator are the roles that should not be assigned to anyone permanently. If there is an account having these rights permanently assigned this account should be controlled with TPA process for accounts, where accounts are disabled and passwords are randomly generated and not divulged to operators.

Privileged MS Cloud directory roles should have an owner or a group of owners assigned that are responsible for granting the access. Approval could be extended by local security authority, the individual that actually knows the requester and is aware of existing corporate security policies.

This process could replace existing permanent groups assignment model where employee is given permanently custom group memberships. The assignment time could be exceeded to couple months and prolongated if needed.

Organizations having dynamic Role-Based Access Control  (RBAC) or/and Attributes-Based Access Control (ABAC) in place could leverage this process (see RBAC UPSIDE DOWN) while all permanent group assignments respond to business changes and all custom requests are on temporary basis via TPA.



Figure 1. TPA – Assignment

Privileged Accounts

Highly privileged accounts that are given elevated rights permanently should be protected with different safeguards. Security engineer may maintain two highly privileged accounts each for different PAM process. One disabled with password stored (printed out) in a physical highly protected vault and the other one disabled with password dynamically generated upon TPA account request (see Figure 2.).

In MS Cloud account with Global Administrator right, means account having all or most of the directory roles assigned should be protected and not used on daily basis. This account as any resource should have an owner or a group of owners that are responsible for granting the access. Approval could be extended by local security authority, the individual that actually knows the requester and is aware of existing corporate security policies.


Figure 2. TPA – Privileged Account Activation

Break Glass

Privileged Assignments

This process is very similar to TPA processes, however there is no approval required every time access is required. Here operator or anyone requiring privileged access is assigned to a BG activator role. This role does not grant any access directly however makes any future temporary access requests possible (automatically approved).

MS Cloud Exchange Administrator or any group of activator roles once assigned gives potential for unrestricted time-constrained Exchange Administrator directory role assignment (see Figure 3.).


Figure 3. BG – Privileged Assignment


Privileged Accounts

Accounts protected with Break-Glass processes are normally highly privileged accounts e.g. Enterprise Admin accounts in Active Directory Domain Services or Global Administrator (multiple privileged directory roles) accounts in O365. Such account in MS Cloud may have assigned permanently Company Administrator, Exchange Administrator, Lync Service Administrator and SharePoint Administrator roles. Such accounts insufficiently protected compromise any security safeguards delivered by Cloud Service Provider (CSP) or that are present in cloud tenant.

Same as in TPA a security engineer may maintain two highly privileged accounts each for different PAM process. One disabled with password stored (printed out) in a physical highly protected vault and the other one disabled with password dynamically generated upon Break-Glass request.

In BG process operator or anyone requiring privileged account is assigned to a BG activator role (see Figure 4.). This role does not enables privileged account directly however makes any future temporary Break-Glass requests possible (automatically approved).


Figure 4. BG – Privileged Account Activation


Post-factum BG justification

Any Break-Glass implementation may or should introduce retrospective approval upon access request justification given by requester. This process is extremely useful when individual requires immediately access to highly sensitive resources. Request has to be justified and while access is granted simultaneously security incident is generated and is pending for approval (see Figure 5.). Security responsible within specific time (e.g. 48 Hrs) have to close the security incident by approving the access. Approval flow may be extended to include global security authorities, line managers and data custodians and others.



Figure 5. Break-Glass justification

Cloud IAM

Multi-factor Authentication with Federated-Identity

MFA for cloud, i.e. MS Cloud can solve many problems with potential insufficient Azure AD accounts protection. Federated identity makes it possible to authenticate any identity against on-premises authentication authority. Furthermore, passwords are never verified against the cloud but against internal identity provider (IdP).

MS Cloud could be easily federated (joined for authentication) with MS Active Directory Domain Services (MS AD DS) using Active Directory Federation Services (ADFS). Every personal Azure AD account maintains credentials on-premises and with properly implemented PAM program have no effective rights assigned in the cloud.

Only bottle-neck of MFA is that automation is not easy especially if using Remote PowerShell to manage O365 systems. Only this year MS finally enabled MFA support for Exchange Online (EXO), however the PoSH flow still differs from other O365 systems what makes any automation complex and almost impossible for 3rd party vendors (O365 migration teams, etc).

Named-privileged accounts

Using named privileged accounts is not a new approach and almost every large organization uses dedicated administrative accounts assigned to employee to separate personal identity from technical privileged identities (see PRIVILEGED ACCOUNT – PASSWORD POLICY AUDIT).

One of the problem with named privileged accounts is fact that these are normally permanently assigned with privileged groups and roles in various target systems and that these are almost never disabled when unused. Furthermore, missing password policies and trivial  naming convention applied for these accounts makes environment enumeration prior attack easy (e.g. all admin accounts start with priv or admin key word).

In MS Cloud named privileged accounts are secure if combined with Federated Identity for MFA against on-premises IdP. Problem to be solved is Single Sign-on experience lost when operator uses named privileged account for scripting and automation. In order to use Remote PowerShell for O365 systems first of all individual has to impersonate the console with own privileged account and then start the Remote PowerShell authentication flow. EXO requires additional impersonation for Internet Explorer session as the PoSH session requires valid temporary certificate that could be leased only while visiting O365 Portal.

Unnamed-privileged accounts

Privileged accounts that don’t belong to one individual could be used by more than one operator. These accounts have permanently assigned highly privileged rights in a target system. Account should be disabled and if enabled only for one individual during scheduled operations. It is very important that only one person can obtain temporary password at time. By applying TPA – Account or BG – Account processes to unnamed privileged accounts it is possible to highly improve corporate security in MS Cloud.

Unnamed accounts could be federated, however most often these are accounts authenticated directly against Microsoft Online IdP.

Having no corporate security boundaries such accounts are exposed publicly and if enabled could be leveraged by adversary to compromise the MS tenant.

E.g. external operations team worker performing privileged changes in MS tenant was asked to leave the company. Security operations team ensured that all personal accounts of this individual are immediately locked, however this person still holds password for privileged MS cloud accounts. After leaving the building the fired individual still could try to leverage privileged unnamed account if proper PAM processes are not in place.

Technical non-interactive accounts

Technical non-interactive accounts, same as unnamed privileged accounts are used by more than one individual. Such service accounts / technical identities perform routine changes in automated manner. Federation of such accounts is not possible due to lack of generic support for scheduled Remote PowerShell for O365 systems. Of course advanced developer could simulate the MFA flow within a script, however with new EXO PowerShell MFA support there is no guarantee that libraries used for establishing remote sessions are not going to be changed (note that session is established upon visiting O365 Portal).

Using permanently permissioned technical non-interactive accounts with password stored in the cloud brings loads of security issues. First is the fact that service account passwords are rarely changed due to impersonated running processes that fail if account password has changed. Furthermore such accounts are always enabled.

Again, if an employee has to leave a company having knowledge of such accounts outside could compromise entire MS tenant from outside of the company.

There is still no certificates support for EXO PowerShell and other O365 systems might have this possibility but implementation is highly customizable. Only certificate could ensure proper technical non-interactive accounts usage and enforce where you are access principle.


PAM solutions presented here are designed for “pure” Microsoft Cloud in no-Hybrid scenario. Authors recommend implementation of these services for any large organization either for on-premises or cloud-based privileged access management. All individual group assignment could be a subject for TPA despite whether the group is privileged or not. Other non-discretionary access control models (e.g. RBAC and/or ABAC) could control permanent groups and roles assignments based on business structure. Temporary memberships simplify complexity of the environment in long term as well as highly improves audit points having no unnecessary rights assigned.

Break-Glass processes should be used only for privileged access due to rather higher complexity of the implementation requiring additional abstract layer for Activator Role giving actual privileged access potential to an individual.

Only with properly selected PAM and IAM techniques MS Cloud could be considered secure on a level comparable with legacy on-premisses systems. There are additional built-in Azure features and safeguards helping to improve the overall security condition of the MS tenant, however processes described here are absent or only partially implemented in the MS Cloud.