Clear the Git commits and history from the local & remote master repository

Introduction

Why would we clear the Git commits and history from the local & remote master repository? When preparing training labs leveraging Azure DevOps and Git, I often need to do a lot of testing and experimenting to empirically get the scenarios right. That means the commit history is cluttered with irrelevant commits for the lab training I am presenting.

Clearing the Git commits and history from the local & remote master repository
Photo by Gabriel Heinzer on Unsplash

Ideally, I reset the history to start a training lab when the repository is at the right stage. The students are then not bothered by the commits of previous demos. But how can we clear the Git commits and history from the local & remote master repository?

Clear the Git commits and history from the local & remote master repository

Git is meant to keep the commit history, as are repositories like Azure DevOps. That means there is no way to reset the commit history in Azure DevOps. Git, being a very powerful and, to a certain extent, also a dangerous tool, can help you overcome this. But how to do it is not always obvious. That said, you can also shoot yourself in the foot with Git, so pay attention and be careful.

Step 1 to Clear the Git commits and history from the local & remote master repository

If you keep branches around things get complicated. For my needs, I don’t need them. To delete a branch via git we need three (3) deletes.

git push origin --delete marshipdev
git branch --delete marshipdev
git branch --delete --remotes origin/marshipdev

The above lines respectively delete:

  • The remote branch in Azure DevOps
  • The local branch
  • The local remote tracking branch

You can also delete remote branches in Azure DevOps via the GUI by selecting a branch and selecting “Delete branch” in the menu. Locally you’ll need to use Git commands or the Git GUI.

Clear the Git commits and history from the local & remote master repository

Step 2

Create a new orphaned branch

git checkout --orphan myresetbranch

The Git option –orphan creates a branch that is in a git init “like” state. That is why we have an alternative option and that is to delete the .git folder in your local repository and run git init in it. That is why i normally keep a copy around of the “perfect” situation with the .git folder removed. I can copy that to create a new local master branch by running git init. I then have that track a new remote repository that still needs initializing via:

git remote add origin  https://[email protected]/workinghardinit/InfraAsCode/_git/AzureFwChildPolMarShip


git push --set-upstream origin master

But that is not what I am doing here, I am using another method.

Step 3

On your workstation in the local repository, make sure to clean and delete or edit and add all the files and folders we want to be in our master repository initial commit.

git add -A

git commit -m “Initial commit”

Note: we use -A here instead of  “.” Because we also want to delete any tracked files and folder that are currently being tracked. At the same time, it adds new items to be tracked. In practice it is like running both git -u and git .

Step 4

Now delete the current master branch

git branch -D master

Step 5

Rename the temporary branch to “master”

git branch -m master

We now have a master repository again locally.

Step 6

We now need to update the remote repository with the option –force or -f. That allows us to delete branches and tags as well as rewrite the history. Normally that is no allowed so we nee to temporarily allow this in Azure DevOps.

Clear the Git commits and history from the local & remote master repository

Now we can run

git push -f origin master

If we had not allowed Force push the above command would fail with an error indicating we need to allow “Force push”.
TF401027: You need the Git ‘ForcePush’ permission to perform this action.

Important: do not forget to set “Force push” back to “Not set”

Step 7 to Clear the Git commits and history from the local & remote master repository

Finally, make sure that the local master branch is set up to track origin/master.

git push --set-upstream origin master

That’s it, you now have a master repository in Azure DevOps that is ready to be cloned and used for labs with a clean commit history. Student can clone it, create branches, work on that repository and they will only see their changes and commit.

Conclusion

Resetting the git commit history of a repository is not a recommend action on production repositories under normal situations. But in situations like training lab repositories, it gives me a clean commit history to start my demos from.

Connect to an Azure VM via Bastion with native RDP using only Azure PowerShell

Connect to an Azure VM via Bastion with native RDP using only Azure PowerShell

To connect to an Azure VM via Bastion with native RDP using only RDP requires a custom solution. By default, the user must leverage Azure CLI. It also requires the user to know the Bastion subscription and the resource ID of the virtual machine. That’s all fine for an IT Pro or developer, but it is a bit much to handle for a knowledge worker.

