Friday, October 9, 2020

Join a VM to an active directory domain in Azure with PowerShell

 At current client we have a hybrid setup with an on-prem datacenter and VPN connections to Azure. The on-prem active directory has been extended to Azure with an additional two domain controllers (classic active directory).

We have a generic virtual machine deployment template in PowerShell and want to be able to have VMs automatically join the domain as part of the deployment process.

A first learning is to make sure that the IP addresses of the DC's are specified as custom DNS servers on the VNets where they reside (assuming they also function as DNS servers). Otherwise, the VMs won't be able to resolve the domain (VNet -> DNS servers -> Custom).

Up front we have verified that a VM can be manually joined to the domain from the VM itself.

The PowerShell command for setting the domain is: Set-AzVMADDomainExtension

The MS documentation is not very thoroughly described for this command, unfortunately.

We got pretty far using this guide instead.

When using that example and trying jo join, the PowerShell script kept hanging and timing out. From the VM itself in the event log, it just stated NetJoin action failed. But no helpful error description.

We had to adjust two things to make it work:

1. For the JoinOption parameter, instead of using 0x00000001, we used 0x00000003 (which is similar to setting 0x00000001 and 0x00000002). This specifies joining a domain instead only a workgroup (option 1) and option 2 creates an account on the domain.

2. By using the Invoke-AzVMRunCommand command we set the DNS suffix from inside the VM using PowerShell before running the domain join command.

This works in our setup. The code examples can be seen below (first script calls the second script). It can be added to an existing VM deployment script or be run as a standalone script post VM install.

Join domain

# Update variables
$VMName = "XXVMname"
$ResourceGroupName = "XX-RGname"

# Do not update these variables
$DomainName = "XXdomainname.local"
$ServiceAcct = "XXdomainname\XXserviceaccountname"
$secretnameDomain = "XXnameofsecretinKeyVault"
$JoinOpt = "0x00000003" # specifies the options to join a domain, 0x00000001 + 0x00000002
$OU = "OU=XX,OU=XX,DC=XX,DC=Local" # Update string with corrrect OU path (not a requirement)
$kvname = "XXnameofKeyVault"
$LocationName = "westeurope"
$ScriptPathDNSsuffix = ".\SetDnsSuffixInVM.ps1"

Write-Host "Set DNS suffix in VM. $(Get-Date)"
# Set DNS suffix in VM (for domain join to work)
Invoke-AzVMRunCommand -ResourceGroupName $ResourceGroupName `
 -VMName $VMName `
 -CommandId 'RunPowerShellScript' `
 -ScriptPath $ScriptPathDNSsuffix

# Get service account password from key vault
$ServiceAcctPassword = (Get-AzKeyVaultSecret -vaultName $kvname -name $secretnameDomain).SecretValueText | ConvertTo-SecureString -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential ($ServiceAcct, $ServiceAcctPassword);

Write-Host "Joining domain $DomainName. $(Get-Date)"
Set-AzVMADDomainExtension -DomainName $DomainName `
 -VMName $VMName `
 -ResourceGroupName $ResourceGroupName `
 -Location $LocationName `
 -Credential $Credential `
 -OUPath $OU `
 -JoinOption $JoinOpt `
 -Restart `
 -Verbose
Write-Host "Script done at $(Get-Date)"

Set DNS Suffix in VM (SetDnsSuffixInVM.ps1)

$DnsSuffix = "XXDomainname.local"

$interfacealias = get-dnsclient | Where-Object {$_.InterfaceAlias -eq "Ethernet"}
set-dnsclient -Interfaceindex $interfacealias.Interfaceindex `
-ConnectionSpecificSuffix $DnsSuffix `
-RegisterThisConnectionsAddress $True


Thursday, October 1, 2020

Azure: Allowing Windows Server to activate via KMS through Azure Firewall

 At current client we have an Azure Firewall installed. And only outbound traffic on ports 80 and 443 is allowed. Today we found that Windows Servers do not activate (we're buying the licenses per Windows Server). 

The reason for this is that the VMs can't reach the KMS server for Azure Global cloud:

Azure Global KMS: kms.core.windows.net  - IP: 23.102.135.246 on port 1688. See here for more info. 

(I found a general activation troubleshooting guide here where they recommend testing with PsPing. I didn't get around to trying that, but it might be useful.)

I tried adding a network rule in the Azure Firewall using the FQDN, kms.core.windows.net. That failed.

But adding a rule using the IP address in stead worked fine (and that looks to be 'allowed' as well by MS).

The following rule was added in Azure Firewall via PowerShell:

 # Allow VMs to reach kms.core.windows.net for Windows Server activation
 $NetRule2 = New-AzFirewallNetworkRule -Name "allow-kms" -Protocol TCP,UDP -SourceAddress `
  "10.1.1.0/24", `
  "10.1.2.0/24" `
 -DestinationAddress "23.102.135.246" -DestinationPort "1688"

