DotNetVersionLister icon indicating copy to clipboard operation
DotNetVersionLister copied to clipboard

WinRM SPN Issue workaround

Open garetjax67 opened this issue 4 years ago • 2 comments

As described in this posting WinRM does not allow connections if the HTTP/ SPN is registered with a domain account vs computer account. https://social.technet.microsoft.com/Forums/windows/en-US/a4c5c787-ea65-4150-8d16-2a19c569a589/enterpssession-winrm-cannot-process-the-request-kerberos-authentication-error-0x80090322?forum=winserverpowershell

You can workaround this issue with your module if you: On the offending computer create port specific SPNs: SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME

The modify your module like this (I am sure you can find a more graceful way): ~line 311 Try{ $DotNetData.$Computer = Invoke-Command @PSRSplat #-ComputerName $Computer -ScriptBlock (Get-Item function:\SetDataHashObject).ScriptBlock ` #-ArgumentList $Computer, $true -ErrorAction Stop # -Verbose:$(if ($VerbosePreference -match 'Stop|Continue') { $true } else { $false }) } catch { Try{ $SessionOptions = New-PSSessionOption -IncludePortInSPN $session = New-PSSession -Computername $computer -SessionOption $SessionOptions -Credential $Credential $DotNetData.$Computer = Invoke-Command -Session $session -ScriptBlock (Get-Item function:\SetDataHashObject).ScriptBlock -ArgumentList $Computer, $true -ErrorAction Stop Remove-PSSession $session } catch{ $DotNetData.$Computer | Add-Member -MemberType NoteProperty -Name Error -Value "PSRemoting Port failure: $_" } }

garetjax67 avatar Dec 27 '19 16:12 garetjax67

I don't feel like it's within the scope of my module to do this, but not sure. I wouldn't be setting up the SPNs (didn't read the Technet post (yet), but assuming those commands do a sensible thing), but only allowing for -IncludePortInSPN, unknown to me at this point, so maybe...

Also not sure if it should be parameterized or default fallback behavior. This is why my answer has lingered. Sharing initial thoughts. If it's default fallback behavior here, then it should be in every script that uses PowerShell remoting, I guess... (then Microsoft might as well implement it themselves by default?). I'm not sure.

How common is this "SPN" issue globally, I wonder? More questions than answers here, I'm afraid. I can always implement the code, but should I? Your method seems OK enough with regards to code quality/sanity, btw, except for a few details I would handle differently. A nested try/catch block (I don't recall using "finally {}" yet, heh) would probably be the easiest at least.

You might want to read up on GitHub syntax, you can post a code block much more readable than that.

A minor stylistic detail in the code is that $($var).$($var2) is something I think is better written without two subexpressions, but rather by delimiting with the "variable name delimiters": brackets (no idea what the official term is, maybe I just invented it). Like this: ${var}.${var2}.

EliteLoser avatar Jan 27 '20 11:01 EliteLoser

(I know you don't need the variable name delimiters with a period, as it's not an allowed variable name character and parsed as a literal period in the string "$var1.$var2")

EliteLoser avatar Oct 10 '22 20:10 EliteLoser