Setting up Ansible control node for managing Linux and Windows hosts

Background

In this post, I will walk you through the complete end-to-end procedure for setting up an Ansible controller node and setting up the connection for managing RHEL and Windows Server nodes.

Azure setup

I have created 3 servers and placed them in a simple network configuration.

Infra:

    10.0.3.4 ansiblecontrol (RHEL 8.7)

App:

    10.0.5.4 linuxnode1 (RHEL 8.7)

    10.0.5.5 windowsnode1 (Windows Server 2019)

OS preparation

Ensure all hosts are configured with the correct FQDN and IP configurations. This is more so important when dealing with domain-joined nodes.

ex:

• run hostnamectl set-hostname ansiblecontrol.local.vanguard.com to set the hostname for RHEL
• add DNS suffix to computer name on System Settings on Windows Server

Make sure the control node can reach the managed nodes in the absence of DNS by adding entries in /etc/hosts

Setting up Ansible on Control node

1. Install ansible sudo yum install ansible

     2. Generate SSH key pair for ansible user ssh-keygen

     3. Copy public key to linuxnode1 ssh-copy-id linuxnode1.local.vanguard.com

     4. Install pywinrm for managing Windows nodes pip3 install "pywinrm>=0.3.0"

     5. Import windows module collection ansible-galaxy collection install ansible.windows

Setting up Linux managed node

1. Add ansible user on linuxnode1 sudo useradd ansible
2. Add ansible user in the sudoers file for password-less authentication for all elevated commands using sudo visudo

Setting up Windows managed node

     1. Ensure PowerShell version is 5.0 and above using $PSVersionTable command. Also make sure .NET version is later than 4.0. However, with newer Windows Servers, this shouldnt be an issue.

    2. Set up WinRM listener on port 5986 for HTTPS transport. This requires the creation of a self-signed certificate. Ansible has provided a script for this task which is available to download on GitHub

    2. Additionally, make sure Windows Firewall is switched off

Sample Ansible directory setup

1. Create inventory file by grouping the 2 managed nodes by operating system

    2. Define group_vars.

        Create a new file called windows.yml in group_vars. The contents of the file defines the connection parameters that will be used by ansible to connect with hosts under the windows group of the inventory file. This will also work for any dynamic inventory as long as those hosts are also added to the windows group during playbook runtime.

         

        For domain-joined windows servers, it is advised to use the more secure kerberos instead of ntlm. In such cases, kerberos packages must be installed and krb5.conf configured on the ansible control node to obtain kerberos tickets from the AD domain.

    3. Encrypt windows group_vars using ansible-vault to protect sensitive information

        ansible-vault encrypt windows.yml

    

    4. Perform a ping to verify connectivity using ad-hoc ping command. Make sure to use --ask-vault-pass for windows nodes

Sample playbook

 1. The following playbook will install webserver on both nodes depending on their OS

2. Execute the playbook first by doing a dry-run

ansible-playbook installwebserver.yml -i testservers --check --ask-vault-pass

3. Run the playbook

ansible-playbook installwebserver.yml -i testservers --ask-vault-pass

Password sync issues between AD and Entra ID - ‘User must change password at next logon’

Background

You want to reset a user's password in an Entra ID-connected Active Directory environment.

Issue

In Active Directory Users and Computers, you reset a user's password by making sure 'User must change password at next login' is selected.

The password was reset successfully. However, after allowing enough time for the Entra Connect sync, the user cannot authenticate with the new password on M365 and/or the company portal. The error message indicates an incorrect password.

Troubleshooting steps

In the Entra ID admin portal, the password for the same user is reset, enabling successful authentication into web-based services, with the updated password also reflected in Active Directory.

It appeared that the password hash sync only works from Entra to AD, not the other way around.

If the ‘User must change password at next logon’ flag was deselected when the password was reset, it would work across both Entra and AD.

Conclusion

The ‘User must change password at next logon’ flag will not sync with Entra unless the ForcePasswordChangeOnLogOn feature is enabled on the Entra ID tenant (see below).

Implement password hash synchronization with Microsoft Entra Connect Sync - Microsoft Entra ID

If the option ‘User must change password at next logon’ is selected in Active Directory, but that feature is not enabled in Entra ID, password changes will not be synced (see below).

azure-content/articles/active-directory/active-directory-aadconnectsync-implement-password-synchronization.md at master · toddkitta/azure-content

As a workaround, 'User must change password at next logon’ was deselected during password reset until changes were made to the Entra ID tenant.

How to change existing Azure VM from security type Trusted to Standard in order to enable nested virtualisation capabilities

Background

It is not possible to change the security type of an existing Azure VM back to standard. The only known way to achieve this is to setup a new standard VM and attaching the old OS disk to it.

