Azure Privileged Identity Management - Part 1

Administrating resources and services in a company has always been a challenge and most companies struggle with assigning the right level of access. On one hand administrative privileges are needed to ensure productivity and implementation of new services, while on the other hand these privileges are under attack from adversaries.

One solution is highly privileged administrators, which will ensure that implementing new services runs smooth but leaves the company vulnerable to identity-theft attacks against the administrative accounts that can give immediate access to privileged resources.

Password-less phone sign-in with the Microsoft Authenticator app

In two of the latest we tested Azure Self-service password reset and integrated the feature with Windows 10:

This time let’s use the same user, and enable it to use Password-less phone sign-in with the Microsoft Authenticator app.

This feature is in public preview and you need to be aware of a couple of known issues :

Azure AD Password Protection

We now have Azure AD Password Protection generally available, this will allow us to eliminate easily guessed passwords. By using it we can lower the risk of password spray attacks.

Password spraying is using a large number of usernames and loops them with a single password, this will give a low number of passwords attempted. This method can avoid password lockouts, and is often effective uncovering weak passwords.

So no reason not to implement Azure AD Password Protection, if you have the license.

Conditional Access

Securing cloud services against attacks requires a strong focus on identities. This is because cloud services, normally, is available from anywhere and access is often based on the login only.

To address this threat, it is possible to implement extra layers to the login process, like Multi Factor Authentication. This effectively raises security but unfortunately lowers usability, which again leads to users turning to 3rd party services – not under corporate control.

To accommodate this concern, Microsoft has implemented Azure Active Directory Conditional Access in their identity stack. With Conditional Access it is possible to reach a high level of security, with very little impact on users.

Conditional Access uses properties received from Azure AD during login and evaluates these against a set of conditions, to determine which access controls should be applied to a users login.
See flow in figure 1.

Azure AD Password Reset on login screen

In one of the last posts we enabled SSPR in our hybrid environment.

This time let’s enable password reset on the Windows 10 clients login screen.

Before we start we need to be aware of the following:

  • Supported on Windows 10, version April 2018 Update (1803).

  • Device must be Azure AD-joined or Hybrid Azure AD-joined.

  • Azure AD self-service password reset must be setup and configured.

  • If proxy is used you must add and to your HTTPS traffic (port 443) Allowed URLs list.

  • Not supported on a Remote Desktop (see info on Hyper-V later).

  • There are know issues if Ctrl+Alt+Del is required at logon (before 1809).

  • If lock screen notifications are turned off, SSRP will not work.

Essentially what we need on the client is just a registry key set:


This can of course be done in multiple ways like Intune and SCCM, but for this test let’s use old school  Group Policy Preferences.

Azure AD Naming Policy for Office 365 Groups

We can now enforce a Naming Policy for Office 365 Groups, lets give it a test drive.

With the Naming Policy feature we can define prefix or suffix that can be automatically added to group names and at the same time we can define words that are blocked from use in group names.

Note that Azure AD P1 license is required for the group creator, the group members, and the Naming Policy admin.

Setup is done by PowerShell and you need the Public Preview release of Azure Active Directory V2 PowerShell Module to be at least on version

You can verify your  current version with the commands:

Azure Multi Factor Authentication

Identity as a security perimeter

When using services available from anywhere, like cloud services, the security risk associated with user credentials increases drastically. In an on-premise infrastructure, companies are protected by the physical perimeter and attackers are forced to either physically connect to the on-premises network or overcome obstacles like firewalls. But when it comes to cloud-based services, attacks can be performed from outside the company’s perimeter, lowering the risk for the attacker.

This fact means that companies thinking about moving parts of their services or infrastructure to the cloud, needs to increase focus on user credentials and authentication mechanisms. We believe that one of the first considerations should concern the implementation of 2 factor authentication.

Azure Active Directory (Azure AD) self-service password reset (SSPR)

This time let’s try out SSPR with the new MFA combined registration in a hybrid environment.

Before passwords can be changed on our local AD, Azure AD Connect must be configured with password writeback.

Self-Service Password Reset/Change/Unlock with on-premises writeback is a premium feature of Azure AD, so license is required, it could be Azure AD Premium P1/P2, Enterprise Mobility + Security or Microsoft 365.

So here we go, let’s configure Azure Active Directory Connect.

Azure KMS Server

You might find yourself in a situation where you want all your computers to activate using Active Directory based activation except for your Azure VM’s, they should use the Azure KMS server.

By default, when Active Directory based activation is enabled all computers on your domain will use Active Directory based activation.

By using the command cscript c:\Windows\system32\slmgr.vbs /dlv we can see that this host has been activated by AD activation:

Windows Defender Application Guard – Settings

Let take one more look at the Windows Defender Application Guard.

You can find the previous posts about WDAG here:

Testing Windows Defender Application Guard on a VM

Windows Defender Application Guard

In the last post we saw that by default we were not allowed to do copy and paste operations

Your admin doesn’t allow you to copy and paste this content between Application Guard and other apps.

Windows Defender Application Guard

This time let’s give Windows Defender Application Guard a very simple test:

You can test this on a physical client or a Hyper-v client, take a look here for the requirements:

Testing Windows Defender Application Guard on a VM

The test will be done in an enterprise Active Directory domain (Enterprise-managed mode).

First lets create a Group policy (GPO) for Windows Defender Application Guard and apply it to the OU holding our clients.

Go to the following setting:

Computer Configuration\Policies\Administrative Templates\Network\Network Isolation\Enterprise resource domains hosted in the cloud

In the Enterprise cloud resources you can enter a pipe-separated (|) list of domain cloud resources (Trusted domains).

The domains you enter here will be rendered using Microsoft Edge (or Internet Explorer) and won't be accessible from the Application Guard environment.

You can use a leading "." as a wildcard character to trust subdomains. Configuring will automatically trust and etc.

Testing Windows Defender Application Guard on a VM

If you want to test Windows Defender Application Guard your test environment must meet the requirements:

A 64-bit computer with minimum 4 cores (logical processors) with CPU virtualization extension, minimum 8GB RAM and 5 GB free space.

But what if we want to test this on a virtual Windows 10 running on Hyper-v?

When you try to enable Windows Defender Application Guard you might see warnings like these.

Windows Defender Application Guard cannot be installed: The Processor does not have required virtualization capabilities:

Office Client Policy Service

Microsoft has made the new Office Client Policy Service available as preview, and this is looking promising.

The solution is a cloud-based service that can enforce policy settings for Office 365 ProPlus on the office client. This is possible even if the device isn’t domain joined or otherwise managed.

The policy settings will be applied to whichever device the user signs into and uses Office 365 ProPlus. The solution includes many of the same user-based policy settings that are available when using Group Policy (GPO).

We need to be aware of the following:

Enterprise State Roaming

This time I will have a quick test-drive of the Enterprise State Roaming Feature (ESR) with a hybrid Azure AD joined device, for those of us still using our own AD.

Enterprise State Roaming will offer a secure synchronization of user settings from Windows and applications to the cloud.

You can think of it as the modern roaming profiles, but it will not roam existing Windows desktop apps (Win32 apps), in order to roam these settings we need UE-V (preferred before the old roaming profile).

We also need to be aware that Enterprise State Roaming only is available with an Azure AD Premium or Enterprise Mobility + Security (EMS) license.

Azure PowerShell Az module

Starting in December 2018, the Azure PowerShell Az module is in general release and now the intended PowerShell module for interacting with Azure. Az offers shorter commands, improved stability, and cross-platform support. Az also offers feature parity and an easy migration path from AzureRM.