Лучший отвечающий
Удаленное взаимодействие через Powershell.

Вопрос
-
Добрый день!
При конфигурировании PSRemoting столкнулись с такой проблемой:
Инфраструктура состоит из нескольких доменов (к примеру dom1, dom2, dom3), между которыми организованы доверительные отношения.
В одном из доменов (к примеру dom1) было настроено рабочее место с ОС Windows 10 Enterprise 2016 LTSB (к примеру computer1), на рабочем месте произведена конфигурации для PS: enable-psremoting -force
Нам необходимо удаленно подключаться из домена dom2 с сервера с windows 2003 (к примеру server) через psremoting к ПК computer1.dom1.
С server до ПК computer1 открыт доступ к порту 5985 (HTTP - подключаться будем только по dns именам)
проверка производилась с server командой telnet ip-computer1 5985 -> доступ есть.
на server установлен пакет обновления с powershell v2.0. Внутри домена dom2 сервер легко работает через powershell+winrm с настроенными машинами, а с нужным нам computer1.dom1 никак.
Учетная запись на server прописана в локальных администраторах computer1.dom1 как dom2\учетная_запись.
При попытке подключиться к удаленному computer1 через enter-pssession computer1.dom1 у нас появляется ошибка соединения (-cred ситуации не меняет). Команда invoke-command так же не работает (указывается полное имя computer1+dom1). Изменение trustedhosts на computer1 ситуацию не поменяло (заносили имя server из dom2).
IP адрес на машинах с двух сторон нормально резолвится в dns и наоборот. Для теста отключали брандмауэр, антивирус - не помогает.
Для теста была произведена проверка работы другого пк из домена dom2 с computer1.dom1 под такой же учетной записью- работа в норме.
Появился вопрос - что нужно для того, чтобы server.dom2 мог работать с computer1.dom1?
проверка telnet ip-computer1 5985 будет в данном случае гарантом работы PS через winrm?
29 ноября 2017 г. 10:15
Ответы
-
К сожалению, настроить Global Names на DC возможности нет (администрированием DC занимаются другие люди и интереса в лишних настройках ради 1 машины (для работы через PS) у них точно не возникнет..).
Хотелось бы уйти от Hosts и работать так, как оно должно работать из коробки - по длинному имени computer1.dom1
- Помечено в качестве ответа Vitaly.L 15 декабря 2017 г. 6:53
1 декабря 2017 г. 5:31
Все ответы
-
Добрый день.
Если машина не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.
https://blogs.technet.microsoft.com/heyscriptingguy/2013/11/29/remoting-week-non-domain-remoting/
29 ноября 2017 г. 11:57 -
Добрый день! Огромное спасибо за отклик, но данная рекомендация не помогла.
Добавлял значение в трасты - результата нет, к тому же, другой комп (который мы использовали для теста) из dom2 спокойно работает с computer1.dom1 (трасты нигде не прописаны - работают доверительные отношения между доменами), а server из dom2 никак не вяжется с computer1.dom1...
29 ноября 2017 г. 18:50 -
Хм. Может с вашей 10-кой проблема какая-то? Попробуйте другую такую машину найти.29 ноября 2017 г. 19:39
-
К машине с win 10 computer1.dom1 подключается несколько машин, проверяли из домена dom2 и dom3, проблема только с server 2003 server.dom2..
ПК computer1.dom1 недавно настроен - ничего лишнего еще установить не успели :)
Попутно появился вопрос - если пк из домена dom2 спокойно подключается через winrm к computer1.dom1 даже без записей в trustedhosts, то проблема с доверительными отношениями между доменами отпадает? и как точно узнать доверяют ли домены друг другу или нет?
30 ноября 2017 г. 5:30 -
В оснастку домены и доверие заглянуть и проверить доверие, например если очень хочется. Можно и проще- аутентифицироваться на ресурсе и посмотреть свои керберос билеты командой klist. По умолчанию без явного указания командой -credential будет керберос использоваться, и проблем с аутентификацией быть не должно, как Вы и пишете в примере. Но проверить все же надо. А почему с 2003 не хочет дружить- для меня загадка пока. А не 10-ка есть в хозяйстве, чтобы проверить точно PS 2.0 соединение с 2003 на W7 скажем?30 ноября 2017 г. 5:45
-
Еще раз спасибо за отклики, удалось определить причину неработоспособности PSRemoting, но отсюда появились новые вопросы! :)
Решить проблему удалось так:
в файле hosts прописали короткий путь: computer1 (НО! без домена dom1) и сопоставили его к его IP (к IP адресного пространства dom1).
Подключение к computer1 из dom1 (от server из dom2) проходит без проблем по короткому имени:
enter-pssession computer1, хотя по всем факам и докам подключаться мы должны были бы через длинное имя пк (enter-pssession computer1.dom1, ведь ip computer1.dom1 в адресном пространстве dom2 нет).
Изначально производились проверки разрешения dns-имени в ip и наоборот (на server'е и computer1'е - все работает без проблем, сетевые настройки так же в норме).
Отсюда назрел вопрос - почему PS не работает стандартно по длинному dns имени (имя пк + домен), ведь для разрешения имени в адрес при соединении, PS использует стандартные средства операционной системы???
30 ноября 2017 г. 17:46 -
Забудьте про хостс навсегда, есть уже 10 лет как Global names.30 ноября 2017 г. 17:55
-
К сожалению, настроить Global Names на DC возможности нет (администрированием DC занимаются другие люди и интереса в лишних настройках ради 1 машины (для работы через PS) у них точно не возникнет..).
Хотелось бы уйти от Hosts и работать так, как оно должно работать из коробки - по длинному имени computer1.dom1
- Помечено в качестве ответа Vitaly.L 15 декабря 2017 г. 6:53
1 декабря 2017 г. 5:31 -
Дело хозяйское, я просто предложил. Почему так- я не знаю, может еще есть мнение у граждан.1 декабря 2017 г. 5:35
-
В любом случае - огромное спасибо за отклики!4 декабря 2017 г. 5:51
-
Не за что, приходите еще.4 декабря 2017 г. 5:59