Como ativar o CredSSP

2

Estou tentando usar a opção -Authentication CredSSP ao entrar com o PowerShell (2.0) para iniciar remotamente um script que pode gravar arquivos ou configurar novos PSDrives.

Eu recebo um erro quando invoco Enter-PSSession com o CredSSP, dizendo que o computador de destino não está aprovado.

Eu habilitei o CredSSP como servidor no computador de destino e como um cliente no computador que executa o New-PSSession , com o computador delegado definido como *.

Estamos em um domínio, o DC executa o Windows Server 2008 R2 e os clientes executam o Windows 7.

No AD, ambas as estações são aprovadas quando vejo a Delegação de Propriedades- >

Eu também abri o gpedit e ativei a delegação especificando o nome do computador de destino.

Aqui está a mensagem de erro (francês):

La connexion au serveur distant a échoué avec le message d'erreur suivant : Le client WinRM ne peut pas traiter la demande. Une stratégie d'ordinateur ne permet pas la délégation des informations d'identification de l'utilisateur à l'ordinateur cible car ce dernier n'est pas approuvé. L'identité de l'ordinateur cible ne peut pas être vérifiée si vous configurez le service WSMAN pour utiliser un certificat valide à l'aide de la commande suivante : winrm set winrm/config/service '@{CertificateThumbprint="<thumbprint>"}' Sinon, vous ouvez rechercher dans l'Observateur d'événements un événement qui spécifie que le SPN suivant n'a pas pu être créé : WSMAN/<computerFQDN>. Si vous trouvez cet événement, vous pouvez manuellement créer le SPN à l'aide de setspn.exe. Si le SPN existe, mais que CredSSP ne peut pas utiliser Kerberos pour valider l'identité de l'ordinateur cible et si vous souhaitez toujours autoriser la délégation des informations d'identification de l'utilisateur à l'ordinateur cible, utilisez gpedit.msc et examinez la stratégie sui vante : Configuration de l'ordinateur -> Modèles d'administration -> Système -> Délégation d'informations d'identification -> Autoriser les nouvelles informations d'identification avec l'authentification du serveur NTLM uniquement. Vérifiez qu'elle est activée et configurée avec un SPN approprié pour l'ordinateur cible. Par exemple, pour le nom d'ordinateur cible « monserveur.domaine.com », le SPN peut être : WSMAN/monserveur.domaine.com ou WSMAN/*.domaine.com. Renouvelez la demande après ces modifications. Pour plus d'informations, voir la rubrique d'aide bout_Remote_Troubleshooting. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc eption + FullyQualifiedErrorId : PSSessionOpenFailed

Quais são os outros parâmetros que podem impedir o CredSSP?

Editar: Ok, então tenho uma solução temporária para montar uma unidade em uma PSSession remota em que o CredSSP não é permitido. Eu uso o

net use X: \xxx.xxx.xxx.xxx /user:username password

sintaxe quando estou na sessão remota (ou seja, não o cmdlet New-PSDrive). Isso parece funcionar bem, mesmo com o Invoke-Command em um computador remoto.

Mas ainda preciso habilitar o CredSSP, que me impediria de credenciais de codificação ...

    
por zrz 03.05.2013 / 14:32

1 resposta

0

Há um bug no PowerShell 2.0 (corrigido no PS 3.0): Provedor do FileSystem credenciais de suporte

It's not possible to supply alternate credentials when using any cmdlets with the FileSystem provider. Even New-PSDrive, which accepts a -Credentials parameter, won't accept it with the FileSystem provider.

The bottom line here is that the ancient NET USE command has more power than PowerShell's New-PSDrive ...

Portanto, se você estiver preso ao PS 2.0, não há como (AFAIK) forçar o New-PSDrive cmdlet a usar credenciais. Existem soluções alternativas, mas todas usam credenciais codificadas:

Uso da rede (como você já fez):

net use X: \xxx.xxx.xxx.xxx /user:username password

ou

Wscript:

$net = new-object -ComObject WScript.Network
$net.MapNetworkDrive("X:", "\server\share", $false, "domain\user", "password")
    
por 19.02.2015 / 16:50