Installing Git for Windows

Install Git on Windows is easy, just run the following;

scoop install main\git

I first realised something was wrong when I was trying to clone a repo from an Azure DevOps organisation I had not worked with for several weeks. I was getting the following;

❯  git clone https://[organisation]@dev.azure.com/[organisation]/[project-name]/_git/[repository-name]
Cloning into '[repository-name]'...
Password for 'https://[organisation]@dev.azure.com':

That’s weird! I’m sure I wasn’t prompted to enter a password the last time I did this…In fact, I’m pretty sure I just logged in via the usual Microsoft Entra ID authentication flow (including MFA). The only thing that had changed was that I had re-installed Git using Scoop.

So, what’s missing?

After a bit of frantic Googling, I realised that Git Credential Manager had not been installed. Doh!

This is easily resolved by simply installing GCM using Scoop:

scoop bucket add extras
scoop install extras/git-credential-manager

Additionally, I need to configure Git to use GCM:

git config --global credential.store manager
git config --global credential.helper manager

What about WSL?

The above will fix things for Windows, but what about WSL? Well, you can install GCM in WSL as well but that means having separate credential stores. The best experience is to let GCM share credentials & settings between WSL and the Windows host. This can be achieved by doing the following.

Inside your WSL installation, run the following command to set GCM as the Git credential helper installed by Scoop, which will not be in the default location indicated on GCM on Windows Subsystem for Linux (WSL):

git config --global credential.helper "/mnt/c/Users/[username]/scoop/shims/git-credential-manager.exe"

# For Azure DevOps support only

git config --global credential.<https://dev.azure.com.useHttpPath> true

Note: change [username] so that the path is valid.

Wrap-up

I learned two things from this experience:

1. Always check what is - and what isn’t - being installed by Scoop.
2. Additional configuration may be required when performing a user-only install, instead of a system-wide install.

Conclusion

I hope you’ve found this useful.

As always, if you think there is a better way this could’ve been fixed then please leave a comment below.

These instructions assume you have already configured Starship as per my previous blog post. If not, follow those instructions first before proceeding.

Can I really customise the humble Windows shell cmd.exe?

Yes you can! Here’s mine, which looks almost exactly like my PowerShell and WSL instance;

Step 1: Install Clink using Scoop

Customising the Command Prompt using Starship is achieved using a tool called Clink.

The first step is to install Clink, which is as simple as opening Windows Terminal and running the following PowerShell;

scoop bucket add main
scoop install main/clink

Step 2: Configure Clink to load Starship

Add the following to a file called starship.lua and save in a Clink scripts directory:

-- starship.lua
os.setenv('STARSHIP_CONFIG', 'C:\\Users\\?\\.config\\starship\\starship.toml')
load(io.popen('starship init cmd'):read("*a"))()

Replace “?” with the relevant Windows “username” so that the path is valid, or modify the path to where you have your Starship TOML file saved. This means that the Command Prompt will use the same Starship configuration file as both your Windows Terminal AND WSL instance, ensuring consistency across all prompts!

And there’s more!

Clink as a powerful tool for customising the cmd.exe, including features such auto-suggestions, completions, persistent history and key bindings!

If you spend a lot of time using Command Prompt then take a look at the multitude of configuration options, but be careful you don’t conflict with customisations provided by Starship.

Wrap Up

All of the above code & config snippets are available on my dev-machine-configuration GitHub repo.

Conclusion

I hope this will be of help to you. Let me know if you have any suggestions for improvements in the comments.

This is Part 1 of a series of posts regarding this issue.

The provisioning state is “Failed”! Should I be worried?

As explained in Troubleshoot Azure Microsoft.Network failed provisioning state;

These states are metadata properties of the resource. They’re independent from the functionality of the resource itself. Being in the failed state doesn’t necessarily mean that the resource isn’t functional. In most cases, it can continue operating and serving traffic without issues.

OK, panic over, but…

What’s the cause of this?

There are different reasons why this can occur that seem to vary depending on the resource type, whether it be an IP Group, Azure Firewall Policy, Azure Firewall etc.

