2

Я пытаюсь использовать -Authentication CredSSP при входе в PowerShell (2.0) для удаленного запуска сценария, который может записывать в файлы или устанавливать новые PSDrive.

Я получаю сообщение об ошибке, когда я вызываю Enter-PSSession PSSession с CredSSP, говоря, что целевой компьютер не одобрен.

Я включил CredSSP в качестве сервера на целевом компьютере и в качестве клиента на компьютере, который выполняет New-PSSession , для компьютера-делегата установлено значение *.

Мы находимся в домене, DC работает под управлением Windows Server 2008 R2, клиенты работают под управлением Windows 7.

В AD обе станции утверждены, когда я смотрю на Свойства-> Делегирование.

Я также открыл gpedit и активировал делегирование, указав имя целевого компьютера.

Вот сообщение об ошибке (французский):

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

Какие другие параметры могут помешать CredSSP?

Редактировать: Хорошо, поэтому у меня есть временный обходной путь для монтирования диска в удаленном сеансе PSSession, где CredSSP не разрешен. Я использую

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

синтаксис, когда я нахожусь в удаленном сеансе (то есть не командлет New-PSDrive). Кажется, это работает нормально, даже с Invoke-Command на удаленном компьютере.

Но все равно нужно включить CredSSP, что помешало бы мне жестко кодировать учетные данные ...

1 ответ1

0

В PowerShell 2.0 есть ошибка (исправлена в PS 3.0): поставщик файловой системы должен поддерживать учетные данные

Невозможно предоставить альтернативные учетные данные при использовании каких-либо командлетов с поставщиком FileSystem. Даже New-PSDrive, который принимает параметр -Credentials, не примет его с поставщиком FileSystem.

Суть в том, что древняя команда NET USE обладает большей мощностью, чем PowerShell New-PSDrive ...

Так что, если вы застряли с PS 2.0, невозможно (AFAIK) заставить командлет New-PSDrive использовать учетные данные. Обходные пути существуют, но все они используют жестко закодированные данные:

Чистое использование (как вы уже сделали):

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

или же

Wscript:

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .