It is recognized that privileged access and management of IT services needs particularly protection and high security policies. There are already some concepts for securing privileged access that has been proven very useful in management of an on-premises infrastructure. Some of them can be adopted to hybrid or cloud-native environments as well.

However, it seems quite common to use a browser on a productivity (standard) workstation to manage Azure or Microsoft 365 workloads. Few years ago Microsoft has designed a concept of Privileged Access Workstations (PAW) to use dedicated high-secured devices for privileged tasks only. This security approach generally seems not be applied in many cases to manage Azure resources as expected.

Scenarios and concepts for PAW or SAW (Secure Admin Workstations) in (hybrid) cloud environments are also part of my community talks about “Securing and monitoring Azure AD accounts”. I can only strongly recommended to use a PAW to separate privileged and productivity workloads. This allows you to apply a sufficient security baseline for privileged tasks on Device-/OS-level and adopt security pattern such as “clean source”-principal approach and “secure keyboard”. But there are various deployment options from physical to shielded VM-based PAWs. The choiche also depends on your rating of convenients, security and costs. More details on design approaches and implementation of SAW devices will be followed in one of my next blog posts.

The need of a fundamental concept for privileged identity management will not covered in this article and therefore it will not replaced by the following recommendation. You should ensure that all admins have a privileged account for Azure Management which is separated from “productivity” accounts (e.g. internet and mail access) or (high-privileged) on-premises admin accounts.

In this blog post I like to give you some recommendations and advices to increase your security and usability on level of browser- and identity-configuration. This can be use as part of your PAW/Admin workstation implementation or decrease the risk by using your standard (productivity) client.

Now, at that point, when I’m writing this post, some of the features are in “public preview”. Please take also in consideration that these features are not recommended to use in production (yet). This article has no claim for completeness.

Identity and device access policies

The following diagram shows recommended set of policies from Microsoft Docs. Some settings of the protection level “highly-regulated” environment can be adopted to protect your privileged accounts and devices:

image-text

Source: Microsoft Docs: Common identity and device access policies - Microsoft 365 Enterprise

Always require MFA

Every identity which can be used to manage Azure resources, Microsoft 365 services or your subscriptions (Enterprise Agreement Portal) should be (always) forced to use multi-factor authentication.

Microsoft has well documented how to create a Conditional Access policy to require MFA for administrators: Conditional Access - Require MFA for administrators | Microsoft Docs

Microsoft’s documentation described to use a list of “directory roles” as user assignment but other critical roles are not covered (e.g. Intune service Administrator is missing) in this introduction.

Consider to create (dynamic) security groups that includes all your admin accounts. This group can be used as user assignment for the “Conditional Access policies” of all privileged accounts. Further more I personally prefer to force these CA policies before a user account is eligible to request or assign the privileged role.

In addition to this you can also configure require MFA for Azure Management services for all users. Every user will be prompted for MFA if they attempt to access Azure Service Management apps such as Azure Portal.

A common policy is also documented by Microsoft to achieve this goal: Conditional Access - Require MFA for Azure management

Advice: Make sure that your admins are able to use passwordless methods as strong authentication for MFA to avoid daily use of annoying verification options such das text messages or phone calls.

Require compliant devices

Microsoft Intune can be used to identify if devices meet compliance requirements. Various Device Compliance policy settings such as requiring a PIN or operating system version can be configured in Intune. Device-compliance policies defines the requirements that devices must passed to be marked as compliant. Another baseline policy to require compliant devices is also documented in Microsoft Docs: Conditional Access - Require compliant devices.

Define your security baseline for device configuration as “device compliance policy”. This policy really depends on your needs of OS and security configuration (e.g. BitLocker encryption, OS version):
Create device compliance policies in Microsoft Intune | Microsoft Docs

Take a look on the MDM Security Baseline if you are planning to review or to rebuild your policies:
Intune security baselines settings for Windows 10 MDM | Microsoft Docs

Please keep in mind to exclude emergency or break glass accounts from these policies as I described in my previous blog post.

Identity protection risk policies

Identity protection should be applied to privileged accounts for detection of risky users. Verify that the user risk policy also includes your privileged accounts: How to configure and enable risk policies in Azure Active Directory Identity Protection | Microsoft Docs

Separated browser (user) profiles

Every privileged identity should have at minimum a separated browser profile. Create seperated profiles for each account, for example based on (staging/customer) environement or split critical role. Increase your security by level of separation: Dedicated hardware or single device with browser on virtualization or sandboxing platform.

Google’s Chrome and Edge Insider (Chromium-based) are able to manage multiple user profiles and allow sign-in option of Azure AD work accounts:

Advice: Do you like to know more about Azure AD tokens and browser cookies in Chrome and Edge (Classic)? Technical details on Azure AD WAM plug-in and how it also enables SSO on browser (by injecting the PRT) are described in this excellent PRT documentation by Microsoft: Primary Refresh Token (PRT) and Azure AD - Azure Active Directory | Microsoft Docs

Hardening of browser settings

Review your browser settings and validate some options such as:

  • Clear cookies and cache after you close the browser
  • No (3rd-party) extensions installed on profiles
  • Increased tracking prevention (Edge Insider only)
  • Disable crash report or user feedback
  • Enable Microsoft Defender SmartScreen (required extension on Google Chrome)
  • Set page layout and content to Focus (Edge Insider only)

