На даний момент я намагаюся ввімкнути віддалене управління Windows (зокрема, видалення Powershell) між двома недовірливими доменами, і мені не пощастило.
Короткий опис моєї настройки:
- domain1 - моя робоча станція знаходиться в цьому домені
- domain2 - сервер, до якого я хочу підключитися, знаходиться на цьому домені
Немає довіри між цими доменами.
Я намагаюся створити віддалене з'єднання Powershell за допомогою наступних команд зі своєї робочої станції (приєднався до домену1):
парам (
[Параметр (обов'язковий = $ True)]
$ сервер
)
$ username = "домен \ користувач"
$ password = read-host "Введіть пароль для $ username" -AsSecureString
$ poverljivi = Новий об'єкт System.Management.Automation.PSCredential ($ ім'я користувача, $ пароль)
$ session = New-PSSession "$ server" -Authentication CredSSP -Credential $ mandaster -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $ session
Результатом якого є таке повідомлення про помилку:
New-PSSession: [computername.domain2.com] Не вдалося підключитися до віддаленого сервера computername.domain2.com із таким повідомленням про помилку: Клієнт WinRM
не може обробити запит. Комп'ютерна політика не дозволяє делегувати облікові дані користувачів на цільовий комп'ютер, оскільки комп'ютеру не довіряють. Ідентифікація цілі
комп'ютер може бути перевірений, якщо ви налаштуєте службу WSMAN для використання дійсного сертифіката за допомогою наступної команди: winrm встановити winrm / config / service '@ {CertificateThumbprint = ""}' Або
ви можете перевірити переглядач подій на предмет події, яка вказує на те, що неможливо створити наступний SPN: WSMAN /. Якщо ви знайдете цю подію, можете вручну створити SPN за допомогою
setspn.exe. Якщо SPN існує, але CredSSP не може використовувати Kerberos для підтвердження ідентичності цільового комп'ютера, і ви все одно хочете дозволити делегування облікових даних користувачів цільовій
на комп'ютері, використовуйте gpedit.msc і перегляньте таку політику: Конфігурація комп'ютера -> Адміністративні шаблони -> Система -> Делегування облікових даних -> Дозволити свіжі облікові дані лише для NTLM
Аутентифікація сервера Перевірте, чи ввімкнено та налаштовано SPN, відповідний для цільового комп'ютера. Наприклад, для назви цільового комп'ютера "myserver.domain.com" SPN може бути
одне з наступних: WSMAN / myserver.domain.com або WSMAN / *. domain.com. Повторіть запит після цих змін. Для отримання додаткової інформації див. Тему довідки about_Remote_Troubleshooting.
Я спробував / перевірив такі речі:
- Я переконався, що SPN існує для WSMAN \ ім'я комп’ютера та WSMAN \ computername.domain2.com у домені2.
- Перевірено, що конфігурація комп’ютера -> адміністративні шаблони -> система -> делегування облікових даних -> дозволити свіжі облікові дані з автентифікацією сервера лише для NTLM.
- Налаштований winrm на цільовому комп'ютері для використання ssl.
- Налаштуйте CredSSP на цільовому комп'ютері та моїй локальній робочій станції за допомогою наступних команд:
Увімкнути-WSManCredSSP-сервер № ролі на цільовому комп'ютері Увімкнути-WSManCredSSP -Ротовий клієнт -DelegateComputer * -Force
- Я переконався, що ніякі правила FW, локальні для комп’ютерів або мережі, не блокують мій доступ.
Жоден з яких не дозволив мені успішно підключитися до цільового комп’ютера в домені2 зі своєї робочої станції в домені1. Я можу успішно підключитися до інших серверів, які приєднані до domain1, тільки не до серверів у domain2. Чи є ще щось, що я повинен шукати та / або намагатися змусити це працювати?
ОНОВЛЕННЯ 06.08.2015. Насправді мені вдалося переконатися, що я можу підключитися до сервера зі своєї робочої станції без використання CredSSP, що було б добре; однак мені потрібно мати можливість запускати сценарії проти SharePoint, і це робити без CredSSP не вдається з помилкою дозволу.
Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , пункт 3.)