And remember to add the rule variable as well to the New-AzFirewallNetworkRuleCollection cmdlet:

$NetRuleCollection = New-AzFirewallNetworkRuleCollection -Name 'fw-rule-collection' -Priority 200 `
   -Rule $NetRule1,$NetRule2 -ActionType "Allow"

When done, I RDP'ed to a VM and went to activation. It wasn't activated. I clicked on troubleshoot and the VM activated. Likely after a while all VMs will activate automatically.




Azure: Create an availability set with two VMs with PowerShell

If you have two or more virtual machines in Azure running in a pair or a cluster (for example domain controllers), you want to make sure that the proper redundancy is in place. Both in regards to separating VMs between datacenters and making sure that during maintenance that MS will not reboot your VMs at the same time. This can be done by creating an availability set which places VMs into availability zones.

An availability zone is the combination of a fault domain (which is a separate physical datacenter within a given region such as West Europe) and an update domain (the underlying hardware 'group', likely the hypervisor. This is to avoid VMs freezing or being rebooted at the same time during a Azure update which can happen on rare occasions according to MS).

The order in which you create the availability set is the following:
  • First you create the availability set
  • Then you create the individual VMs - and the important part is that the availability set has to be specified/set during VM creation using a parameter (AvailabilitySetName). If the VM has already been created without this parameter, then it cannot be added to the availability set later
If you are creating the VMs in PowerShell from scratch an not using the "New-AzVMConfig" cmdlet to specify VM settings in your script, then you can follow this MS guide. However, if you're using "New-AzVMConfig" then it has to be done slightly differently.

Create availability set

# Variables

$ResourceGroupName = "myRG"
$LocationName = "westeurope"
$AvailSetName = "AvailabilitySetAD01"

New-AzAvailabilitySet `
   -Location $LocationName `
   -Name $AvailSetName `
   -ResourceGroupName $ResourceGroupName `
   -Sku aligned `
   -PlatformFaultDomainCount 2 `
   -PlatformUpdateDomainCount 2

This creates the availability set with two fault domains and two update domains. In West Europe you can have up to three fault domains.

To create the VMs, make sure that the following lines are set in the script (copy/paste the snippet to get all the code):

$AvailSetName = "AvailabilitySetAD01"
# Get the availability set for domain controllers
$AvailSet = Get-AzAvailabilitySet -ResourceGroupName $ResourceGroupName -AvailabilitySetName $AvailSetName
# Create new VM config object and add it to the availability set
$VirtualMachine = New-AzVMConfig -VMName $VMName -VMSize $VMSize -AvailabilitySetID $AvailSet.Id

An example of a full VM script including the above three lines can be seen below. If using this in its entirety, make sure that the resource groups, key vault, and storage group are created in advance (or not use the specific parts about key vault and boot diagnostics).


# Update these variables:
# Update to correct RG name
$ResourceGroupName = "ad-RG"
$Vnetrgname = "vnet-RG"
$rgLogmon = "logmon-RG"
$secrgname  = "sec-RG"

$ComputerName = "myServer01" # Change this!
$VMName = "myServer01" # Change this!
$VMSize = "Standard_B2s"
$Vnetname = "MYvnet"
$SubnetName = "MyZone01"
$Disksize = "128"
$OSDiskName = $($VMName) + '-disk01'
$Publisher = "MicrosoftWindowsServer"
$Offer = "WindowsServer"
$Sku = "2019-Datacenter"
$DiskType = "StandardSSD_LRS"
$PrivateIP = "192.168.1.10" # Change this!
$stgaccountname = "myStorageAccount"
$kvname = "MyKV"
$secretname = "localadmpwd"
$AvailSetName = "AvailabilitySetAD01"

# Do not update these variables
$VMLocalAdminUser = "localadmin"
# Will prompt for password during deploy
#$VMLocalAdminSecurePassword = ConvertTo-SecureString  -AsPlainText -Force
# Will get password from text file
#$VMLocalAdminSecurePassword = Get-Content ./vmos-sec-key.txt | ConvertTo-SecureString -AsPlainText -Force
# Will retrieve passwd from key vault
$VMLocalAdminSecurePassword = (Get-AzKeyVaultSecret -vaultName $kvname -name $secretname).SecretValueText | ConvertTo-SecureString -AsPlainText -Force
$LocationName = "westeurope"
$NICName = $($VMName) + '-nic01'
$OSDiskName = $($VMName) + '-OsDisk01'

Write-Host "Creating variables at $(Get-Date)"
# Get existing Vnet
$Vnet = Get-AzVirtualNetwork -Name $Vnetname -ResourceGroupName $Vnetrgname
# Get existing subnet
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $Vnet
# Set static private IP address
$IPconfig = New-AzNetworkInterfaceIpConfig -Name "IPConfig1" -PrivateIpAddressVersion IPv4 -PrivateIpAddress $PrivateIP -SubnetId $Subnet.Id
# Create a new NIC for the VM and associate the private IP
$NIC = New-AzNetworkInterface -Name $NICName -ResourceGroupName $ResourceGroupName -Location $LocationName -IpConfiguration $IPconfig -Force

# Create credentials object
$Credential = New-Object System.Management.Automation.PSCredential ($VMLocalAdminUser$VMLocalAdminSecurePassword);
# Get the availability set for domain controllers
$AvailSet = Get-AzAvailabilitySet -ResourceGroupName $ResourceGroupName -AvailabilitySetName $AvailSetName
# Create new VM config object and add it to the availability set
$VirtualMachine = New-AzVMConfig -VMName $VMName -VMSize $VMSize -AvailabilitySetID $AvailSet.Id
# Set OS type and OS name and add to VM config object
$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $ComputerName -Credential $Credential -ProvisionVMAgent -EnableAutoUpdate
# Associate the NIC with the VM config object
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $NIC.Id
# Specify OS type for the VM config object
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName $Publisher -Offer $Offer -Skus $Sku -Version latest
# Set disk size in GB
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -DiskSizeInGB $Disksize -Name $OSDiskName -StorageAccountType $DiskType -CreateOption FromImage
# Set storage account for boot diagnostics (udpate line below)
$VirtualMachine = Set-AzVMBootDiagnostic -VM $VirtualMachine -Enable -ResourceGroupName $rgLogmon -StorageAccountName $stgaccountname

Write-Host "Creating new VM...(this can take 10+ minutes). Starting at $(Get-Date)"
# Create the VM using VM config object 
New-AzVM -ResourceGroupName $ResourceGroupName -Location $LocationName -VM $VirtualMachine -Verbose
Write-Host "VM created"
  
Write-Host
Write-Host "Script done at $(Get-Date)"
Write-Host

When done, it will look like below in the portal:






Tuesday, September 29, 2020

Azure: Encrypting VM disks with Powershell using Azure key vault

 Encrypting disks in Azure for virtual machines can be a good idea if you have sensitive data on them. At current client the decision is to encrypt disks for domain controllers but not for general purpose VMs (as it adds a bit of administrative overhead and might impact performance - I don't have specific numbers on this).

If you have a key vault in place with the -EnabledForDiskEncryption parameter set it is relatively easy to configure on the VM. The VM has to be already running so it is a post step after install.

From the VM deploy script you can add the below code snippet to your script:

# Encrypt VM disks (should only be done for AD VMs and VMs with highly sensitive data)
Write-host "Checking if disks are encrypted on VM"

# Get key vault
$KeyVault = Get-AzKeyVault -VaultName $kvname -ResourceGroupName $secrgname

# Check if disk already encrypted, if not then encrypt it
if (Get-AzVmDiskEncryptionStatus -VMName $VMName -ResourceGroupName $ResourceGroupName | Where-Object {$_.OsVolumeEncrypted -eq "Encrypted"}){
    Write-host "Disk already encrypted"
}
else {
    Write-host "Encrypting disks"
    Set-AzVMDiskEncryptionExtension -ResourceGroupName $ResourceGroupName `
     -VMName $VMName `
     -DiskEncryptionKeyVaultUrl $KeyVault.VaultUri `
     -DiskEncryptionKeyVaultId $KeyVault.ResourceId `
     -Force

Variables:

  • $kvname: Name of the key vault
  • $secrgname: Name of the resource group where key vault resides
  • $VMName: Name of the VM
  • ResourceGroupName: Name of resource group where VM resides
Assuming you have the correct permissions set on the key vault, then the secret will be created automatically in the key vault. During the encrypt process the VM will reboot and it takes about 10 minutes depending on the size of the disks.





Wednesday, September 23, 2020

Azure: Delete tags on resource groups and resources with Powershell

 At current client we've been pushing out standard tags via Azure Policy to both resource groups and resources. One policy adds tags to the resource groups and another poicy inherits the tags from the resource groups to the resources (to only have to update tags in one place).

After some evaluation we found that we'd pushed too many tags and needed to delete some of them from some of the subscriptions.

There is no easy way to do this in bulk from the portal but it can be done with Powershell.

The logical command to use would be Remove-AzTag but apparently that is only for unused tags and so it won't work if you've added values to your tags.

To delete tags with values added to them, you need two different scripts. One for resource groups and one for the resources.

If you have an 'inherit tags' policy enabled that force changes on updates, then make sure to delete first the tags on the resource groups and then on the resources. Otherwise the tags will be re-written to the resources immediately on update.

Both scripts below will traverse all or selected subscriptions and delete tags.

DeleteTagsOnRGs.ps1

# This script will delete the specified tag including values only on resources groups.

# Update this variable with tag name to be deleted. No tag value required.
$DeleteTag = "ContactEmail"

# Get all subscriptions in tenant
# $subscriptions = Get-AzSubscription
# To get all subscriptions except subscription named: SUBS NAME
# Replace -notlike with -eq to get a specific subscription
$subscriptions = Get-AzSubscription | Where-Object {$_.Name -notlike "SUBS NAME"}

# Traverse through all subscriptions
Foreach ($subscription in $subscriptions ) {

# Select a subscription    
Select-AzSubscription -subscriptionid $subscription

# Get list of resource groups in subscription
$rg = Get-AzResourceGroup
# For each resource group, get the associated tags and put into a variable
Foreach ($i in $rg.ResourceGroupName)
{
 $Tags = (Get-AzResourceGroup -Name $i).Tags
 # Remove the tag with the Name specified
 $Tags.Remove($DeleteTag)
 # Set the tags on the resource group
 Set-AzResourceGroup -Name $i -Tag $Tags
}

}

DeleteTagsOnResources.ps1

# This script will delete tags on all resources in all subscriptions, 
# however not on the resource groups, see DeleteTagsOnRGs.ps1 for that.
# Must run as .ps1 script, pasting into Cloud Shell will not work.
# Note, there can be a delay of 20-30 mins from running script until Tags appear 
# as deleted in the Portal
# Before running this script, ensure that tags are deleted at RG level first 
# otherwise they'll be re-added via the Inherit policy (if applied)

# To get all subscriptions
# $subs = Get-AzSubscription
# Get only a specific subscription
# $subs = Get-AzSubscription | Where-Object {$_.Name -eq "SUBS NAME"}
# To get all subscriptions except SUBS NAME
$subs = Get-AzSubscription | Where-Object {$_.Name -notlike "SUBS NAME"}

# Specify tag name
$tagname = "ContactEmail"
# Specify tag value
$tagvalue = "person@companyemail.com"

# Through all subscriptions, get resources with specified tag and value, 
# remove the tag from the array and update the resource
$subs | ForEach-Object {
    Set-AzContext $_
    $rs = Get-AzResource -TagName $tagname -TagValue $tagvalue
    $rs | ForEach-Object {
        $_.Tags.Remove($tagname)
        $_ | Set-AzResource -Force
    }  
}

That's it.

Wednesday, September 16, 2020

Activate new Visual Studio subscription and start using credits in a new Azure AD tenant

 If you want to test code in Azure or you just want a sandbox to try things out, then having a Visual Studio (VS) subscription (formerly MSDN) is a good idea. This gives you a certain amount of dollars (or credits) to spend each month in Azure.

There are two types of subscriptions:

  • Visual Studio Professional (50 USD/month in credits)
  • Visual Studio Enterprise (150 USD/month in credits)
The subscription is personal to the employee and is typically acquired by the employer and assigned to the employee on the employee email address (you will receive an email with activation info from Microsoft). See pricing details here.

Activate Visual Studio subscription

Once you have been assigned a VS subscription, it has to be activated. Go to below link to activate:


Log in with your company email, if you don't have an account already, then create one (using company email).

Activate the monthly credits under the Featured Benefits section, see below:


You can view your subscription details under the Subscriptions tab:


Create new Azure AD tenant

When you log into Azure using your company credentials, you will typically see the company's AD tenant under Azure Active Directory, e.g. companyname.onmicrosoft.com. Since you'll likely have limited permissions in this tenant (AD tenant is similar to an AD domain, just in the cloud. It's also referred to as Directory) and since the aim it to create an isolated sandbox for testing, then a new AD tenant has to be created and the VS subscription associated with this tenant.

To create a new AD tenant, go to:


Go to: Create a resource -> Identity -> Azure Active Directory (see below):


Give your new AD tenant (or organisation) a name and click create:


Note that this will not affect the existing company AD tenant. Even though you create it while logged in with your company email, it will have no cost for the company and will only be manageable by you. I note this as I have discussed this with both colleagues and clients where they worry that they might break something in the company Azure AD. They won't.

Move your VS subscription to the new AD tenant

Once your new Azure AD is created, you can go to your VS subscription and change the directory so that the subscription will be associated with your new tenant.

  • Go to Subscriptions and choose your VS subscription
  • Under "Overview" choose "Change directory"
  • Choose your newly create Azure AD tenant (as opposed to the company AD tenant)
  • Click OK, see below two screen dumps:



Note that it can take a few hours before the changes kick in.

To switch around between tenants and also to choose your default tenant, click on your profile in upper right corner and choose your directory/tenant and/or default tenant, see below:


That's it! Now you can start using your monthly credits in a tenant that you have full control over.

To get an overview of current spending and to know when the monthly credits reset, see this post.






Thursday, September 10, 2020

Azure Firewall drops traffic to on-prem S2S VPN

We're currently setting up an Azure Firewall at a client site. Initial implementation was done by following the MS documentation: 

https://docs.microsoft.com/en-us/azure/firewall/deploy-ps

After deployment and after attaching a given subnet to the default route table (to force all outbound traffic to pass through the Azure Firewall), then there was no communication from the Azure subnet and to the local VPN gateway (S2S VPN to on-premises). Other subnets that weren't attached to the route table worked fine.

It seemed that new default route (see example below) might be overriding the existing default routes in Azure. And that the way forward would be to create additional routes to specify traffic to the VPN.

$routeTableDG = New-AzRouteTable `

