Azure App Registrations Cert / Client Secret MS Graph Report

In this post we will be looking at creating a report to show what Azure App registrations have expiring client secret / certificate in the specified amount of days.

There is currently no in built way to report on expiring App registrations in the Azure portal other than checking the app registration, so we will be using Microsoft Graph SDK to automate the reporting.

First to automate the report we need to create an app registration to use for the Microsoft Graph connection. I have gone through this in a previous post.

Using Microsoft Graph PowerShell SDK

The specific Microsoft GraphApi application permission required is Application.Read.All, this needs to be added to the App Registration that we use for Microsoft Graph.

Next we need to connect to Microsoft Graph using.

Connect-MgGraph

To list the app registration use

Get-MgApplication

Once we have the list of apps we can use PasswordCredentials to view client secret details

(Get-MgApplication).PasswordCredentials

and KeyCredentials to view the certificates details

Once we have the required properties, we can create the script to export the app registration details.

There are two parameters Reportonly which returns just the result to PowerShell window and ReportExport which will export the report to the specific folder specified.

Below is what the Reportonly should look like.

.\Get-AppRegistrationDetails.ps1 -CertificateThumbprint Thumprint -ClientId ClientID -TenantId TenantID -ReportOnly -ExpiryDate 200

When using the Reportexport

.\Get-AppRegistrationDetails.ps1 -CertificateThumbprint thumbprint -ClientId ClientID -TenantId TenantID -ReportExport C:\temp\Graph\ -ExpiryDate 200

The full script can be downloaded from the below GitHub link.

https://github.com/TheSleepyAdmin/Scripts/blob/master/MSGraph/AppRegistration/Get-AppRegistrationDetails.ps1

Create Local ESXi Account Using PowerCLI

In this post we will be going through creating local ESXi account using PowerCLI.

Recently I have had to create local account to allow a monitoring tool to pull information from all ESXi hosts.

We want to automate the user creation and assign the required permissions so that they only have the permission required for a limited time.

First we need to connect to the ESXi Host using PowerCLI

Connect-VIServer

To check what account already exist use the below.

Get-VMHostAccount

To create a new account we will use the New-VMHostAccount command

New-VMHostAccount -Id accountname -Password password -Description Account Description

Next we need to assign the required permissions. We can list the current roles using

Get-VIRole

We also need an entity to set the permission or the command will error out.

To list the entity use the

Get-Folder

Select the entity that will have the role applied. In this case we will be applying to the root object so it applies to all objects on the host and will assigning the admin role.

New-VIPermission -Entity (Get-Folder root) -Principal accountname -Role Admin

To remove the account use the below command.

Get-VMHostAccount -User account name | Remove-VMHostAccount -Confirm:$false

Once we have the commands, we can create the script to automate the account creation and role assignment to configure multiple hosts.

The scripts uses EsxiHost as the heading for the CSV if you want to use something different the script will need to be updated.

Below is the script running against my test hosts.

.\Create-LocalESXiUser.ps1 -ESXiHostList .\EsxiHosts.csv -ESXiUser useraccount -ESXipass password -ESXiNewUser accountname -ESXiUserPass accountpass -ESXiPermission Permission -ESXiUserdesc "Account Description"

This process can also be used to update the permission for a specific account.

To download the full script use the below link to github.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Config/Account/Create-LocalESXiUser.ps1

Configure SNMP On VMware ESXi Using PowerCLI

In this post we will be going through deploying new SNMP configuration to a list of ESXi hosts using PowerCLI. We can add SNMP using ssh and esxcli commands but this will required SSH to be enabled and connecting to each host.

We can use Set-VMHostSNMP command to set the SNMP configuration by conecting to the host using connect-viserver which uses https to connect and does not required SSH to be enabled.

First we need to connect to the ESXi host

Connect-VIServer -Server esxihost.domain.local

use a local account like root to connect

If you get a certificate error and can’t connect you might need to update the PowerCLI Configuration or install the root cert to trust the self singed cert of the ESXi hosts.

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

Once connected we will be using the below set of command to configure the SNMP settings.

Get-VMHostSnmp | Set-VMHostSnmp

https://developer.vmware.com/docs/powercli/latest/vmware.vimautomation.core/commands/set-vmhostsnmp/#Default

First we will enabled and set the community string

Get-VMHostSnmp | Set-VMHostSnmp -Enabled:$true -ReadOnlyCommunity communityname

Next we will set the target that traps will be sent.