That is why I wanted to automate things for those users and hide that complexity away from the users. One requirement was to ensure the solution would work on a Windows Client on which the user has no administrative rights. So that is why, for those use cases, I wrote a PowerShell script that takes care of everything for an end user. Hence, we chose to leverage the Azure PowerShell modules. These can be installed for the current user without administrative rights if needed. Great idea, but that left us with two challenges to deal with. These I will discuss below.

A custom PowerShell Script

The user must have the right to connect to their Virtual Machine in Azure over the (central) bastion deployment. These are listed below. See Connect to a VM using Bastion – Windows native client for more information.

  • Reader role on the virtual machine.
  • Reader role on the NIC with private IP of the virtual machine.
  • Reader role on the Azure Bastion resource.
  • Optionally, the Virtual Machine Administrator Login or Virtual Machine User Login role

When this is OK, this script generates an RDP file for them on the desktop. That script also launches the RDP session for them, to which they need to authenticate via Azure MFA to the Bastion host and via their VM credentials to the virtual machine. The script removes the RDP files after they close the RDP session. The complete sample code can be found here on GitHub.

I don’t want to rely on Azure CLI

Microsoft uses Azure CLI to connect to an Azure VM via Bastion with native RDP. We do not control what gets installed on those clients. If an installation requires administrative rights, that can be an issue. There are tricks with Python to get Azure CLI installed for a user, but again, we are dealing with no technical profiles here.

So, is there a way to get around the requirement to use Azure CLI? Yes, there is! Let’s dive into the AZ CLI code and see what they do there. As it turns out, it is all Python! We need to dive into the extension for Bastion, and after sniffing around and wrapping my brain around it, I conclude that these lines contain the magic needed to create a PowerShell-only solution.

See for yourself overhere: azure-cli-extensions/src/bastion/azext_bastion/custom.py at d3bc6dc03bb8e9d42df8c70334b2d7e9a2e38db0 · Azure/azure-cli-extensions · GitHub

In PowerShell, that translates into the code below. One thing to note is that if this code is to work with PowerShell for Windows, we cannot use “keep-alive” for the connection setting. PowerShell core does support this setting. The latter is not installed by default.

