Category Archives: Azure

Inside Azure datacenter architecture with Mark Russinovich – BRK3347

A tour of Windows Virtual Desktop – THR2302

Windows Admin Center: Hyper-V Live Migration, PerfMon & deeper Azure integration. (Microsoft Ignite)

Microsoft 365 admin updates | User templates, Global Reader role. (Microsoft Ignite)

Real life hacks for Windows and Office… and how to stop them (Microsoft Ignite)

Windows Virtual Desktop | upcoming admin experience + recent updates (Microsoft Ignite)

Azure AD Password Protection is now generally available

We’ve talked about this Azure AD feature a few months ago, when it was in Public Preview, you can take a look at the article here: https://systemplus.gr/azuread-password-protection-and-smart-lockout-are-now-in-public-preview/

Something that was not so clear and it needs to be, is the fact that it’s not only a cloud solution: it can be used even on on-premises environments, meaning that you can use it on your Domain Controllers. Simply create a banned password list and that’s all! Keep in mind that it’s not only the banned password list that you create the one that is being used: Microsoft has the proper algorithms and their own banned passwords lists that are also used in your password policy.

You should start configuring it by navigating to Azure Active Directory node in the Azure portal and then select Authentication Methods:

image

 

How to protect your on-premises environment

To use Azure AD Password Protection on our Windows Server Active Directory, download the agents from the download center and use the instructions in the Password Protection deployment guide.

Specifically, you need to deploy Azure AD Password Protection in audit mode, just to monitor the impact of your password policy to your users. Later you should change the mode to Enforce.

In a single-forest deployment, the following diagram shows how it works and the various components that you’ll need:

azure-ad-password-protection

 

Read-only domain controllers

Password changes/sets are not processed and persisted on read-only domain controllers (RODCs). They are forwarded to writable domain controllers. So, you don’t have to install the DC Agent software on RODCs.

 

Deployment requirements

  • All domain controllers that get the DC Agent service for Azure AD password protection installed must run Windows Server 2012 or later. This requirement does not imply that the Active Directory domain or forest must also be at Windows Server 2012 domain or forest functional level. There is no minimum DFL or FFL required for either the DC agent or proxy software to run.

  • All machines that get the DC agent service installed must have .NET 4.5 installed.

  • All machines that get the proxy service for Azure AD password protection installed must run Windows Server 2012 R2 or later.

  • All machines where the Azure AD Password Protection Proxy service will be installed must have .NET 4.7 installed. .NET 4.7 should already be installed on a fully updated Windows Server.

  • All machines, including domain controllers, that get Azure AD password protection components installed must have the Universal C Runtime installed. You can get the runtime by making sure you have all updates from Windows Update, see Update for Universal C Runtime in Windows.

  • Network connectivity must exist between at least one domain controller in each domain and at least one server that hosts the proxy service for password protection. This connectivity must allow the domain controller to access RPC endpoint mapper port 135 and the RPC server port on the proxy service. By default, the RPC server port is a dynamic RPC port, but it can be configured to use a static port.

  • All machines that host the proxy service must have network access to the following endpoints:

    Endpoints
    https://login.microsoftonline.com
    https://enterpriseregistration.windows.net

  • All machines that host the proxy service for password protection must be configured to allow outbound TLS 1.2 HTTP traffic.

  • A Global Administrator account to register the proxy service for password protection and forest with Azure AD.

  • An account that has Active Directory domain administrator privileges in the forest root domain to register the Windows Server Active Directory forest with Azure AD.

  • Any Active Directory domain that runs the DC Agent service software must use Distributed File System Replication (DFSR) for SysVol replication.

  • The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows Server 2012. By default, this service is enabled via manual trigger start.

 

(The deployment requirements are just a copy of the official deployment document by Microsoft, just to give you a general idea of the components that you’ll need. There are a lot of additional steps that you need to perform, so I strongly recommend to check the documentation here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy)

 

Thanks for your time!

Azure AD B2C custom policies to build-your-own identity methods is in general availability

A few days ago the Azure AD product group has announced the general availability of the Identity Experience Framework and custom policy support in Azure Active Directory B2C. That really means that you can use your own identity frameworks to use the identity technology of your choice and interoperate with multiple identity providers.

With the release of custom policies in Azure Active Directory B2C you can now customize your identity experience for clients and partners. Do not forget to take a look at this article here: Get started with custom policies in Azure Active Directory B2C

There is also an upcoming webinar that you cannot miss it, Sign up for the webinar on April 18th: Connect more effectively with customers using Azure Active Directory B2C.