Get-VMHostSnmp | Set-VMHostSnmp -TargetCommunity communityname -TargetHost snmp.domain.local -TargetPort 162 -AddTarget

To test I have setup snmp on Ubutu

Now that we have set of command we can create the script. I will be doing a loop through each host and configuring the SNMP.

I also added in some if statement to check if SNMP is already enabled and to check if the target host matches the one that is set in the parameters.

The full script can be downloaded from the below github link.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Config/SNMP/Set-ESXiSNMP.ps1

Below is an example of what the csv file should look like if you want to use a different heading the script will need to be updated.

Each of the values will be called as parameter to allow easy re-use below is an example of the SNMP script running against my test hosts.

Using PowerCli can be a quicker way to set and enabled SNMP on a list of hosts rather than having to SSH and use esxcli command. This can also be used to update the existing SNMP configuration to a new traps target.

Using Stored Access Policy with Azure Storage

In this post we will be going through setting up and using stored access policy with Azure storage account. We can create SAS URL but each time we create one there is no way to revoke without rotating the storage keys.

A stored access policy can be used to control shared access signatures (SAS) on the server side. We can use a stored access policy to change the start time, expiry time, or permissions for a SAS URL that is generated from a storage account. We can also revoke access after it has been issued with out having to rotate the storage keys.

Below are the storage resources that support stored access policies:

Blob containers
File shares
Queues
Tables

First we will create a new storage account in Azure.

Logon to Azure and go to storage accounts. Click Create and add in the basic details and I left the rest as default.

Once the storage account is deployed, we will be creating a container in the below example its called files.

Go in to the container and create a policy under Access policy.

Give the policy a name, set the required permission and start / end date. Click ok and then save the policy.

Once the policy is create it will show under access policy.

Now that we have the access policy we will need to create a new SAS. There are two ways to create this.

First we can create it directly from Azure storage under Shared access tokens.

Select the Stored access policy. We can also restrict access down to a specific IP.

Next click on Generate SAS token and URL.

We can also use Azure Storage Explorer to create a new SAS.

Azure Storage can be downloaded from:

https://azure.microsoft.com/en-us/features/storage-explorer/

Logon with an account that has access to the storage account.

Select the storage account that we want to create the SAS for.

Select the Access policy, this will then grey out all the options as we are now using the access policy for the SAS.

Click create and this will generate the URL with the SAS key and will also reference the access policy

To test access to the blob we can connect using Storage Explorer.

Click on the connect to Azure Storage and select Blob container.

Azure Storage Explorer Resource Selection

Select SAS

Azure Storage Explorer Connection Method

Give the connection a name and add in the SAS URL generated earlier.

The last screen is a summary of details once all are confirmed, click connect.

We have now connected to the Files container we created with the storage policy and SAS.

To test the policy is working we can try delete the a file as I didn’t apply that permission in the policy I get access denied.

Now we can update the policy and add the delete permission. Click save the policy can take 30 seconds to update.

Now when delete the file it completes without issue.

Using a stored access policy allow granular access control and also means if we need to change a permission or start / expiry time for an application or user that is using the SAS URL, we no longer have to re-issue each time we can just update the storage policy used for the SAS.

How to check VM SKU and VM Series Sizes Different Methods

When deploying VMs in Azure using template we need to be able to check the VM SKU and sizes to be able to update templates to deploy different OS version and VMs sizes.

There are a few different methods that can be used.

There is the Microsoft document, below is the link to the virtual machine size docs.

https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-general

We can select the type in this case we will use general purpose.

Select the size, I selected ddv5-ddsv5-series. There will be table listing the VM sizes.

We also check the the VM size from the Azure portal by creating a new VM and changing the VM sizes.

Last method is to use either PowerShell or Azure CLI to query the require details on Windows Image SKU and VM sizes.

First we need to install the Azure AZ PowerShell module.

Run the below command to install the AZ module

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Once the module is installed run

Connect-AzAccount

We can use the Get-AzVMImagePulisher to get the publisher name in this case I was looking for Microsoft Windows.

Get-AzVMImagePublisher -Location northeurope | Where-Object {$_.PublisherName -like 'MicrosofWindows*'}

To check all available Windows Server images we can run.

Get-AzVMImageSku -Location northeurope -PublisherName MicrosoftWindowsServer -Offer Windowsserver

We can use where-object filter to by server OS version.

