So you have just stood up Entra ID Domain Services (formally - or still known as of July 2023 as: Active Directory Domain Services (AAD DS)) and trying to login and join a computer to the AAD DS domain and you get the following error:

The referenced account is currently locked out and may not be logged on to.

This is commonly due to the following:

Entra ID doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Entra ID also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.

Essentially this means, that the password hashes are not comaptible with Entra ID Domain Services, and the fix is to reset the password of an Entra ID account used to access Entra ID services, to allow Entra ID Domain Services, to hash and validate the Entra ID credentials. The reset only needs to happen, if the password for the accounts haven't been reset since Entra ID Domain Services has been deployed.

After resetting the password to my Entra ID account, and waiting an hour for replication I was successfully able to login and join a Windows Server to Entra ID Domain Services.

Currently, CIS (Center for Internet Security) Azure Marketplace images, do not support being Entra ID (Azure Active Directory) Joined.

Although this article is about allowing Entra ID login to a Ubuntu machine, its worth noting the current decisions around Windows as well currently:

'The Windows CIS Benchmarks are written for Active Directory domain-joined systems using Group Policy, not standalone/workgroup systems. Adjustments/tailoring to some recommendations will be needed to maintain functionality if attempting to implement CIS hardening on standalone systems or a system running in the cloud. 'Currently, we do not support Azure Active Directory and it is not compatible with our EXISTING Hardened Images.

In fact when you, attempt to create a CIS Level 1 Ubuntu image in the Azure Portal, you get:

"This image does not support Login with Azure AD."

However, as I go into below, we can indeed login to the CIS hardened image, using the Microsoft Azure AD based SSH Login extension.

Be wary, that although this works, you may run into issues with operational support of this from CIS, due to the hardening. This is also Entra ID LOGIN (not JOINED!). You won't see the device under Entra ID Devices.

There are many security benefits of using Azure AD with SSH log in to Linux VMs in Azure, including:

1. Use of your Entra ID (Azure AD) credentials to log in to Azure Linux VMs.
2. Get SSH certificate-based authentication without needing to distribute SSH keys to users or provision SSH public keys on any Azure Linux VMs you deploy.
3. Reduce reliance on local administrator accounts, credential theft, and weak credentials.
4. Password complexity and password lifetime policies configured for Azure AD help secure Linux VMs as well.
5. With Azure role-based access control, specify who can login to a VM as a regular user or with administrator privileges. When users join or leave your team, you can update the Azure RBAC policy for the VM to grant access as appropriate. When employees leave your organization and their user account is disabled or removed from Azure AD, they no longer have access to your resources.
6. With Conditional Access, configure policies to require multi-factor authentication and/or require client device you are using to SSH be a managed device (for example: compliant device or hybrid Azure AD joined) before you can SSH to Linux VMs.
7. Use Azure deploy and audit policies to require Azure AD login for Linux VMs and to flag use of non-approved local accounts on the VMs.

So after your CIS Hardened Image, in my case I am using Ubuntu 20.04 has been deployed in Azure. Lets set this up.

You will need to make sure you have a few prerequsites.

Prerequisites​

Network​

VM network configuration must permit outbound access to the following endpoints over TCP port 443.

https://packages.microsoft.com: For package installation and upgrades. http://169.254.169.254: Azure Instance Metadata Service endpoint. https://login.microsoftonline.com: For PAM-based (pluggable authentication modules) authentication flows. https://pas.windows.net: For Azure RBAC (Role Based Access Control) flows.

Also make sure you have enabled TCP Port 80 for: ubuntu.com, specifically http://archive.ubuntu.com as the Microsoft Azure AD based SSH Login, will need to download and install the following packages: aadsshlogin and aadsshlogin-selinux as needed.

Virtual Machine​

The CIS hardened image, will need to have a System Managed Identity setup. This can be easily enabled in the Identity blade of the Virtual Machine.

The Entra ID (Azure Active Directory) users that need to login with to the Linux Virtual Machine are a member of one of the following Azure RBAC (Role Based Access Control) groups, as per their requirements:

Only one role is required. These roles are supported for both Windows and Linux.

Client​

