SSPI sql access fails in remote powershell request due to double-hop failure, constrained delegation
Asked Answered
G

1

7

We are trying to run an automated install from serverA on remote serverB which needs to talk to sql serverC using windows authentication.

Invoke-Command -ComputerName serverB -ScriptBlock {

    $conn = new-object System.Data.SqlClient.SqlConnection 'Data Source=ServerC;Initial Catalog=master;Integrated Security=SSPI'
    try
    {
        $conn.open()
    } finally {
        $conn | Remove-SQLConnection
    }

} -Credential $cred 

However it fails returning:

Exception calling "Open" with "0" argument(s): "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'."

We worked around this issue using:

Invoke-Command -ComputerName serverB -ScriptBlock { Register-PSSessionConfiguration -Name Ipswitch -RunAsCredential $using:cred -Force  } -Credential $cred

But we would prefer to use constrained kerberos delegation:

https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-6#resource-based-kerberos-constrained-delegation

We tried using the steps to perform kerberos delegation below:

##########################
#run on serverC
##########################
Add-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory


$serverB = Get-ADComputer serverB
$serverC = Get-ADComputer serverC

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $serverC -PrincipalsAllowedToDelegateToAccount $serverB

# Check the value of the attribute directly
$x = Get-ADComputer -Identity $serverC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

# Check the value of the attribute indirectly
Get-ADComputer -Identity $serverC -Properties PrincipalsAllowedToDelegateToAccount

# purge kerberose cache
Invoke-Command -ComputerName $serverB.Name -Credential $cred -ScriptBlock {
    klist purge -li 0x3e7
}

After doing it, these 2 tests pass:

Invoke-Command -ComputerName serverB -ScriptBlock {

    Invoke-Command -ComputerName serverC -ScriptBlock {'hello world'} -Credential $using:cred
} -Credential $cred 


Invoke-Command -ComputerName serverB -ScriptBlock {

    Copy-Item '\\serverC\c$\file'

} -Credential $cred 

However the sql command still fails, and we have not been able to find a solution to it.

We found this same issue on github which seems identical, but no answer: https://github.com/PowerShell/PowerShell/issues/9331

Guidotti answered 2/8, 2019 at 17:28 Comment(6)
Are all these instances on one domain?Br
yes, all servers are in the same domain.Guidotti
Are you sure that SQL Server is using Kerberos for its default auth scheme, and not NTLM? And are you sure an SPN has been registered for the account to be delegated?Cooperman
Thanks @DavidW this gives me an avenue to investigate. i used the query: select auth_scheme from sys.dm_exec_connections where session_id=@@spid and it returns NTLM so i will follow up with our DBA about that and the SPN, when you are referring to the SPN Is that the SQL SPN or the account for remoting?Guidotti
@DavidW we were able to get this working, your comment pointed us in the right direction however i cannot award the bounty unless you post an answer. The solution was: Register SPN for sql service account using SetSPN –A MSSQLSvc/<ComputerName>.<DomainName>:1433 <AccountName> we did this for both port (1433) and named (DEMO16) we then also needed to "trust this computer for delegation to any server (Kerberos only)" on server "B" Note: we had to make sure the connection account to server "B" was from the same domain as server "C" for the scheme to show Kerberos.Guidotti
Answer posted! Glad I helped!!Cooperman
C
2

Be sure to register an SPN for the SQL service account using SetSPN –A MSSQLSvc/.:1433

Cooperman answered 20/9, 2019 at 23:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.