Get-AzVMImageSku -Location northeurope -PublisherName MicrosoftWindowsServer -Offer Windowsserver | Where-Object {$_.Skus -like '2022*'}

To get the VM series size use the below command to check size in the specific region.

Get-AzVMSize -Location northeurope

To filter by a specific cores or name we will use where-object again.

Get-AzVMSize -Location northeurope | Where-Object {$_.Numberofcores -eq '4' -and $_.Name -like 'Standard_D*'}

Now once we have the SKU and Image size we can update our template file with the required VM size and image references.

Using Parameter File With Bicep Templates

In the previous post we went through the process of deploying an Bicep template using parameter that where called directly from PowerShell.

Deploy Azure Resource Using Bicep template and PowerShell

This is ok when deploying resources that require only a few values to be set, but this can become difficult to manage when there are a lot of parameter like when deploying virtual machines or web apps.

A parameter file for Bicep is a json file that has the specific parameter names and values set.

I used this Microsoft document as a reference to create the parameter file.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameter-files

Below is the Bicep file we created in the last post.

A parameter file for the storage Bicep template would look like the below.

Once we have the parameter file, we are ready to test the deployment. To test without actually deploying the resource add the whatif parameter.

New-AzResourceGroupDeployment -ResourceGroupName ResourceGroupName -TemplateFile .\BicepTemplate.bicep -TemplateParameterFile .\BicepParamter.json -WhatIf

Next we will create a template to deploy a virtual machine and it network interface. To create base template in visual studio code type

res-nic to populate the network interface:

Use res-vm-windows to populate the virtual machine.

I will be creating parameters for each part that requires customization and anything that doesn’t I will leave with the hardcode values like. The @descirpiton is a Parameter decorators that allow use to add a description of what the parameter is used for.

I create two variables for the vnetId and subnetref that are used for the network interface

Below is what the updated virtual machine resource template looks like.

Once we have the Bicep template file ready the next step is to configure the parameter file. I copied the default template file code from the above Microsoft document and added in each of the required parameters.

To get the virtual network ID that will be used in the parameters file go to the virtual network and click on properties > Resource ID.

Once we have that we can fill out the reset of the parameter values.

After the template file has been configured, we can test the deployment same way as the storage account and use the whatif to confirm there are no errors.

As I have not set the admin password in the template or parameter file the deployment will prompt for the admin password to be set on the VM.

If the test deployment comes back without any issues we can check the results from the whaif deployment to confirm all the are correct.

Since the template and parameter files have returned no error we are ready to run and deploy the new VM resource.

If we check the resource group the new VM, OSDisk and network interface should be created.

Now that we have all the template and parameter file working we can just create a new parameter file for each VM resource. We can now create fully customized VM’s pretty quickly instead of having to deploy using the Azure market place and manually select the options we want to set.

Deploy Azure Resource Using Bicep template and PowerShell

In a previous post we went through deploying resource using ARM templates. I have been recently working on creating some new templates to be used for additional deployment and decided to use Bicep templates instead as it seem to an easier and more straight forward way of writing template files to deploy resources in Azure.

Bicep uses a simpler syntax than creating templates using JSON, the syntax is declarative and specifies which resources and resource properties you want to deploy.

Below is a comparison of a JSON and Bicep template file to create a storage account.

We can see that the bicep file is an easier format to read and create.

To get started with Bicep we will first be installing the Bicep extension to Visual Studio Code so we can edit and modify Bicep templates.

The extension adds intellisense which makes it easier than looking up the full syntax for each resource.

To create a new template click on new file in VS code and select bicep as the language.

To create a template using intellisense either start typing the res-resource type or the resource type itself.

Click on the resource to pre populate the template.

The values can be hard code in the template file but this would require manual change each time the template is run.

We can add parameters to the template to make it more reusable. There are a few different types of parameters that can be used.

Below is a brief description of each type.

Parameter	Description
string	Single line value
array	Allow multiple values
int	Integer value
bool	Required true or false
objects	Allows property types

Microsoft have a more in depth document on the different data types.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/data-types

The below is an example of a template with parameters set.

Once we have the template we need to install Azure PowerShell if not already installed and to install the Bicep tools, below is the document to install.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/install#install-manually

To connect to Azure PowerShell use

Connect-AzAccount

Once connected we can use the New-AzResourceGroupDeployment to deploy the template and specify the parameters values. To test the deployment for errors without running an actual deployment we can use the -whatif parameter.