# Connect & authenticate to the correct tenant and to the Bastion subscription
Connect-AzAccount -Tenant $TenantId -Subscription $BastionSubscriptionId | Out-Null

 #Grab the Azure Access token
    $AccessToken = (Get-AzAccessToken).Token
    If (!([string]::IsNullOrEmpty($AccessToken))) {
        #Grab your centralized bastion host
        try {
            $Bastion = Get-AzBastion -ResourceGroupName $BastionResoureGroup -Name $BastionHostName
            if ($Null -ne $Bastion ) {
                write-host -ForegroundColor Cyan "Connected to Bastion $($Bastion.Name)"
                write-host -ForegroundColor yellow "Generating RDP file for you to desktop..."
                $target_resource_id = $VmResourceId
                $enable_mfa = "true" #"true"
                $bastion_endpoint = $Bastion.DnsName
                $resource_port = "3389"

                $url = "https://$($bastion_endpoint)/api/rdpfile?resourceId=$($target_resource_id)&format=rdp&rdpport=$($resource_port)&enablerdsaad=$($enable_mfa)"

                $headers = @{
                    "Authorization"   = "Bearer $($AccessToken)"
                    "Accept"          = "*/*"
                    "Accept-Encoding" = "gzip, deflate, br"
                    #"Connection" = "keep-alive" #keep-alive and close not supported with PoSh 5.1 
                    "Content-Type"    = "application/json"
                }

                $DesktopPath = [Environment]::GetFolderPath("Desktop")
                $DateStamp = Get-Date -Format yyyy-MM-dd
                $TimeStamp = Get-Date -Format HHmmss
                $DateAndTimeStamp = $DateStamp + '@' + $TimeStamp 
                $RdpPathAndFileName = "$DesktopPath\$AzureVmName-$DateAndTimeStamp.rdp"
                $progressPreference = 'SilentlyContinue'
            }
            else {
                write-host -ForegroundColor Red  "We could not connect to the Azure bastion host"
            }
        }
        catch {
            <#Do this if a terminating exception happens#>
        }
        finally {
            <#Do this after the try block regardless of whether an exception occurred or not#>
        }

Finding the resource id for the Azure VM by looping through subscriptions is slow

As I build a solution for a Windows client, I am not considering leveraging a tunnel connection (see Connect to a VM using Bastion – Windows native client). I “merely” want to create a functional RDP file the user can leverage to connect to an Azure VM via Bastion with native RDP.

Therefore, to make life as easy as possible for the user, we want to hide any complexity for them as much as possible. Hence, I can only expect them to know the virtual machine’s name in Azure. And if required, we can even put that in the script for them.

But no matter what, we need to find the virtual machine’s resource ID.

Azure Graph to the rescue! We can leverage the code below, and even when you have to search in hundreds of subscriptions, it is way more performant than Azure PowerShell’s Get-AzureVM, which needs to loop through all subscriptions. This leads to less waiting and a better experience for your users. The Az.ResourceGraph module can also be installed without administrative rights for the current users.

$VMToConnectTo = Search-AzGraph -Query "Resources | where type == 'microsoft.compute/virtualmachines' and name == '$AzureVmName'" -UseTenantScope

Note using -UseTenantScope, which ensures we search the entire tenant even if some filtering occurs.

Creating the RDP file to connect to an Azure Virtual Machine over the bastion host

Next, I create the RDP file via a web request, which writes the result to a file on the desktop from where we launch it, and the user can authenticate to the bastion host (with MFA) and then to the virtual machine with the appropriate credentials.

        try {
            $progressPreference =  'SilentlyContinue'
            Invoke-WebRequest $url -Method Get -Headers $headers -OutFile $RdpPathAndFileName -UseBasicParsing
            $progressPreference =  'Continue'

            if (Test-Path $RdpPathAndFileName -PathType leaf) {
                Start-Process $RdpPathAndFileName -Wait
                write-host -ForegroundColor magenta  "Deleting the RDP file after use."
                Remove-Item $RdpPathAndFileName
                write-host -ForegroundColor magenta  "Deleted $RdpPathAndFileName."
            }
            else {
                write-host -ForegroundColor Red  "The RDP file was not found on your desktop and, hence, could not be deleted."
            }
        }
        catch {
            write-host -ForegroundColor Red  "An error occurred during the creation of the RDP file."
            $Error[0]
        }
        finally {
            $progressPreference = 'Continue'
        }

Finally, when the user is done, the file is deleted. A new one will be created the next time the script is run. This protects against stale tokens and such.

Pretty it up for the user

I create a shortcut and rename it to something sensible for the user. Next, I changed the icon to the provided one, which helps visually identify the shortcut from any other Powershell script shortcut. They can copy that shortcut wherever suits them or pin it to the taskbar.

Connect to an Azure VM via native RDP using only Azure PowerShell

Do Azure VPN Gateways that leverage BGP support BFD?

Introduction

Anyone doing redundant, high-available VPN gateways leveraging BGP (Border Gateway Protocol) has encountered BFD (Bi-Directional Forwarding Detection). That said, BFD is not limited to BGP but also works with OSPF and OSPF6. But before we answer whether Azure VPN Gateways that leverage BGP support BFD, l briefly discuss what BFD does.

Bi-Directional Forwarding Detection

The BFD (Bi-Directional Forwarding Detection) protocol provides high-speed and efficient detection for link failures. It works even when the physical link has no failure detection support itself. As such, it helps routing protocols, such as BGP, failover much quicker than they could achieve if left to their own devices.

BFD control packets are transmitted via UDP from source ports between 49152-65535 to destination port 3784 (single-hop, RFC 5880, RFC 5881, and RFC 5882) or 4784 (multi-hop, RFC 5883). It can be IPv4 as well as IPv6. See Bidirectional Forwarding Detection on Wikipedia for more information. Note that this works between directly connected routers (single-hop) or (multi-hop).

Azure VPN Gateways that leverage BGP support BFD

Currently, OPNsense and pfSense, with the FRR (Flexible Rigid Routing) plugin, support BFD integration with BGP, Open Shortest Path First (OSPF), and Open Shortest Path First version 6 (OSPF6). Naturally, most vendors support this, but I mention OPNsense and pfSense because they offer free, fully functional products that are very handy for demos and lab testing.

Do Azure VPN Gateways that leverage BGP support BFD?

TL;DR: No.

You do not find much information when you search for BFD information about Microsoft Azure networking. Only for Azure ExpressRoute does Microsoft clearly state that it is supported and provides information.

But what about Azure VPN gateways with BFD? Well, no, that is not supported at all. You can try to set it up, but your VPN Gateways on-premises is shouting into a void. The session status with the peers will always be “down.” It just won’t work.

Visualize an Always On VPN device tunnel connection while disabling the disconnect button

Visualize an Always On VPN device tunnel connection while disabling the disconnect button

The need to visualize an Always On VPN device tunnel connection while disabling the disconnect button arises when the user experiences connectivity issues. End users should be able to communicate quickly to their support desk whether or not they have a connected Always On VPN device tunnel. They usually do not see the device VPN tunnel in the modern UI. Only user VPN tunnels show up. Naturally, we don’t want them to disconnect the device VPN or change its properties, so we want to disable the “disconnect” and the “advanced setting buttons. Since a device VPN tunnel runs as a “SYSTEM,” they cannot do this anyway. The GUI shows “Disconnecting” but never complete.

Refreshing the GUI correctly shows “Connected” again. However, it makes sense to disable the buttons to indicate this. So how to we set all of this up?

Visualize an Always On VPN device tunnel connection

Visualizing the Always On VPN device tunnel in the modern GUI is something we achieve via the registry. Scripting deploying these registry settings via GPO or Intune is the way to go.

New-Item -Path ‘HKLM:\SOFTWARE\Microsoft\Flyout\VPN’ -Force
New-ItemProperty -Path ‘HKLM:\Software\Microsoft\Flyout\VPN\’ -Name ‘ShowDeviceTunnelInUI’ -PropertyType DWORD -Value 1 -Force

Disable the disconnect button and the advanced options buttons

Now that the Always On VPN device tunnel is visible in the GUI, we want to disable the disconnect button and the advanced options buttons. How? Well, we can do this in Windows 11 22H2 or more recent versions. For this, we add the following to the VPN configuration file.

<!-- The below 2 GUI settings are only available in Windows 11 22H2 or higher. --><DisableAdvancedOptionsEditButton>true</DisableAdvancedOptionsEditButton><DisableDisconnectButton>true</DisableDisconnectButton>

  <!– These GUI settings below are only available in Windows 11 22H2 or higher. –>    <DisableAdvancedOptionsEditButton>true</DisableAdvancedOptionsEditButton>    <DisableDisconnectButton>true</DisableDisconnectButton>

Visualize a device VPN tunnel connection while disabling the disconnect button

Results

For an administrative account, the Always On VPN device tunnel is visible, but the buttons are dimmed (greyed out).

As before, the administrator can still use the rasphone GUI to hang up the Always On VPN device tunnel or edit the properties like before. Usually, you’ll configure the setting with Intune or via GPO with Powershell and custom XML. There is also a 3rd party option for configuring Always On VPNs via GPO (AOVPN Dynamic Profile Configurator).

For a non-administrator user account, the GUI looks precisely the same. The big difference is that when such a user launches the rasphone GUI, they cannot “Hang Up” the connection. The error message may not be the clearest, but in the end, a user with non-administrative rights cannot disconnect the Always On VPN device tunnel.

So now we have the best of both worlds. An administrator and a standard user can see that the Always On VPN device tunnel is connected. Remember that disabling the buttons requires Windows 11 22H2 or more recent. This blog was written using 23H2. The administrator can use the rasphone GUI or rasdial CLI to access the Always On VPN device tunnel like before.

Conclusion

Device VPN tunnels are supposed to be connected at all times, whether a user is logged on or not. It is also something that users are not supposed to be concerned about in contrast to a user VPN tunnel. However, it can be beneficial to see whether the Always On VPN device tunnel is connected. That is most certainly so when talking to support about an issue. We showed you how to achieve this, combined with disabling the “disconnect” and “advanced” options buttons), in this blog post.