Solving the Second Hop Problem in Azure DevOps pipelines with CredSSP

05 february 2025

Solving the Second Hop Problem in Azure DevOps pipelines with CredSSP

This article is dedicated to a common issue frequently encountered when automating infrastructure with Azure DevOps: the second hop problem. We’ll examine why this problem occurs and how to effectively resolve it to ensure seamless integration and automation.

The DevOps approach is about delivering changes and infrastructure to production environments as quickly and automatically as possible. Within the Azure DevOps pipeline, it is often necessary to automate the deployment of virtual machines, install complex applications on them, and perform configuration remotely using PowerShell scripts.

The goal of this automation is to significantly accelerate infrastructure deployment, reduce errors by eliminating manual operations, and improve the overall stability and predictability of the process.

Problem Definition

When you try to implement the above automation, you can often run into an issue known as a Second hop error. What does this mean in practice?

The second jump problem refers to the following situation:

You have logged on to ServerA.
Then from ServerA, you establish a remote connection via PowerShell to ServerB.
When you run a cmdlet on ServerB through this remote session, it attempts to access a resource located on ServerC.
However, ServerC rejects the request because the credentials passed to connect from ServerA to ServerB are not passed on from ServerB to ServerC.

This problem occurs in Azure DevOps pipelines, the agent on which the pipelines are executed is remotely connected to the virtual machine via PowerShell Remote. Thus, the agent is ServerB and the virtual machine is ServerC. This is because the standard Kerberos authentication mechanism does not allow credentials to be transferred beyond one step.

This problem is especially critical in DevOps because it breaks the concept of automation and process continuity. It often results in the need for temporary “manual workarounds,” which negatively impacts productivity and increases the likelihood of errors.

What are the ways to solve this problem?

The second hop problem can be solved in several ways:

Using CredSSP (Credential Security Support Provider).
Using Kerberos Constrained Delegation.
Pre-copying all required resources locally to the virtual machine before running the deployment.

Within DevOps, the use of CredSSP technology has become most popular because it is the most affordable solution despite some security risks.

Solving this problem with CredSSP

To solve the problem of second wadding in Azure DevOps pipeline we need to follow two steps.

The first one is Enabling CredSSP on the Azure DevOps agent.

         - task: PowerShell@2
          displayName: Enable CredSSP authentication on Client
          inputs:
            targetType: 'inline'
            script: |
              $vmdnsname = <VmDnsName>
              $vmusername = <VmUsername>
              $vmpassword = <VmPassword>
              # Enable CredSSP
              $allowedHost = "$vmdnsname".Replace("$vmdnsname".Split('.')[0],'*')
              $allowedHost
              $allowed = @("WSMAN/$allowedHost")
              Write-Host Allowed hosts: $allowed
              Enable-WSManCredSSP -Role Client -DelegateComputer $allowed -Force
              # Following is equivalent to modifying gpedit.msc > Computer > Admin > System > Credentials > AllowFreshCredentialsWhenNTLMOnly
              $key = 'hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation'
              if (!(Test-Path $key)) {
                  md $key -Force
              }
              New-ItemProperty -Path $key -Name AllowFreshCredentialsWhenNTLMOnly -Value 1 -PropertyType Dword -Force
              $key = Join-Path $key 'AllowFreshCredentialsWhenNTLMOnly'
              if (!(Test-Path $key)) {
                  md $key -Force
              }
              $istr = Get-Item -Path $key | Select-Object -ExpandProperty Property | Select-Object -Last 1
              $i = [convert]::ToInt32($istr)
              $i++
              $allowed |% {
                  New-ItemProperty -Path $key -Name $i -Value $_ -PropertyType String -Force
                  $i++
              }
              # Following is equivalent to modifying gpedit.msc > Computer > Admin > System > Credentials > AllowFreshCredentials
              $key = 'hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation'
              if (!(Test-Path $key)) {
                  md $key -Force
              }
              New-ItemProperty -Path $key -Name AllowFreshCredentialsWhenNTLMOnly -Value 1 -PropertyType Dword -Force
              $key = Join-Path $key 'AllowFreshCredentials'
              if (!(Test-Path $key)) {
                  md $key -Force
              }
              $istr = Get-Item -Path $key | Select-Object -ExpandProperty Property | Select-Object -Last 1
              $i = [convert]::ToInt32($istr)
              $i++
              $allowed |% {
                  New-ItemProperty -Path $key -Name $i -Value $_ -PropertyType String -Force
                  $i++
              }

There are steps in the above script that modify the host policy settings to allow CredSSP connectivity.

Second - Enable CredSSP authentication on the virtual machine.

Here we will assume that powershell remote on the virtual machine is already enabled. You can see how to do this in my other article.

         - task: PowerShell@2
          displayName: Enable CredSSP authentication on Server
          inputs:
            targetType: 'inline'
            script: |

              $vmdnsname = <VmDnsName>
              $vmusername = <VmUsername>
              $vmpassword = <VmPassword>
              # Convert Password
              $securePassword = ConvertTo-SecureString $vmpassword -AsPlainText -Force
              $cred = New-Object System.Management.Automation.PSCredential($vmusername, $securePassword)
              # Connect to the machine
              $soptions = New-PSSessionOption -SkipCACheck
              $session = New-PSSession -ComputerName $vmdnsname -Port 5986 -Credential $cred -SessionOption $soptions -UseSSL
              Invoke-Command -Session $session -ScriptBlock {
                Enable-WSManCredSSP -Role "Server" -Force
              }

You can then connect using CredSSP and execute commands on the virtual machine.

         - task: PowerShell@2
          inputs:
            targetType: 'inline'
            script: |
              $vmdnsname = <VmDnsName>
              $vmusername = <VmUsername>
              $vmpassword = <VmPassword>
              # Convert Password
              $securePassword = ConvertTo-SecureString $vmpassword -AsPlainText -Force
              $cred = New-Object System.Management.Automation.PSCredential($vmusername, $securePassword)
              # Connect to the machine
              $soptions = New-PSSessionOption -SkipCACheck
              $session = New-PSSession -ComputerName $vmdnsname -Port 5986 -Credential $cred -SessionOption $soptions -UseSSL –Authentication CredSSP
              Invoke-Command -Session $session -ScriptBlock {
                echo "Hello from Azure DevOps!
              }

Thus, the use of CredSSP solves the second hop problem and provides maximum automation and efficiency in CI/CD processes, eliminating the need for manual interventions and significantly accelerating the infrastructure deployment process in Azure DevOps.