私は現在、2つの信頼できないドメイン間でWindowsリモート管理(具体的には、Powershell Remoting)を有効にしようとしていますが、うまくいきません。
私のセットアップの簡単な説明:
これらのドメイン間に信頼関係はありません。
(domain1に参加している)ワークステーションから次のコマンドを使用して、Powershellリモート接続を作成しようとしています。
param( [Parameter(Mandatory = $ True)] $ server ) $ username = "domain\user " $ password = read-Host" Enter Password for $ username "-AsSecureString $ credential = New-Object System.Management.Automation.PSCredential($ username、$パスワード) $ session = New-PSSession "$ server" -Authentication CredSSP -Credential $ credential -UseSSL -SessionOption(New-PSSessionOption -SkipCACheck -SkipCNCheck) Enter-PSSession $ session
その結果、次のエラーメッセージが表示されます。
New-PSSession:[computername.domain2.com]リモートサーバーcomputername.domain2.comへの接続が次のエラーメッセージで失敗しました:WinRMクライアント が要求を処理できません。コンピューターが信頼されていないため、コンピューターポリシーでは、ターゲットコンピューターへのユーザー資格情報の委任を許可していません。次のコマンドを使用して有効な証明書を使用するようにWSMANサービスを構成すると、ターゲット コンピューターのIDを確認できます。winrm set winrm/config/service '@ {CertificateThumbprint = ""}'または イベントビューアで、次のSPNを作成できなかったことを示すイベントを確認できます:WSMAN /。このイベントが見つかった場合は、 setspn.exeを使用して手動でSPNを作成できます。 SPNは存在するが、CredSSPがKerberosを使用してターゲットコンピューターのIDを検証できない場合でも、ユーザーの資格情報のターゲット コンピューターへの委任を許可するには、gpedit.mscを使用して次のポリシーを確認します:コンピューターの構成->管理用テンプレート->システム->資格情報の委任-> NTLMのみで新しい資格情報を許可 サーバー認証。ターゲットコンピュータに適したSPNで有効化および構成されていることを確認します。たとえば、ターゲットコンピュータ名が "myserver.domain.com"の場合、SPNは 次のいずれかになります。WSMAN/ myserver.domain.comまたはWSMAN/*。domain.com。これらの変更後、要求を再試行してください。詳細については、about_Remote_Troubleshootingヘルプトピックを参照してください。
私は次のことを試しました/検証しました:
Enable-WSManCredSSP -Role Server #on the target computer Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
Domain1のワークステーションからdomain2のターゲットコンピュータに正常に接続できなかったものはありません。 domain2のサーバーではなく、domain1に参加している他のサーバーに正常に接続できます。他に何かを探したり、これを機能させたりする必要があるでしょうか?
2015年6月8日更新実際に、CredSSPを使用せずにワークステーションからサーバーに接続できることを確認できました。ただし、SharePointに対してスクリプトを実行できる必要があるため、CredSSPを使用せずに実行すると、アクセス許可エラーが発生して失敗します。
この [〜#〜] msdn [〜#〜] の記事は、マルチホップサポート用のWinRMを構成する方法を示しています。これは、Kerberosがオプションではない場合の接続の作成にも対応しています。以下の簡単な要約。
Windowsリモート管理(WinRM)は、複数のリモートコンピューター間でのユーザー資格情報の委任をサポートしています。マルチホップサポート機能で、認証にCredential Security Service Provider(CredSSP)を使用できるようになりました。 CredSSPを使用すると、アプリケーションはユーザーの資格情報をクライアントコンピューターからターゲットサーバーに委任できます。
CredSSP認証は、Kerberos委任を使用できない環境を対象としています。 CredSSPのサポートが追加され、ユーザーがリモートサーバーに接続して、ファイル共有などのセカンドホップマシンにアクセスできるようになりました。
具体的には、レジストリエントリ/グループポリシー設定に関する記事のセクションAllowFreshCredentialsWhenNTLMOnlyで、私が抱えていた問題が解決しました。記事から:
Kerberos認証も証明書の拇印も使用できない場合、ユーザーはNTLM認証を有効にできます。 NTLM認証を使用する場合は、NTLMのみのサーバー認証でフレッシュクレデンシャルを許可する(AllowFreshCredentialsWhenNTLMOnly)ポリシーを有効にし、WSMANプレフィックスを持つSPNをポリシーに追加する必要があります。資格情報は認証されていないサーバーに送信されるため、この設定はKerberos認証と証明書の拇印よりも安全性が低くなります。
AllowFreshCredentialsWhenNTLMOnlyポリシーの詳細については、グループポリシーエディターおよびKB 951608によって提供されるポリシーの説明を参照してください。AllowFreshCredentialsWhenNTLMOnlyポリシーは、コンピューターの構成\管理用テンプレート\システム\クレデンシャルの委任にあります。