For Azure Firewall, I recently found this can occur if you attempt to push changes to IP Groups in parallel. This is a known issue, which can be found Azure Firewall known issues and limitations. Fortunately, there is a feature that is currently in preview to support parallel IP Group updates, although I’m not sure how a CI/CD will know to limit parallel updates to a specific number.

So, how do I fix it?

For resources in a Failed provisioning state, you can Restore succeeded state through a PUT operation.

The easiest way to achieve this task is to use Azure PowerShell. Issue a resource-specific Get command that fetches all the current configuration for the resource. Next, run a Set command, or equivalent, to commit to Azure a write operation that contains all the resource properties as currently configured.

You can find a list of Azure PowerShell cmdlets to restore succeeded provisioning state.

Didn’t you say something about dependencies?

That’s right. If you have several resources that are “chained” in some way then you may find that one or more of them have a Failed provisioning state.

A recent customer of mine experienced this where they had multiple resources chained together like so;

They couldn’t deploy changes to some of the IP Groups referenced by the Parent Azure Firewall Policy because it had a Failed provisioning state, which was because the Child Azure Firewall Policy had a Failed provisioning state, which in turn was because the Secondary Azure Firewall had a Failed provisioning state.

We resolved the situation by doing the following:

• Perform a PUT operation on the Secondary Azure Firewall
• Perform a PUT operation on the Child Azure Firewall Policy
• Perform a PUT operation on the Parent Azure Firewall Policy

The lesson here is that you will need to check all resources in the dependency chain before you perform any of the PUT operations. If you perform the PUT operations in the wrong order then they will fail.

Conclusion

I hope this helps someone that experiences the same issue.

As always, if you think there is a better way this could’ve been fixed then please leave a comment below.

by J. R. R. Tolkien….maybe.

Introduction

I recently watched Starship! One prompt to rule them all by Matt Field and loved the idea of having a consistent look and feel across all the prompts that I use on my Windows 11 machines, whether that be PowerShell or WSL Ubuntu in either Windows Terminal or Visual Studio Code. Such as;

Briefly, the above images are showing (from left to right);

• The platform (Windows or Linux)
• The shell (PowerShell or Bash)
• I’m in the “dev-machine-config” folder
• This is a GitHub repo
• I’m in the “main” branch
• The name of the Azure subscription that AZ CLI is currently logged into

WARNING! This article is written for Windows 11 users. Those on macOS or Linux may not have these issues and will need to follow slightly different instructions.

After trying to follow Matt’s instructions I discovered that not everything was going to work on my work laptop because I don’t have the permissions to start / run a prompt with elevated privileges. Also, some of the tasks required to get Starship setup can be done in several different ways, some easier than others. So I thought it might be useful to document my findings here for the benefit of others.

What’s Starship?

“What’s Starhip?”, I hear you ask. Starship is a cross-platform cross-shell prompt written in Rust, so is blazingly fast. It allows you to customise and augment the prompt with additional information that you may find useful.

Sold! How do I get this setup?

Before you run headlong into trying to install Starship, you need to install a few dependencies first. As I said before, I couldn’t install Starship using Winget or Chocolatey as I did not have the permissions to start Windows Terminal with elevated privileges. After a bit of sluething, I discovered an alternative package manager called Scoop, which allowed me to install Starship without elevated privileges, as well as other helpful tools.

Step 1: Install Scoop in Windows