Do not use the browser (profile) for non-privileged activities and (if possible) technically disable for preventation.

Sync browser settings (Edge Insider only)

Synchronization of user settings increase the usability but can be risky. Therefore you should limit the synchronization of browser settings to “Favorites” or “Settings” only. If you are able to manage the browser settings you should also exclude the sync of settings.

Limit risk time with Azure AD Privileged Identity Management

Azure AD Privileged Identity Management (PIM) supports you to manage just-in-time elevated access for users. Request/approval process, access reviews, alerts or auditing are just few of the features.

In my opinion PIM is not replacing the need of separated privileged accounts for users and isolation of critical roles. Therefore I can not recommended to assign privileged access to your standard users even with time-bounded access only.

There are lot of good documentations and videos about the implementation of Azure AD PIM such as the following ones:

Therefore I will not describe this part in more detail. But I would like to share a tip to handle activation of an Azure AD or Azure Resource PIM role. I myself daily use this process to activate a role without sign out and log back:

  1. Open Azure AD Portal with deep link to blade “Identity Governance” for request/activate role (bookmarked in browser):
  1. Navigate to Azure Portal (bookmarked in browser) and activated role can be used.

Tip: If you like to integrate Azure AD PIM to an existing self-service portal or create a own app (front-end): Jan Vidar Elven has written a great blog post about building an Azure AD PIM App with PowerApps and Flow using Microsoft Graph.

Sign me out when inactive (Azure Portal)

Azure Portal settings allows you to enable a “sign out” of users after specific time of inactivity. Idle timeout can be individually configured by the user. Click in the Azure Portal on the portal settings to choose the level timeout:

It is also possible to configure the inactivity timeout on tenant-level (applied to every user). Click in the portal settings on “Configure directory level timeout” to move to to this config blade:

Current users are able to override the directory level timeout for their account only. But the value must be more restrictive (allow less time) than the directory level policy it is overriding.

In case of inactivity it ensures that a user signed-out before the token expired.

Advice: Keep in mind that MCAS and other admin portals have also the option to configure auto-log out:

Non-persistent session und sign-in frequency

Microsoft has implemented session controls as option in “Conditional Access” to control sign-in frequency and persistent of browser sessions. Both settings are currently in public preview.

Sign-in frequency allows to configure refresh token lifetimes. This feature will also replace the preview of “Configure token lifetimes”. You are able to reduce the rolling windows of 90 days (by default) and asking users for credentials. This option only applies to apps with OAuth2 or OIDC authentication.

Control of persistent browser sessions allows to prevent users to choose “stay signed-in” at the Azure AD sign-in page. So the user will not remain signed in of the cloud app after closing and reopening their browser window.

The configuration of both policies are described in Microsoft Docs:
Configure authentication session management with Azure Active Directory Conditional Access | Microsoft Docs

Choose the token lifetime wisely with regard of idle timeout and activation duration of Azure AD PIM eligible roles.

Advice: I can strongly recommended to read Peter van der Woude’s detailed blog post about Sign-in frequency and persistent browser session controls.

Passwordless authentication

There is no doubt that passwordless authentication methods increase security and usability for administrators. This method also avoids to use (unsecure) MFA verification options such as phone call or text messages everyday. Microsoft has invested strongly to support passwordless options in Azure Active Directory in the recent months.

Source: Microsoft Docs: Passwordless authentication options

With a Windows device, you have the freedom to choose between built-in Windows Hello or FIDO2 security keys (such as YubiKeys) to achieve a passwordless sign-in. Security keys can be preferred if you like to separate Windows device and authentication key or using non-Windows devices.

Microsoft documented a deployment guide including comparison of the various passwordless authentication methods and technical considerations: Complete a passwordless authentication deployment with Azure AD | Microsoft Docs

In general you have the following three options to implement passwordless for your privileged accounts.

Advice: Security keys works also on macOS. In my tests Google Chrome and Edge Insider works very well.

Note: FIDO2-support is not supported on iOS and iPadOS platform (yet). So it would be great to enable the passwordless option for this scenarios as well. For example: Using Microsoft’s Azure app or portal and FIDO2 key would be very helpful in case of on-call service. Therefore I’ve posted a user voice: Adding YubiKey Support to Azure AD and Edge on iOS/iPadOS

Advice: This is also a passwordless option if you like to use virtual machines (Hyper-V with vTPM-enabled) for remote management or as “virtualized” PAW/SAW devices.

Note: Microsoft only supports biometric methods on Windows platform. Google already started to support Apple’s Touch ID sensor on macOS-Devices for authentication. I’ve posted a user voice to request for Azure AD support: Adding Touch ID Support for MFA/password-less on Chromium (macOS)


Original cover image by Geralt / Pixabay

You May Also Enjoy

Microsoft Entra Workload ID - Lifecycle Management and Operational Monitoring

22 minute read

Workload identities should be covered by lifecycle management and processes to avoid identity risks such as over-privileged permissions but also inactive (stale) accounts. Regular review of the provisioned non-human identities and permissions should be part of identity operations. In th...

Microsoft Entra Workload ID - Introduction and Delegated Permissions

15 minute read

Workload identities will be used by applications, services or cloud resources for authentication and accessing other services and resources. Especially, organizations which follows a DevOps approach and high automation principals needs to manage those identities at scale and implement p...