-Name Firewall-rt-table ` -ResourceGroupName Test-FW-RG ` -location "East US" ` -DisableBgpRoutePropagation #Create a route Add-AzRouteConfig ` -Name "DG-Route" ` -RouteTable $routeTableDG ` -AddressPrefix 0.0.0.0/0 ` -NextHopType "VirtualAppliance" ` -NextHopIpAddress $AzfwPrivateIP ` | Set-AzRouteTable


It turns out that the standard routes were fine. Only the default route to the internet is overridden (which is expected), the other two remain in use:

These are the standard routes that Azure creates:

"Each virtual network subnet has a built-in, system routing table. The system routing table has the following three groups of routes:
Local VNet routes: Directly to the destination VMs in the same virtual network.
On-premises routes: To the Azure VPN gateway.
Default route: Directly to the Internet. Packets destined to the private IP addresses not covered by the previous two routes are dropped."

The problem was that the property setting: "Propagate gateway routes" was set to "No", see below. This means that the VPN gateway routes are not visible/propagated to the subnets. To turn it on you can either do it from the portal or configure it via Powershell.




To do this in Powershell, simply remove the line: -DisableBgpRoutePropagation from the New-AzRouteTable command so it looks like below :

-Name Firewall-rt-table ` -ResourceGroupName Test-FW-RG ` -location "East US" #-DisableBgpRoutePropagation

This will set the property to: "False" which in the portal corresponds to "Yes".  You can see the "false" setting under Route table -> Export template.

When done, the published routes from the virtual gateway become visible under Route tables -> "your route table" -> Effective routes, like below, and traffic will flow to the on-prem site via VPN as well.