New-AzResourceGroupDeployment -ResourceGroupName ResourceGroup -TemplateFile pathtotempaltefile\BicepStorageTest.bicep -location regsion -storagename storageaccountname -storagetype Standard_LRS -WhatIf

Run the command and it should return any error if there is an issue or green if there is no issue.

Once the template comes back with no issues we can remove the -whatif and the storage account will be created.

To confirm the storage account has been created use the Get-AzStorageAccount

Using parameters in the Bicep template is fine when there are only a few that need to be called but for more complex deployment it will be better to use a parameters file and pre fill each value.

In the next post we will go through the process of using a template to create a VM and its network interface and will call a parameters files instead of call the parameters in PowerShell directly.

Azure VM Snapshot Backup: UserErrorRequestDisallowedByPolicy

During a recent project I have been deploying new VM to Azure, when trying to configure the Azure VM backup I was getting a failure at taking snapshot.

The error that showed in the reason was UserErrorRequestDisallowedByPolicy.

This was being caused by a policy that one of the Azure Admins had setup to require tags be configure on resource groups. When a initial backup is run it creates a resource group to save the restore point collection to and it is this resource group that is getting blocked by the Azure tag policy.

To view the policy details we can go to Policy > assignments

Click on the policy to view the parameter’s.

There are two option to work around this issue, either changing the policy from a Deny effect to a Modify effect, or create the resource group manually.

I will be creating a manual resource group as I am not that familiar with creating custom policy yet and this was the quicker workaround.

Below is the link to the Microsoft document on creating a manual resource group for restore collection point.

https://docs.microsoft.com/en-us/azure/backup/backup-during-vm-creation#azure-backup-resource-group-for-virtual-machines

Here are the steps that I did to get around this, by manually creating the resource group that will be used for the backup.

This needs to be RG name with 1 as this starting number in my case I used TheSleepyAdmin_Backup_RG1.

In the backup policy we specify the new resource group. Go to Azure Backup center > Backup policies.

Put in the name of the resource group we create manually without the number. In my case this was TheSleepyAdmin_Backup_RG

Wait for the policy update to complete.

Now try the backup again and it should complete.

If we check the resource group we can see that the restore point collection has been created.

Any addtional backup should now also be successfully, if the resource group becomes full it will try to create a new RG so there maybe a need to create another RG in the future. I will be having a look at creating or updating the tag policy to apply a modify instead of a deny but that will be in a different post as this seems like it would be a better longer term solution.

Enable Accelerated Networking on existing Azure VM’s

In this post we will go over the different methods to enabled accelerated networking in an existing Azure VM.

Accelerated networking improves performance as it allows the network interfaces of Azure VM to bypass the host.

Screen shot from Microsoft documentation

Below are some of the benefits of using accelerated network.

Lower Latency / Higher packets per second

Reduced jitter,

Decreased CPU utilization

Accelerated networking is only supported on VM that have 2 or more CPU’s. If the VM’s are in a availability set all VM’s in the set need to be powered off before updating.

There are three way’s to enabled accelerated networking on existing VMs use either AZ PowerShell Module or the AZ CLI and directly in the Azure portal.

To enable in the Azure portal go to Virtual machines > Networking and select the required network interface.

To enable first Power off the VM,

Select the network interface and click on the name. This will bring you to the network interface configuration page.

Click on enable accelerated networking

You will have to confirm you have validate that your operating system is supported.

Once completed the network interface should now show have accelerated networking enabled.

Enabling in the console is fine for one or two interfaces but if there are a few to update doing PowerShell or AZ CLI will be a quicker method.

To update using the AZ PowerShell Module, first we need to install the module.

To install run the below command

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Once installed use the below to connect, you will be prompted to put in Azure account details.

Connect-AzAccount

Once connected, we can check if the network interfaces have accelerated networking using the below command.

Get-AzNetworkInterface -ResourceGroupName RGName | Select-Object Name,EnableAcceleratedNetworking

To enabled accelerated networking the VM needs to be stopped and deallocated so either power off from the Azure console or use stop-azvm

Stop-AzVM  -Name VMName -ResourceGroupName RGName

To enable we need to get the network adapter information into a variable and then set the enabledacceleratednetworking property to true.

$networkacc = Get-AzNetworkInterface -ResourceGroupName RGName-Name nicname
$networkacc.EnableAcceleratedNetworking = $true
$networkacc | Set-AzNetworkInterface

Once the command completes, we can run the command to check the network interfaces again and one should now have enabledaccleratednetworking set to true.