This process appears to be suitable for domain joined production environments as well, however, it may depend on the complexities of your own environment.

Steps

1. Stop the target VM.


2. Export the current OS disk as VHD. Run the following script in cloud shell bash.

#Provide the subscription Id where managed disk is created

subscriptionId="your sub ID"

#Provide the name of your resource group where managed disk is created

resourceGroupName="rg name"

#Provide the managed disk name

diskName="current OS disk"

#Provide Shared Access Signature (SAS) expiry duration in seconds e.g. 3600.

#Know more about SAS here: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-signature-part-1

sasExpiryDuration=3600

#Provide storage account name where you want to copy the underlying VHD file of the managed disk.

storageAccountName="sa name"

#Name of the storage container where the downloaded VHD will be stored

storageContainerName="blob container for storing disks"

#Provide the key of the storage account where you want to copy the VHD

storageAccountKey="sa key"

#Provide the name of the destination VHD file to which the VHD of the managed disk will be copied.

destinationVHDFileName="name of VHD"

az account set --subscription $subscriptionId

sas=$(az disk grant-access --resource-group $resourceGroupName --name $diskName --duration-in-seconds $sasExpiryDuration --query [accessSas] -o tsv)

az storage blob copy start --destination-blob $destinationVHDFileName --destination-container $storageContainerName --account-name $storageAccountName --account-key $storageAccountKey --source-uri $sas

3. Create managed disk from the exported VHD by running the following script in PowerShell Cloud Shell.

    Make sure HyperVGeneration and Zone match the new VM that will be created in the next step.

#Provide the subscription Id

$subscriptionId = 'your sub ID'

#Provide the name of your resource group

$resourceGroupName ='rg name'

#Provide the name of the Managed Disk

$diskName = 'name of VHD'

#Provide the size of the disks in GB. It should be greater than the VHD file size.

$diskSize = '127'

#Provide the URI of the VHD file that will be used to create Managed Disk.

# VHD file can be deleted as soon as Managed Disk is created.

# e.g. https://contosostorageaccount1.blob.core.windows.net/vhds/contoso-um-vm120170302230408.vhd

$vhdUri = 'https://<your sa>.blob.core.windows.net/<container name>/VHDfilename.vhd'

#Provide the resource Id of the storage account where VHD file is stored.

#e.g. /subscriptions/6472s1g8-h217-446b-b509-314e17e1efb0/resourceGroups/MDDemo/providers/Microsoft.Storage/storageAccounts/contosostorageaccount

$storageAccountId = '/subscriptions/<your sub id>/resourceGroups/<rg name>/providers/Microsoft.Storage/storageAccounts/<sa name>'

#Provide the storage type for the Managed Disk. PremiumLRS or StandardLRS.

$sku = 'StandardSSD_LRS'

#Provide the Azure location (e.g. westus) where Managed Disk will be located.

#The location should be same as the location of the storage account where VHD file is stored.

#Get all the Azure location using command below:

#Get-AzureRmLocation

$location = 'your location'

#Set the context to the subscription Id where Managed Disk will be created

Set-AzContext -Subscription $subscriptionId

#If you're creating an OS disk, add the following lines

#Acceptable values are either Windows or Linux

#$OSType = 'yourOSType'

#Acceptable values are either V1 or V2

#$HyperVGeneration = 'yourHyperVGen'

#Specify Zone

#Zone = 1

#If you're creating an OS disk, add -HyperVGeneration and -OSType parameters

$diskConfig = New-AzDiskConfig -SkuName $sku -Location $location -DiskSizeGB $diskSize -SourceUri $vhdUri -StorageAccountId $storageAccountId -Zone 2 -OsType Windows -HyperVGeneration "v2" -CreateOption Import

#Create Managed disk

New-AzDisk -DiskName $diskName -Disk $diskConfig -ResourceGroupName $resourceGroupName

4. Delete current VM while retaining OS Disk (just in case). 

    Make sure new VM uses dsv4 series of Azure VMs that support nested virtualisation.

    https://learn.microsoft.com/en-us/azure/virtual-machines/ddv4-ddsv4-series#ddsv4-series

5. Go to the new VM -> Disks, and choose Swap OS Disk. Choose the managed disk created in step 3.

    

6. Re-assign IP on the new NIC on Azure

7. Start new VM and connect using local administrator account

    After this step, OS disk provisioned along with new VM can be deleted.

8. Remove old and hidden NICs in Device Manager (Select Show hidden devices under View menu)

9. Edit Ethernet adapter by re-assigning IP along with default gateway and DNS server

You should now be able to install Hyper-V role on your Azure VM