web-dev-qa-db-ja.com

PowerShellでCredSSP認証が機能しない

リモート処理を使用してPowerShellスクリプトを作成しようとすると、 ダブルホップ問題 であると私が思うことに遭遇しました。その記事では、Perrimanが問題の簡潔な説明と問題を解決するための具体的な手順を説明しています（コマンドを知っていればほとんど簡単ですが、私のようにあまり知られていない人にとっては、その情報は非常に貴重です！）。

私は走ったEnable-WSManCredSSP Server Win7サーバーで問題なく、実行しようとしましたEnable-WSManCredSSP Client –DelegateComputer <FQDN of the server> Win7クライアントでこのエラーが発生しました：

Enable-WSManCredSSP : The client cannot connect to the destination specified
in the request. Verify that the service on the destination is running and
is accepting requests.
Consult the logs and documentation for the WS-Management service running
on the destination, most commonly IIS or WinRM. If the destination
is the WinRM service, run the following com mand on the destination
to analyze and configure the WinRM service: "winrm quickconfig".

winrm quickconfigを実行すると、サーバーでWinRMが実行されていることが確認されました。

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

そしてGet-WSManCredSSPは、サーバーがクライアントからの資格情報を受け入れる準備ができていることを確認しました：

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

私はBoessenの WinRMに関する記事 も見つけました。ここで、彼は一般的なWinRMセットアップについて説明し、診断に役立つデータポイントを取得するためのヒントを1つ見つけました。このコマンドをクライアントで実行すると、winrsツールを使用してサーバーにリモートアクセスします。

winrs -r:http://<FQDN of my server>:5985 -u:<myDomain>\msorens "dir c:\"

そのコマンドは、予期した結果、サーバー上のルートディレクトリの内容を問題なく返し、FQDNが正しく、WinRMが有効になっていることを確認しました。

Boessenは、ポート5985がWin7のデフォルトであることを示しています。サーバーで実行されるこのコマンドは、5985の値を確認します。

get-item wsman:\localhost\listener\listener*\port

質問：クライアント側でEnable-WSManCredSSPコマンドを実行できないのはなぜですか？

2011.06.07アップデート

上記の質問に対する解決策を見つけました：Enable-PSRemotingを呼び出し、コンピューターをreceiveリモートコマンド。クライアントでEnable-WSManCredSSPが正常に機能することを許可しました！好奇心が強いが、その man page はさまざまなアクションを実行することを示しているため、そのうちの1つが誤って必要な処理を行ったと想定します。

しかし、CredSSP認証を使用しようとしたときに、別の障害に到達しました。コマンドは次のとおりです。

Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred  -Authentication Credssp

そしてここに応答があります：

リモートサーバーへの接続が次のエラーメッセージで失敗しました：
 WinRMクライアントは要求を処理できません。コンピュータポリシーでは、
ターゲットコンピュータへのユーザー資格情報の委任は許可されていません。 gpedit.msc 
を使用して、次のポリシーを確認します。コンピュータの構成
->管理用テンプレート->システム->資格情報の委任
->許可に新しい資格情報の委任を許可します。ターゲットコンピュータに適切なSPNで有効になっており、
構成されていることを確認します。たとえば、
ターゲットコンピュータ名「myserver.domain.com」の場合、SPNは
次のいずれかになります。WSMAN/myserver.domain.comまたはWSMAN/*。domain.com 。
詳細については、about_Remote_Troubleshootingヘルプトピックを参照してください。

この非常に役立つエラーメッセージが示唆するように、設定を確認しましたが、適切に構成されているように見えます。

新しい質問：CredSSPを使用したこのリモート接続の試行は何が失敗しますか？

ここで私が何をしているのかを理解していることを事前に払拭し、それとは逆にどのような外観であっても、事前に払拭しましょう。:-) Windows管理者は私の専門分野ではありません。 ！

powershellwinrmremotingcredssp
10
Michael Sorens

私は短い休止期間の後にこれに戻って、新鮮な目（私の同僚と同僚の両方）でもう一度見て、再び基本に戻ることにしました。

クライアントで（管理者シェルで）実行しました：

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

（管理者シェルで）私が実行したサーバーで：

enable-wsmancredssp -role server -force

どちらも、CredSSPが「true」であることを示す通常の出力を返しました。

次に、次のエクササイザーコードを使用して、複雑さのレベルを上げていきました。

$block = {
  Write-Host ("hello, world: {0}, {1}" -f $env:USERNAME, (hostname))
}
$username = "test_user"
$password = "..."   
$adjPwd = $password | ConvertTo-SecureString -asPlainText -Force
$testCred = (New-Object System.Management.Automation.PSCredential($username,$adjPwd))    

switch ($choice)
{
  "basic"       { Invoke-Command $block }
  "remote"      { Invoke-Command $block -computername $serverName }
  "credentialA" { Invoke-Command $block -computername $serverName -credential $testCred  }
  "credentialB" { Invoke-Command $block -computername $serverName -credential $testCred  -Authentication Credssp}
  "session"     { 
      $testSession = New-PSSession -computername $serverName -credential $testCred -Authentication Credssp
      if ($testSession) { Invoke-Command $block -Session $testSession; Remove-PSSession $testSession }
      }
}

これらすべてが私のrun.ps1スクリプトにあるため、トランスクリプトは次のようになりました（これはnon-administratorシェルで実行されました）。

PS C:\> .\run.ps1 basic
hello, world: msorens, MyLocalMachine
PS C:\> .\run.ps1 remote MyRemoteServer
hello, world: msorens, MyRemoteServer
PS C:\> .\run.ps1 credentialA MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 credentialB MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 session MyRemoteServer
hello, world: test_user, MyRemoteServer

以前は、basic、remote、credentialAのみが機能していました。これで5つすべてが動作します。ふew！

8
Michael Sorens

私がこれをしなければならなかったとき、これはそれを機能させるために私がやったことです（GPO設定もいくつかあったかもしれませんが、それらはカバーされているようです）。

クライアントがCredSSPを使用してドメイン内の任意のマシンに接続できるようにするには：

Enable-WSManCredSSP -Role Client -DelegateComputer "*.my.domain.com" -Force | out-null
#the following is used because -delegatecomputer (above) doesn't appear to actually work properly.
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain -Name WSMan -Value "WSMAN/*.my.domain.com"

次に、各ターゲットマシン（サーバー）で以下を実行して、CredSSP認証を有効にしました。

Connect-WSMan -ComputerName $computer 
Set-Item "WSMAN:\$computer\service\auth\credssp" -Value $true

もちろん、これには、適切な権限でスクリプトを実行している必要があります。これは私にとってはうまくいきました。

2
jbsmith

VMを1つのhyper-v 2012R2サーバーから別のサーバーに移行できますが、元に戻すことができませんでした。ドメインコントローラーとしてSAMBA 4.2を使用しようとして、 Sambaで制約付き委任を使用できなかったため、CredSSPでライブ移行できるかどうかを確認します4）。

最終的に、私は作業中のhyper-vに移動し、hklm：\ SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegationにあるレジストリエントリを作業していないhyper-vにコピーしました。その後、両方の方法で問題なく動作しました。

1
Bruce