If there were multiple network interfaces in the resource group to enable, we could get the list and loop through each, but each VM would need to be supported or they would error out.

$networkaccs = Get-AzNetworkInterface -ResourceGroupName RGName
foreach ($networkacc in $networkaccs){

$networkacc.EnableAcceleratedNetworking = $true
$networkacc | Set-AzNetworkInterface

}

Last step is to power back on the VM either from the Azure portal or using AZ PowerShell.

Start-AzVM  -Name VMName -ResourceGroupName RGName

That is the process for setting using AZ Powershell.

To set using the Azure CLI, first we need to install the go to the below and download the MSI installer.

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?tabs=azure-cli

Once installed launch PowerShell.

to logon either use az login for an interactive logon process

or use with username and password parameter. (This method will not work with MFA so we will be using the interactive method.)

az login -u <username> -p <password>

When running the az login command you will be brought to the standard login.microsoft.com page.

Once signed in, we can query the resource group for network interfaces to see what has acceleratednetworking enabled

az network nic list --resource-group RGName --query [].[name,enableAcceleratedNetworking] --output table

To update the interfaces the VM needs to be powered off either in the Azure console or using AZ Cli

To use AZ Cli

az vm deallocate --resource-group RGName --name VMName

az network nic update --name NicName --resource-group RGName --accelerated-networking true

Once the command completes run the list command again to confirm that acceleratednetworking is set to true.

last step is to start the VM using either Azure port or Az Cli

az vm start --resource-group RGName --name VMName

The network interfaces should now have accelerated networking enabled.

Allow External Access to vCenter Using Azure Application Proxy

With some of the recent critical vulnerability’s for both VMware and Log4j vulnerability this is has shown again that having vCenter open on the internet is not a good idea as it leave a big target for hackers to try exploit.

There are several ways to avoid having vCenter directly available on the internet, in this post we will be going through publishing using the Microsoft Azure Application Proxy. This will be using Azure AD as an authentication source and we can add addtional security like MFA.

First before we can use the Azure Application Proxy we need to make sure we have an Azure subscription and the appropriate license types. The application proxy is available for users that have either a Azure AD P1 or P2 license.

Once all the pre requisite are meet we can install the Azure Application Proxy, we will be using a Windows Server 2019 VM.

For Windows Server 2019 we need to disable http2 protocol, to disable run the below command from PowerShell.

Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0

To download the installer, logon to the Azure portal > Azure Active Directory > Application proxy.

Once downloaded run the installer on the server that will be used for the app proxy. To register the connector the minimum rights is to be part of the application administrator role in Azure.

During the install we will be prompted to enter details for an account that has the correct permissions.

The install can take a minute or two to finish.

Once the install has completed the Azure Application proxy connector should show in Azure.

Now that we have the proxy connected to Azure, we will need to register the enterprise application.

Go to Azure AD > Enterprise applications > create your own application

Give the application a name and click create.

Give the app a name
Add in the internal URL for vCenter
Set external URL this can either be an msappproxy.net address or custom domain named
Set the pre authentication to either Azure AD or passthrough (to use MFA or conditional access policy set to Azure AD)
Set the connector group

I left the addtional settings as the defaults. If the internal and external URL are different (its recommend from Microsoft to use the same DNS address), then to allow the redirect set the translate URLs in > Application Body to yes so allow link translation from the external to internal URL.

Click create, the app can take a few minutes provision.

We can restrict access to the app by using security groups or induvial users access.

Once we have setup the access group we can now connect to the external URL.

If the internal application is using an self singed cert or un trusted certificate authority, then the cert will need to be add to the trusted root cert store on the application proxy server.

This is the TLS error:

There should also be event log 13001 log under Applications and Services Logs/Microsoft- AAD Application Proxy Connector/Admin.

Download the root CA cert from vCenter and install to the trusted root on the server that has the Azure Application Proxy connector installed.

The second option is to use a custom SSL cert for vCenter, I have done a previous post on how to install a custom cert.

Set Custom SSL Certificate on VMware vCenter 6.7 Appliance using Windows CA

After this has been completed the page should now load without issue using the external Azure msapproxy address.

If the application proxy is set to use pre authentication then users will be redirected to the sign in page for Azure and be subject to any conditional access policies.

When connecting from an account that has not been give access rights they will not be able to connect.

The VMware remote console does not work using the Azure Application proxy as it requires both port 443 and 902, the application proxy can’t connect on 902 so the connection fails.