The first step is to install Scoop, which is as simple as opening Windows Terminal and running the following PowerShell;

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri [https://get.scoop.sh](https://get.scoop.sh){:target="_blank"} | Invoke-Expression

Step 2: Install a Nerd Font

I’m using Microsoft’s Cascadia Code TrueType font, which can be installed on Windows using, you guessed it, Scoop!

scoop bucket add nerd-fonts
scoop install nerd-fonts/CascadiaCode-NF

I also needed to install it in my WSL Ubuntu instance as well. This can be done using a tool called NFDL (Nerd Fonts Downloader), which is a small NodeJS app. So, first install NodeJS and NPM - if you don’t have them already - and then NFDL;

sudo apt-get install -y nodejs npm
npm install -g nfdl

Then run the cli;

nfdl

Select your desired Nerd Font from the menu and let the cli handle the rest. By default, fonts will be downloaded and installed in the .fonts directory in your home directory.

Step 3: Configure Windows Terminal to use the downloaded Nerd Font

By default Windows Terminal uses a standard font, so you need to tell it to use the new Nerd Font. Open Windows Terminal > Settings, and select Profile Defaults > Appearance, and select your Nerd Font from the the Font face dropdown list. For me that meant selecting “CaskaydiaCode NF”. If you don’t want to apply the font to all profiles then select each profile to set the Font face.

Step 4: Configure Visual Studio Code to use the downloaded Nerd Font

By default Visual Studio Code uses a standard font, so you need to tell it to use the new Nerd Font. Open Visual Studio Code > Preferences > Settings, then Text Editor > Font and type the name of your Nerd Font and click Save. For me that meant entering “CaskaydiaCove NF”.

Step 5: Install Starship on Windows

To install Starship on Windows, open Windows Terminal and run the following PowerShell;

scoop bucket add main
scoop install main/starship

You then need to edit your PowerShell profile to run Starship at startup. From the same Windows Terminal run;

notepad $PROFILE

and then add the following code at the bottom;

$ENV:STARSHIP_CONFIG = "$HOME\.config\starship\starship.toml"
Invoke-Expression (&starship init powershell)

You need to create a configuration file for Starship, which is the “starship.toml” path in the above code. Follow the instructions, or you can download and use my configuration from my GitHub repo. Ensure the path to your starship.toml file matches the one you configure in your STARTSHIP_CONFIG environment variable.

Step 6: Install Starship in your WSL instance

To install Starship on your WSL instance, run the following Bash script;

curl -sS https://starship.rs/install.sh | sh

Then add the following to your .bashrc file;

export STARSHIP_CONFIG=/mnt/c/Users/?/.config/starship/starship.toml
eval "$(starship init bash)"

Replace “?” with the relevant Windows “username” so that the path is valid from WSL, or modify the path to where you have your Starship TOML file saved. This means that both your Windows Terminal AND WSL instance will use the same Starship configuration file, ensuring consistency across both platforms!

Wrap Up

All of the above code & config snippets are available on my dev-machine-configuration GitHub repo.

When you open a PowerShell or WSL prompt, either from Windows Terminal or Visual Studio Code, you should now have a consistent user experience! Enjoy!

Conclusion

I hope this will be of help to you. Let me know if you have any suggestions for improvements in the comments.

Well, you would be right…and wrong. Let me explain.

Not authorized to do what?

I had this issue recently when I was trying to use Terraform to create a Private Endpoint on an Azure Key Vault to a Virtual Network Subnet that was located in a different Subscription.

Here’s the error from my Azure DevOps pipeline run.

The error was;

The client ‘’ with object id ‘’ does not have authorization to perform action ‘microsoft.network/virtualnetworks/taggedTrafficConsumers/validate/action’ over scope ‘/subscriptions/ /resourcegroups/ /providers/microsoft.network/virtualnetworks/ /taggedTrafficConsumers/Microsoft.KeyVault.northeurope’ or the scope is invalid. If access was recently granted, please refresh your credentials."

What’s the cause of this?

After a bit of Googling (or Binging?) I worked out that “/validate/action” authorization is required to register a Resource Provider in a Subscription.

Since I was working with two resource types - Virtual Networks and Key Vaults - I checked both Subscriptions, and discovered that the Subscription containing the Virtual Network did NOT have the “Microsoft.KeyVault” Resource Provider registered.

BUT….

The Service Principal being used by the Service Connection had the correct RBAC permissions on both Subscriptions, i.e. Contributor, which should be enough to register a missing Resource Provider.

You must have permission to do the /register/action operation for the resource provider. The permission is included in the Contributor and Owner roles.

Unfortunately, that will only work if you have Terraform code that is directly trying to manage a resource in a target Subscription.

In my scenario, I was setting the Private Endpoint subnet_id attribute with the Virtual Network subnet located in a different Subscription.

So, how do I fix it?

There are two solutions to this:

1. Add code that will explicitly register the required Resource Provider in the target Subscription, e.g

resource "azurerm_resource_provider_registration" "example" {
    name = "Microsoft.KeyVault"
    alias = provider.other_subscription
}

1. If you have the permissions then manually register the Resource Provider yourself on the required Subscription.

Conclusion

I hope this helps someone that experiences the same issue.

As always, if you think there is a better way this could’ve been fixed then please leave a comment below.

I recently worked with a customer that wanted to deploy a conventional DMZ environment architecture in Azure using Azure Application Gateways and Azure Firewall, leveraging the various security features of Azure Firewall Premium SKU but specifically TLS Inspection for in-bound HTTP(S) traffic.

This article specifically describes my challenges with configuring TLS Inspection in an enterprise environment.

UPDATED on 19th May 2024 after receiving a few comments and questions about Let’s Encrypt and managed private PKI.

Architecture

We’ll be using a specific architectural scenario, which is the Zero-trust network for web applications with Azure Firewall and Application Gateway, where the Azure Application Gateway sits in front of the Azure Firewall. The HTTP(S) traffic passes through those devices before getting to the backend services (API Management, App Service etc).

When looking at the end-to-end TLS connection between the user and the backend service, the following occurs:

• The user’s browser establishes a TLS connection to the Azure Application Gateway, which has a certificate configured as part of its HTTP(S) Listener. Termination of the TLS connection on the Azure Application Gateway allows it to perform Web Application Firewall (WAF) traffic inspection.
• The Azure Application Gateway creates a new TLS connection to the “backend” via the Azure Firewall. Termination of the TLS connection on the Azure Firewall allows it to perform TLS Inspection.
• The Azure Firewall creates a new TLS connection to the backend service.

To decrypt and inspect TLS traffic, Azure Firewall Premium dynamically generates certificates and presents itself to the Application Gateway as the web server. The Azure Firewall has to use an CA certificate to sign the certificates that it generates.

The certificate used by Azure Firewall for TLS Inspection has very specific requirements.

Options

There are 4 options when configuring Azure Firewall with a CA certificate to be used for TLS Inspection, according to the official Microsoft documentation Azure Firewall Premium Certificates:

1. Create your own self-signed certificate
2. Use your enterprise PKI to create an Intermediate CA certificate
3. Certificate auto-generation (via the Azure Portal)
4. Purchase a managed private PKI

I’ll go through each option, discuss some Pros and Cons, identify some limitations, and talk about some of the issues I encountered.

Option 1 - Create your own self-signed certificate

For Dev/Test environments, Microsoft suggest creating a self-signed sertificate using OpenSSL and their provided config file with either the Bash or PowerShell script to generate root CA and intermediate CA certificates that you can then use on the Azure Application Gateway and AzureFirewall resources (respectively).

OpenSSL command-line?! What about Terraform?

I’m glad you asked, because I spent a fair amount of time on this.

First of all, I tried using the azurerm_key_vault_certificate resource but eventually discovered that the azurerm provider - or rather the Azure SDK - does not support the Basic_Constraints attribute required for the certificate, which is used to set the is_ca_certitifcate and pathlength properties. These certificate attribute properties are required to allow the Azure Firewall to issue temporary certificates for the TLS connection created by the Application Gateway.

After engaging Microsoft Support, they provided confirmation from the Azure Key Vault product group that there are currently no plans to support these features in the Azure SDK.

“Don’t worry!”, I hear you cry, “You can use the Hashicorp TLS provider instead.”

Yes and no… The self_signed_cert and locally_signed_cert resources do have a is_ca_certificate property, BUT they do not support the required pathlength property. In fact, there is an outstanding, and slightly confusing, enhancement request to add max_path_length in tls_locally_signed_cert to Hashicorp’s TLS provider.

What about Let’s Encrypt?

Unfortunately, Let’s Encrypt can only issue X.509 certificates to enable HTTPS on websites, they do not issue intermediate CA certificates.

Summary:

PROs:

• Good for Dev/Test environments
• Good if you’re happy managing private keys and certificate lifecycle from the command-line using OpenSSL

CONS:

• Not a fully integrated IaC experience
• Requires additional automation to manage the certificate lifecycle
• Not recommended for Production environments

Issues:

• Neither the azurerm_key_vault_certificate, self_signed_cert or locally_signed_cert resources currently support creating the required intermediate CA certificate

Option 2 - Use your enterprise PKI to create an Intermediate CA certificate

For Production environments, Microsoft recommends deploying a certificate issued from your enterprise PKI. That is fine, so long as it complies with Microsoft’s certificate requirements and your enterprise security standards.

The latter was an issue for the customer I was working with because they DO NOT issue Intermediate CA certificates directly from their root CA. In fact, this was the certificate chain that was initially issued to the DMZ Azure Firewall;

Initial suggestions by Microsoft Support were to bundle the certificate chain to uploaded to the Application Gateway, but this did not work. They later confirmed with the Azure Firewall and Application Gateway product teams that you can only upload a single certificate, meaning the certificate chain has to be no more than one level, i.e. a single root CA certificate or a root & intermediate CA certificate.

Summary:

PROS:

• Good for Production environments
• Certificate is managed by existing operational and security processes

CONS:

• Only works if your enterprise security standards permit the issuing Intermediate CA certificates directly from your root CA

Issues:

• You can only use your enterprise PKI if the Intermediate CA certificate is issued directly from your root CA, or you use the root CA.

Option 3 - Certificate auto-generation

The Azure Portal allows you to auto-generate the required Managed Identity, Key Vault and Self-Signed Certificate on your Azure Firewall. This also includes a certificate issuance policy that will auto-renew the certificate, minimising certificate management for your security operations team.

The obvious drawbacks of this are that “vanilla” resources are created, without any of the standard operational and security configuration that your organisation may normally apply when deploying these resources, such as naming convention, Service / Private Endpoints, Certificate Contacts, Diagnostic Settings etc. So, you have to retrospectively add these modifications afterwards.

Summary:

PROS:

• Correct certificate is generated for use with Application Gateway and Azure Firewall
• Certificate will auto-renew, minimising management by security operations team

CONS:

• Resources are created with names that may not comply with your enterprise resource naming standard
• Resources are created with configuration that may not comply with your enterprise configuration and security standards
• Certificate cannot be exported for re-use elsewhere

Issues:

• The valid certificate created via the Azure Portal cannot be exported, or replicated using automation as it is not supported by the Azure SDK.

Option 4 - Purchase a managed private PKI

I’ve added this option as I had ommited it from the original article. I did discuss it with the customer but they decided against it - for the time being - as it would’ve required a load of effort from a procurement and service management perspective, as well as having to align with, or at least consider, the enterprise strategic approach to PKI, and so did not align with the project timescales.

Essentially, this option involves purchasing a managed private PKI service, such as the one from GlobalSign. This would theoretically give you a root and intermediate CA, which you could configure on your Application Gateway and Azure Firewall (respectively).

To be honest, I have not fully explored how this would technically work and there are a number of questions I didn’t have time to answer:

• Would GlobalSign issue the root CA but then you use that to issue the intermediate CA?
• Could this leverage the native Key Vault integration with Certificate Authorities?
• How much would such a service cost, and is it value for money for this specific use case? It sounds like a service that might cost a lot to procure.

Summary:

PROS:

• Provides a managed enterprise PKI service

CONS:

• May conflict with, or require alignment with, your enterprise PKI strategy
• Will require time to go through procurement and service management processes
• Potential high-cost for this specific use case

Wrap-up

Unfortunately, I don’t have a recommended one-size-fits all solution to this. All I can give you is some general guidance, and hope that some of what I’ve learned above will save you wasted effort in trying to implement a solution that is not supported or will not technically work.

My guidance is that you generate the Intermediate CA certificate using one of the following techniques, in order of preference:

1. Use your enterprise PKI if:
   1. It conforms to your enterprise security standards, and
   2. The resulting certificate adheres to Microsoft’s certificate requirements.
2. Use Microsoft’s config & script(s) for creating a self-signed sertificate if:
   1. You need to automate the creation of the certificate
   2. Your enterprise security team sign-off on the risks of this approach
3. Use the Azure Portal if:
   1. You’re not bothered about automating the certificate and the associated resources
   2. Your enterprise security team sign-off on the risks of this approach

Conclusion

I hope this will be of help to you. Let me know if you have any suggestions for improvements in the comments.