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.

SQL Server Native Client version warning in the SCCM prerequisite check

When running the prerequisite check before upgrading SCCM to the newest releases you might see the following warning (this is taken from 1812):