On the jumphost, client PC you will be connecting to the Linux virtual machine from, you need the latest Azure CLI with the Azure CLI extension 'ssh' installed.

az extension add --name ssh

The minimum version required for the extension is 0.1.4.

az extension show --name ssh

Install Extension​

Make sure the Virtual Machine is on, for the extension to install.

Install using the Azure Portal​

Once the pre-requsites have been met, it is time to install the extension.

1. Login to the Azure Portal
2. Navigate to your CIS Hardened Virtual Machine
3. Click on Extensions + Applications
4. Click + Add
5. 
6. Search for: Azure AD based SSH Login
7. 
8. Select the Azure AD base SSH Login extension
9. Click Next
10. Click Review and Create
11. Click Create

After a few moments, the extension and supporting components, will be installed. You can check the status under the Extensions + Application blade make sure that Provisioning has been succeded, before provisioning to the next step to login.

Install using Terraform​

You can use the following Terraform code snippet, to install the extension to a Linux Virtual Machine:

Make sure you assign the extension, to the virtual machine, using the ID.

resource "azurerm_virtual_machine_extension" "aad_login" {
name                 = "AADLogin"
virtual_machine_id   = 
publisher            = "Microsoft.Azure.ActiveDirectory"
type                 = "AADSSHLoginForLinux" # For Windows VMs: AADLoginForWindows
type_handler_version = "1.0"                 # There may be a more recent version
}

Install using PowerShell​

To install the AADLogin extension to a Linux Virtual Machine in Microsoft Azure using PowerShell, you can follow these steps:

1. Open PowerShell on your local machine, or Azure Cloud Shell.

   Connect-AzAccount Select-AzSubscription -SubscriptionName "Your Subscription Name" $vm = Get-AzVM -ResourceGroupName "Your Resource Group Name" -Name "Your VM Name" Set-AzVMExtension -ResourceGroupName $vm.ResourceGroupName -VMName $vm.Name -Name "AADLoginForLinux" -Publisher "Microsoft.Azure.ActiveDirectory.LinuxSSH" -Type "AADLoginForLinux" -TypeHandlerVersion "1.0"

Login to Virtual Machine​

Now that the extension is stood, up its time to connect.

REMEMBER to make sure that the Entra ID (AAD) accounts you want to login to the Linux image is a member of either of the following roles, directly assigned to the Virtual Machine/Resource Group, or in an Entra ID (AAD) group that has been delegated the permissions.

1. Open a Command Prompt
2. Log in to the Azure using: az login
3. A web browser will prompt and ask you to authenticate, where you will go through the MFA (Multifactor Authentication) and complete login to your Entra ID account.
4. Once authenicated you can run: az ssh vm -n cistest -g cistest Note: -n is the VM name and -g is the Resource Group, that the VM is located inside.

You should now have successfully authenticated to your Linux virtual machine using Entra ID credendials.

Troubleshooting​

If you are unable to connect, it may be due to an issue with the AADSSHLogin extension. You can troubleshoot by reviewing the extension log.

cat /var/log/azure/Microsoft.Azure.ActiveDirectory.AADSSHLoginForLinux/CommandExecution.log

The Azure directory is protected, so you will need Administrator rights to delve into the logs.

By default, when a Management Group gets created, it goes under the Root Management Group, the same is true for Subscriptions.

This works fine, when you have a simple Microsoft Azure environment, but as soon as you start expanding into areas such as Subscription vending or limited access to who can see the Root Management Group and start to look into Visual Studio Enterprise subscriptions, you may want to consider moving new subscriptions, under its own Management Group, away from any policies or RBAC controls, essentially into a Management Group that acts as a shopping cart, to then be picked up and moved later.

If we refer to a recommendation on the Microsoft Cloud Adoption Framework:

Configure a default, dedicated management group for new subscriptions. This group ensures that no subscriptions are placed under the root management group. This group is especially important if there are users eligible for Microsoft Developer Network (MSDN) or Visual Studio benefits and subscriptions. A good candidate for this type of management group is a sandbox management group.

So, how can we change the default Management Group, that new Subscriptions go into?

Lets take a look at the different ways we could use to update the default management group, that new subscriptions go into.

