Impossibile ottenere l'autenticazione CredSSP per funzionare in PowerShell

Nel tentativo di creare uno script PowerShell usando il telecomando mi sono imbattuto in quello che credo sia il problema del doppio hop . In quell'articolo, Perriman fornisce una descrizione sintetica del problema, nonché i passaggi specifici per risolverlo (quasi banale se si conoscono i comandi, ma per qualcuno meno familiare come me, quell'informazione era preziosa!).

Ho eseguito Enable-WSManCredSSP Serversul mio server Win7 senza incidenti, ma il tentativo di esecuzione Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>sul mio client Win7 ha generato questo errore:

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".

L'esecuzione di winrm quickconfig ha confermato che il mio server eseguiva WinRM:

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

E Get-WSManCredSSP ha confermato che il mio server era pronto ad accettare le credenziali da un client:

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

Ho anche trovato l' articolo di Boessen su WinRM in cui descrive la configurazione generale di WinRM e ho trovato un bocconcino per ottenere un utile punto di dati nella diagnosi; questo comando eseguito sul client utilizza lo strumento winrs per accedere in remoto al server:

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

Quel comando ha restituito il risultato atteso, il contenuto della directory principale sul server, senza incidenti, confermando che il mio FQDN è corretto e che WinRM è abilitato.

Boessen indica che la porta 5985 è l'impostazione predefinita per Win7; questo comando eseguito sul server conferma un valore di 5985:

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

La domanda: Perché non riesco a eseguire il comando Enable-WSManCredSSP sul lato client?

Aggiornamento 2011.06.07

Ho trovato una soluzione alla domanda sopra: invocare Enable-PSRemoting , pubblicizzato per configurare un computer per ricevere comandi remoti, ha permesso a Enable-WSManCredSSP sul client di funzionare correttamente! Curioso, ma la sua pagina man indica che fa una serie di azioni diverse, quindi presumo che uno di quelli abbia inavvertitamente fatto ciò di cui avevo bisogno.

Ma poi ho raggiunto un altro blocco quando ho tentato di utilizzare l'autenticazione CredSSP. Ecco il comando:

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

Ed ecco la risposta:

La connessione al server remoto non è riuscita con il seguente messaggio di errore:
Il client WinRM non può elaborare la richiesta. Un criterio informatico non consente
la delega delle credenziali dell'utente al computer di destinazione. Usa gpedit.msc
e osserva il seguente criterio: Configurazione computer
-> Modelli amministrativi -> Sistema -> Delega credenziali
-> Consenti delega di nuove credenziali. Verifica che sia abilitato e
configurato con un nome SPN appropriato per il computer di destinazione. Per esempio,
per un nome di computer di destinazione "myserver.domain.com", l'SPN può essere uno dei
quanto segue: WSMAN /myserver.domain.com o WSMAN / *. domain.com.
Per ulteriori informazioni, consultare l'argomento della guida about_Remote_Tro troubleshooting.

Ho verificato le impostazioni proprio come suggerito da questo messaggio di errore straordinariamente utile, e mi sembra che sia configurato correttamente.

La nuova domanda: cosa fallisce questa connessione remota con CredSSP?

Nel rispondere, ti preghiamo di tenere presente quanto segue: Fammi dissipare in anticipo qualsiasi idea che io sappia cosa sto facendo qui, nonostante qualsiasi aspetto contrario. :-) L'amministratore di Windows non è la mia area di competenza!

Sono tornato a questo dopo una breve pausa per guardare di nuovo con occhi nuovi (sia il mio che un collega) e ho deciso di tornare di nuovo alle basi:

Sul client che ho eseguito (nella shell dell'amministratore):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

Sul server che ho eseguito (nella shell dell'amministratore):

enable-wsmancredssp -role server -force

Entrambi hanno restituito un output normale indicando che CredSSP era ora "vero".

Ho quindi usato il seguente codice di allenamento per superare i livelli crescenti di complessità:

$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 }
      }
}

Tutto questo è nel mio script run.ps1, quindi la trascrizione è stata la seguente (e questa è stata eseguita in una shell non amministratore):

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

In precedenza, funzionavano solo di base, remoti e credenziali. Ora tutti e 5 funzionano. Meno male!

Quando ho dovuto farlo, questo è quello che ho fatto per farlo funzionare (potrebbero esserci state anche alcune impostazioni dell'oggetto Criteri di gruppo, ma sembra che tu ne abbia coperti).

Per consentire al CLIENTE di utilizzare CredSSP per connettersi a qualsiasi macchina nel dominio:

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"

Quindi ho eseguito quanto segue su ogni macchina di destinazione (server) per abilitare l'autenticazione CredSSP:

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

Questo ovviamente richiede che tu stia eseguendo lo script con le autorizzazioni appropriate. Questo ha funzionato per me - spero che ti aiuti.

Sono arrivato dove avrei potuto migrare una macchina virtuale da un server hyper-v 2012R2 a un altro, ma non sono riuscito a migrare indietro. (Sto cercando di utilizzare SAMBA 4.2 come controller di dominio e volevo vedere se potevo vivere migrare con CredSSP poiché non potevo usare la delega vincolata con Samba4).

Alla fine sono andato all'hyper-v funzionante e ho copiato le voci di registro su hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation all'hyper-v non funzionante. Dopo ha funzionato bene in entrambi i modi.