none
Удаленное взаимодействие через Powershell. RRS feed

  • Вопрос

  • Добрый день!

    При конфигурировании 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