Назад | Перейти на главную страницу

Удаленное взаимодействие PowerShell с односторонним доверием

Мой вопрос похож на Удаленное взаимодействие Powershell: одностороннее довериеОднако есть различия, и разрешение (добавление сервера в список доверенных) не работает для меня.

Сценарий:
У меня два домена. DOMAIN и DOMAINDMZ. DOMAIN получает входящее доверие от DOMAINDMZ. То есть DOMAINDMZ доверяет DOMAIN, но не наоборот.

У меня есть административный пользователь DOMAIN\myadmin который входит в локальную группу администраторов на нескольких серверах в домене DOMAINDMZ: servera.domaindmz.com, serverb.domaindmz.com, serverc.domaindmz.comи т.д. Я могу войти на эти серверы с помощью DOMAIN \ myadmin с консоли или RDP.

Я пытаюсь войти в SERVERA и запустить сценарий PowerShell на SERVERB с помощью удаленного взаимодействия PowerShell. Удаленное управление включено на SERVERB. Я запускаю сеанс PowerShell с повышенными привилегиями на SERVERA, а затем пытаюсь использовать Invoke-Command командлет. Я получаю следующую ошибку:

PS C:\Windows\system32> Invoke-Command -ComputerName serverb.domaindmz.com -ScriptBlock {hostname}    
[serverb.domaindmz.com] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.
     Possible causes are:
      -The user name or password specified are invalid.
      -Kerberos is used when no authentication method and no user name are specified.
      -Kerberos accepts domain user names, but not local user names.
      -The Service Principal Name (SPN) for the remote computer name and port does not exist.
      -The client and remote computers are in different domains and there is no trust between the two domains.
     After checking for the above issues, try the following:
      -Check the Event Viewer for events related to authentication.
      -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
     Note that computers in the TrustedHosts list might not be authenticated.
       -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
        + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
        + FullyQualifiedErrorId : PSSessionStateBroken

Если я предоставлю объект учетных данных, содержащий пользователя в домене DOMAINDMZ, ошибка исчезнет, ​​и блок сценария выполнится, как ожидалось:

PS C:\Windows\system32> Invoke-Command -ComputerName serverb.domaindmz.com -Credential DOMAINDMZ\Administrator -ScriptBlock {hostname}
SERVERB

Вопрос:
Учитывая ошибку, я подозреваю, что проблема связана с доверием и Kerberos, но я не понимаю, что я могу сделать, чтобы решить. Должен ли я устанавливать SPN для DOMAIN \ myadmin или SERVERB? Можно еще что-нибудь попробовать?

Как сказал Joeqwerty, обычно считается, что вы собираетесь использовать NTLM-аутентификацию с внешним доверием и Kerberos с доверием леса.

Тем не менее, аутентификацию Kerberos можно заставить работать с внешним доменом, но есть условия.

Доверие должно быть создано с использованием полного доменного имени (FQDN). Ссылка Kerberos не выполняется, если полное доменное имя отсутствует в объекте доверенного домена.

Синтаксис имени пользователя - UPN, а суффикс UPN разрешается в DC в DNS (неявное UPN)

Порты UDP 389, UDP / TCP 88 и UDP / TCP 464 открыты для контроллеров домена в пользовательском домене.

Имя сервера в домене доверенного ресурса должно быть полным доменным именем, а суффикс домена имени сервера должен соответствовать полному доменному имени DNS домена AD DS.

Если после этого у вас по-прежнему возникает сильная изжога, я бы порекомендовал перейти на аутентификацию с согласованием, защищенную с помощью SSL.

Дополнительная литература / ссылки:

http://technet.microsoft.com/en-us/library/dd560679(WS.10).aspx

http://jorgequestforknowledge.wordpress.com/2011/09/07/kerberos-authentication-over-an-external-trust-is-it-possible-part-1/