Configure using Azure Portal​

1. Use the search bar to search for and select 'Management groups'.
2. On the root management group, select details next to the name of the management group.
3. Under Settings, select Hierarchy settings.
4. Select the Change default management group button.

Configuring using Bicep​

resource symbolicname 'Microsoft.Management/managementGroups/settings@2021-04-01' = {
name: 'default'
parent: resourceSymbolicName
properties: {
defaultManagementGroup: 'string'
requireAuthorizationForGroupCreation: bool
}
}

Reference: Microsoft.Management managementGroups/settings

Configure using REST API using PowerShell​

$root_management_group_id = "Enter the ID of root management group"
$default_management_group_id = "Enter the ID of default management group (or use the same ID of the root management group)"
$body = '{
 "properties": {
      "defaultManagementGroup": "/providers/Microsoft.Management/managementGroups/' + $default_management_group_id + '",
      "requireAuthorizationForGroupCreation": true
 }
}'
$token = (Get-AzAccessToken).Token
$headers = @{"Authorization"= "Bearer $token"; "Content-Type"= "application/json"}
$uri = "https://management.azure.com/providers/Microsoft.Management/managementGroups/$root_management_group_id/settings/default?api-version=2021-04-01"
Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body

Configure using Terraform​

resource "azurerm_management_group_subscription_association" "example" {
management_group_id = data.azurerm_management_group.example.id
subscription_id     = data.azurerm_subscription.example.id
}

Note: Not quite the same, as configuring the default setting as above - but you can specify the Managament Group association for subscriptions using Terraform.

When attempting to use aztfexport, a tool designed to export currently deployed Azure resources into HashiCorp Configuration Language (HCL) for use with Terraform, you may get: Access denied.

When using aztfexport, the first thing you need to do is make sure you have the Azure CLI installed, and run an:

az login

After logging in, you need to verify you are on the right subscription, by running:

az account show

If you are on the right subscription, you don't need to do anything. If you are in the wrong subscription then run:

az account list

Find the susbcription ID then use:

az account set --subscription <name or id>

You only need Reader rights to be able to export the Terraform configuration.

If you find you are still running into access denied issues, such as below:

And you are running the aztfexport program on an Azure Virtual Machine, such as Azure Virtual Desktop or Devbox, what is happening is the Managed Identity permissions of your Azure Virtual Machine is overriding your own permissions you used to login to Azure using the CLI.

To get around this, you either have to run aztfexport locally, on a device thats not an Azure Virtual Machine, or supply the Managed Identity of the Virtual Machine, Reader rights to the subscription you wish to do the export from.

You can do this, by navigating to your Azure Virtual Machine, in the Azure Portal, click on the Virtual Machine, select Identity, select Azure role assignments and grant it Reader rights to the Resource Group or Subscription you are targeting.

You could try Disabling the System Assigned Managed Identity as well, which appeared to work for me.

For more information about this error, please refer to the following Github issue: Access Denied during xport on Azure Virtual Desktop.

I was assisting a user on Microsoft Q&A with an issue, that involved looking over some event logs.

The issue itself was related to the Nested Virtualization, with the user unable to install Hyper-V or WSL (Windows Subsystem for Linux), it turned out to be incompatilibies with the SKU size and Secure boot.

But as part of troubleshooting this issue, I recreated the Azure compute environment, this user had and started to delve into the Windows logs.

However, in this case I did something a bit different, I exported the logs as text file and opened up Azure OpenAI, then navigated to Azure OpenAI Studio, clicked on Completion and used the summarization powers of the GPT 3.5 Large language model, to delve into the logs for me:

Copying, the Log into the Completion pane of Azure OpenAI

And using the Prompt of:

----
Summarize all the errors and warnings from above and sort by potential cause of the issues, with the most likely cause first. Format as a table.

Azure OpenAI was able to use the reasoning ability of the GPT 3.5 LLM (Large language Model) to sort through 115 lines of Logs, and work out the probability of what could be causing the root cause of the issue.

As you can see, Azure OpenAI and the LLMs can not just be used as an assistant in writing, studying it can be learned to assist in Incident and root-cause resolution.