There have been many customers and partners that already use today Azure AD B2C and one of them is Subway, a leading restaurant in the US and elsewhere. They managed to migrate their customers seamlessly without changing passwords from an old, identity solution into Azure Active Directory B2C. By upgrading customer identity, Subway customers can connect through their mobile native application and take better advantage of their loyalty program:

subway_mobile_app

 

This new technology is a Microsoft-patented technology called the Identity Experience Framework. Some of the features that are included are:

  • Author and upload your own user identity journey using custom policies.
  • Federate with OpenIDConnect (e.g. Azure Active Directory multitenant, social account providers, two-factor authentication providers).
  • Federate with SAML 2.0 providers (e.g. ADFS, Salesforce, Shibboleth).

identity-experience-framework

The best way to get familiarized is to take a look here Solutions and Training for Azure Active Directory B2C page and start using it today.

 

Thanks for your time!

Azure AD Naming Policy for Office 365 Groups is now available

Another cool Azure AD feature was announced these days: we now have the ability to enforce a Naming Policy for Office 365 Groups. That new Naming Policy feature enables admins to define prefix or suffix conventions that can be automatically appended to group names and create a list of words that are blocked from use in group names. Please keep in mind that you’ll need Azure AD Premium 1 licenses for the users that will belong to these groups, the group creator and the Naming Policy administrator.

One of the obvious things that you can do with a Naming Policy could be to block specific words from being used in group names and aliases, or even create groups having names that declare the function of a group, membership, or even the geographic region that a group belongs.

How it works

You can enforce naming policy for Office 365 groups in two different ways:

  • Prefix-suffix naming policy You can define prefixes or suffixes that are then added automatically to enforce a naming convention on your groups (for example, in the group name “GRP_Athens_Accounting”, GRP_Athens_ is the prefix, and _Accounting is the suffix).

  • Custom blocked words You can upload a set of blocked words specific to your organization to be blocked in groups created by users (for example, “CEO, Payroll, HR”).

 

Install PowerShell cmdlets to configure a naming policy

Make sure to uninstall any older version of the Azure Active Directory PowerShell for Graph Module for Windows PowerShell and install Azure Active Directory PowerShell for Graph – Public Preview Release 2.0.0.137

Then:

  • Open the Windows PowerShell app as an administrator.
  • Uninstall any previous version of AzureADPreview by running: Uninstall-Module AzureADPreview
  • Install the latest version of AzureADPreview by running: Install-Module AzureADPreview
  • Reply Y to the next question and wait for a few minutes to get installed.

 

How to configure the group naming policy for a tenant using Azure AD PowerShell

 

This is an example of how you can import blocked words from a text file that you don’t want them to be used in group names:

$BadWords = Get-Content «C:\work\currentblockedwordslist.txt»

$BadWords = [string]::join(«,», $BadWords)

$Settings = Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq «Group.Unified»}

if ($Settings.Count -eq 0)

{$Template = Get-AzureADDirectorySettingTemplate | Where-Object {$_.DisplayName -eq «Group.Unified»}

$Settings = $Template.CreateDirectorySetting() New-AzureADDirectorySetting -DirectorySetting $Settings

$Settings = Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq «Group.Unified»}}

$Settings[«CustomBlockedWordsList»] = $BadWords

$Settings[«EnableMSStandardBlockedWords»] = $True Set-AzureADDirectorySetting -Id $Settings.Id -DirectorySetting $Settings

 

For a full documentation please take a look here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-naming-policy

 

Thanks for your time!

You can now collaborate using Azure AD and login with any account

Azure AD B2B Collaboration gives you the ability to collaborate with other organizations and people, even if they do not use Azure AD. The Azure AD Team recently improved the way that an external company can authenticate to your Azure AD using Google IDs. So, even if your external partners use Gmail accounts, you can successfully share to them apps and resources, without asking them to use Microsoft accounts. Actually it is Google the first identity provider that Azure AD supports.

If you want to read more about how GMail accounts are supported, you can take a look at this article.

So today we have another announcement, the ability to use OTPs (one-time passwords) for your external partners, making B2B collaboration really easy with anyone that has an email account.

By using email OTP, anyone who doesn’t have a Microsoft or Google account can access shared resources, without the need to create a new account just for this. They can still use their existing account to login to Azure AD and receive an OTP code via email. This code will be used during the authentication process. And if you really need it, you can integrate and use Conditional Access and MFA.

Let’s take a look at how it works:

OTP 1.png

Since we want the whole process to be really secure, remember that each authenticated session lasts for 24 hours, then you have to re-authenticate using a new OTP code. This means that external users need to verify again that they have access to the email address that they used the first time.

This is what your external users will get when they authenticate:

OTP 2.png

As soon as they receive the OTP code via email, they have to use it:

OTP 3.png

Do you need to know more? Take a look at the official documentation here.

 

Thanks for your time!