Меню

Trustedhosts winrm как настроить



Настройка WINRM для HTTPS

В этой статье предоставляется решение для настройки WINRM для HTTPS.

Оригинальная версия продукта: Windows 10 — все выпуски
Исходный номер КБ: 2019527

Общая информация

По умолчанию WinRM использует Kerberos для проверки подлинности, поэтому Windows никогда не отправляет пароль в систему с запросом проверки. Чтобы получить список параметров проверки подлинности, введите следующую команду:

Целью настройки WinRM для HTTPS является шифрование данных, отосланных по всему проводу.

WinRM HTTPS требует локального сертификата проверки подлинности сервера на компьютере с cn, совпадающий с установленным имям хост-сервера. Сертификат не должен быть просрочен, отозван или подписан самостоятельно.

Установка или просмотр сертификатов для локального компьютера:

  1. Выберите Начните, а затем выберите Run (или с помощью комбинации клавиатуры нажмите клавишу Windows+R)。
  2. Введите MMC и нажмите кнопку Ввод.
  3. Выберите Файл из параметров меню, а затем выберите Добавить или Удалить snap-ins.
  4. Выберите Сертификаты и выберите Добавить.
  5. Перейдите через мастер выбора учетной записи Компьютера.
  6. Установка или просмотр сертификатов по сертификатам (локальному компьютеру) > >Персональные сертификаты.

Если у вас нет сертификата проверки подлинности сервера, обратитесь к администратору сертификата. Если у вас есть сервер сертификатов Майкрософт, вы можете запросить сертификат с помощью шаблона веб-сертификата из HTTPS:// /certsrv .

После установки сертификата введите следующее, чтобы настроить WINRM для прослушивания https:

Если у вас нет соответствующего сертификата, можно выполнить следующую команду с помощью методов проверки подлинности, настроенных для WinRM. Однако данные не будут зашифрованы.

Дополнительные сведения

По умолчанию WinRM HTTP использует порт 80. В Windows 7 и выше значение порта по умолчанию составляет 5985.

По умолчанию WinRM HTTPS использует порт 443. В Windows 7 и выше порт по умолчанию — 5986.

Чтобы подтвердить, что WinRM прослушивает HTTPS, введите следующую команду:

Чтобы подтвердить установку сертификата компьютера, используйте надстройки MMC Certificates или введите следующую команду:

Если вы получите следующее сообщение об ошибке:

Номер ошибки: -2144108267 0x80338115
ProviderFault
WSManFault
Сообщение = Невозможно создать прослушиватель WinRM в HTTPS, так как у этой машины нет соответствующего сертификата.

Чтобы использоваться для SSL, сертификат должен иметь CN, соответствующий имени хост-сервера, быть подходящим для проверки подлинности сервера и не быть истекшим, отозванным или самозаверяться.

Откройте надстройку MMC сертификатов и подтвердив правильность следующих атрибутов:

  • Дата компьютера падает между допустимым от: до даты To: даты на вкладке General.
  • Имя хоста совпадает с выданным: на вкладке General или совпадает с одним из альтернативных имен субъекта точно так же, как отображается на вкладке Details.
  • Что расширенное использование ключей на вкладке Details содержит проверку подлинности Сервера.
  • На вкладке Путь сертификации, что текущий статусэто сертификат ОК.

Если установлено несколько локальных сертификатов сервера учетных записей компьютеров, подтвердим, что отобразимый превью сертификата является одним и тем же отпечатком пальца на вкладке Winrm enumerate winrm/config/listener Details сертификата.

Источник

sergey vasin

The IT blog

Удаленное управление компьютерами, не входящими в домен

Мы знаем, что удаленное подключение к компьютерам домена посредством PowerShell происходит практически прозрачно. Все, что нам нужно сделать, это, к примеру:

Причем вам даже не обязательно указывать имя и пароль — аутентификация произойдет с использованием ваших текущих учетных данных.

Однако, если мы попытаемся подключиться к компьютеру рабочей группы (для начала по IP-адресу), мы увидим что-то вроде:

Что нам тут сообщают, так это то, что подключиться мы можем только в том случае, если будем использовать https или добавим IP-адрес компьютера к списку TrustedHosts, а также явным образом указав учетные данные для подключения.

Для чего это нужно.

При обычном подключении, происходящем между двумя доменными компьютерами, удаленный компьютер аутентифицирует подключающегося, что справедливо и для всех остальных случаев. Но кроме этого, компьютер, с которого мы подключаемся также проводит аутентификацию удаленного компьютера, с целью установить, что это именно тот комьпьютер, к которому мы хотим подключиться.

В доменной среде это происходит прозрачно и без нашего участия. Однако, если удаленный компьютер не является членом нашего домена, то просто так проверить его подлинность уже не получится. И тут нам предоставляют выбор.

Мы можем использовать HTTPS в качестве транспорта и в этом случае удаленному компьютеру придется предъявлять нам сертификат, который мы и будем проверять. При этом наш компьютер должен доверять центру сертификации, выдавшему этот сертификат.

Читайте также:  Как настроить sony handycam

В качестве второго варианта нам предлагается взять ответственность на себя и явным образом вписать все имена и IP-адреса компьютеров в TrustedHosts, что приведет к тому, что при подключении к этим компьютерам их подлинность проверяться никоим образом не будет.

HTTPS

Для того, чтобы подключиться с использованием https, на компьютере, к которому мы хотим получить доступ нужно сделать несколько вещей.

Certificate

Для начала нужно установить сертификат, которому бы доверял компьютер, с которого мы будем подключаться. Если компьютер, с которого мы хотим подключиться является членом домена и в домене развернута роль Certificate Services, то можно выдать сертификат компьютеру рабочей группы через службы сертификатов. В этом случае вопрос доверия выдвнному сертификату не возникнет. Или же можно создать самоподписанный сертификат с использованием какой-либо утилиты для создания сертификатов (например, makecert) или командлета New-SelfSignedCertificate.

Так как мы планируем использовать этот сертификат для подключения к компьютеру и по полному имени (computer_name.domain_name.com), по имени компьютера без упомининия домена (computer_name) и по ip-адресу, сразу же создадим сертификат, который бы удовлетворял всем этим условиям.

Сразу же оговоримся. Для того, чтобы подключаться к компьютеру по полному имени — (FQDN — Fully Qualified Domain Name) его вовсе не обязательно вводить в домен. Мы можем, к примеру, создать для этого комьютера запись в нашей внутренней системе DNS в зоне domain_name.com и это позволит нам использовать имя computer_name.domain_name.com для обращения к этому компьютеру, хотя он по-прежнему остается членом рабочей группы.

Итак, создаем сертификат:

Что мы тут сделали.

При помощи параметра -CertStoreLocation мы указали где нужно сохранить сертификат, а именно — в локальном хранилище компьютера.

Параметр -Subject указывает значение поля «Subject» («Субъект») создаваемого сертификата, и это то самое значение, на которое, среди всех прочих, будет обращать внимание командлет Enter-PSSession (или New-PSSession), когда будет пытаться установить подключение к компьютеру. Строго говоря, имя компьютера, указываемое в качестве значения -ComputerName командлета Enter-PSSession должно совпадать со значением поля Subject сертификата, установленного на компьютере, к которому мы подключаемся.

Какой из, возможно, нескольких сертификатов компьютера рабочей группы используется для подключения, мы укажем чуть позже.

Параметр -KeyUsage задает способы использования ключа, в нашем случае — DigitalSignature, KeyEncipherment (Цифровая подпись, Шифрование ключей). Стоит сказать, что это соответствует значению по умолчанию, так что этот параметр мы вполне могли и не указывать.

В параметре -TextExtension мы указываем значения для нескольких полей сертификата.

OID 2.5.29.37 задает Enhanced Key Usage. Два указанных нами значения — 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1 — задают Client Authentication и Server Authentication, соответственно.

OID 2.5.29.17Subject Alternative Name — позволяет нам расширить список значений, используя которые мы сможем обратиться к компьютеру.

В отсутствие Subject Alternative Name, единстенным именем, по котому мы могли бы обратиться к компьютеру было бы имя, заданное в поле Subject.

Данное же поле позволяет нам задать еще несколько значений, принадлежащих к одному из поддерживаемых типов — DirectoryName, DNS, Email, IPAddress, RegisteredID, UPN, URL.

Как видно из примера, мы использовали DNS и IPAddress. Причем никто не будет против, если имя, указанное в поле Subject мы укажем и здесь тоже.

В случае успешного завершения работы командлета будет выведено два значения: Thumbprint и Subject. Значение отпечатка (Thumbprint) нам понадобится на следующем шаге.

Listener

Теперь нам нужно создать прослушиватель (listener) для транспорта HTTPS и указать созданный нами сертификат для использования этим прослушивателем.

Вообще, мы предполагаем, что PowerShell Remoting уже включен, но если же вдруг это не так, мы можем его включить при помощи командлета:

Если же вступать в диалог с командлетом Enable-PSRemoting и отвечать на задаваемые вопросы не хочется, можно запустить его с параметром -Force.

Этот командлет делает возможными подключения к удаленным компьютерам, но по умолчанию в качестве транспорта предлагается только HTTP.

Тут опять же стоит оговориться о том, что, несмотря на то, что протокол HTTP сам по себе не является защищенным, PowerShell вполне способен о себе позаботиться и все коммуникации, происходящие посредством удаленных подключений, шифруются.

HTTPS здесь нужен для обеспечения еще более серьезной защиты (так как в этом случае, по сути будет происходить двойное шифрование) и для возможности аутентификации удаленного компьютера в том случае, когда другие методы (например, Kerberos) неприменимы.

Читайте также:  Телевизор sony как настроить каналы автоматически

Итак, возвращаемся к созданию прослушивателя. Создавать мы его будем при помощи утилиты winrm. Одним из аргументов будет значение отпечатка того сертификата, который бы мы хотели использовать для удаленных подключений к этому компьютеру.

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

Теперь создадим прослушиватель:

где вместо сорока букв ‘X’ мы указываем обпечаток (thumbprint) нужного нам сертификата.

Если мы запускаем эту команду в консоли PowerShell, мы можем получить что-то вроде:

Происходит это потому, что синтаксис утилиты winrm рассчитан на обычную командную строку и он не учитывает, что у PowerShell может быть свое мнение на использование разных специальных символов.

Для того, чтобы для запуска единственной команды не переключаться в cmd, нам нужно попросить PowerShell не парсить всю введенную команду а передать все как есть утилите winrm на выполнение. Сделать мы это можем вставив следующий набор символов после имени утилиты:

Firewall

Далее нам нужно создать правило для сетевого экрана. Это можно сделать как через Microsoft Management Console — wf.msc, так и через PowerShell:

Trust Issues

Как мы помним, для того, чтобы доменный компьютер мог подключиться к компьютеру рабочей группы, он должен доверять сертификату (или его издателю), который будет предъявлен компьютером к которому мы подключаемся.

Опять же, если мы выдали сертификат посредством доменного центра сертификации — вопросов доверия стоять не будет. Однако, если мы создали самоподписанный сертификат, то при попытке подключения мы получим что-то вроде:

Для того, чтобы доменный компьютер начал с большей степенью доверия относиться к созданному нами сертификату, его потребуется экспортировать из хранилища сертификатов Personal компьютера рабочей группы и импортировать в хранилище Trusted Root Certification Authorities доменного компьютера.

Экспортировать сертификат можно как при помощи Microsoft Management Console (она же mmc), так и посредством PowerShell. Так как закрытый ключ в данном случае нам не нужен, мы воспользуемся командлетом Export-Certificate.

Теперь нам нужно скопировать полученный файл на доменный компьютер (предположим, что мы скопировали его в то же место, корень диска C:) и импортировать находящийся в нем сертификат в хранилище Trusted Root Certification Authorities.

Опять же, это можно сделать как через mmc (уже на доменном компьютере), так и через PowerShell:

Enter-PSSession

Так как при подключении нам потребуется указать учетные данные для подключения к удаленному компьютеру, давайте для удобства заранее сохраним их в переменной:

Теперь подключиться к компьютеру рабочей группы должно увеньчаться успехом:

Так как мы собираемся подключаться к удаленному компьютеру как через IP-адрес, так и используя имя компьютера (computer_name и computer_name.domain_name.com), давайте добавим для него запись в DNS. И хотя в отсутствие записи в DNS нам могут помочь NetBios и LLMNR, тем не менее наличие записи в DNS будет более правильным вариантом.

Сделать это можно через Microsoft Management Console — DNS Manager, или же через PowerShell:

Теперь мы можем попробовать подключиться используя как краткое имя компьютера:

TrustedHosts

Теперь рассмотрим второй вариант, который заключается в том, что вы добавляете имена и IP-адреса всех компьютеров рабочих групп, к которым вы будете подключаться, в TrustedHosts. Результатом этого действия станет то, что ваш компьютер будет относиться к ним с определенной долей доверия и не будет пытаться проверить их подлинность.

Получить текущее значение TrustedHosts можно так:

По умолчанию какое-либо содержимое отсутствует, но если вы ранее что-то уже задавали, то новые значения нужно будет добавить к уже существующим. Опять же, так как мы хотим иметь возможность подключиться с использованием различной идентификационной информации (IP-адрес, имя, FQDN), в TrustedHosts мы добавим все три значения.

После этого нам потребуется подтвердить понимание того факта, что изменение значения TrustedHosts приведет к тому, что подлинность указанных компьютеров проверяться не будет, введя ‘Y’.

Если мы не хотим, чтобы после введения вышеприведенной команды нам приходилось подтверждать свое действие, мы можем добавить к ней параметр -Force:

Теперь мы можем подключиться к удаленному компьютеру используя прослушиватель (listener) по умолчанию. Для этого мы используем те же самые команды, за исключением параметра -UseSSL:

Server Manager

Следствием добавления имен компьютера в TrustedHosts явлется еще одна полезная вещь. Теперь мы можем управлять им из Server Manager. А возможно это потому, что для удаленного управления системами Server Manager использует именно WinRM — тот же самый механизм, что используется и для удаленного подключения из через PowerShell.

Читайте также:  Пабг лайт как настроить микрофон

Стоит сказать, что управлять рабочими станциями через Server Manager у нас не получится, но для серверов, по тем или иным причинам не входящим в домен, это вполне себе полезная возможность.

Для добавления компьютера к консоли Server Manager в левом меню выберем «All Servers», нажмем на «All Servers» правой кнопкой мыши и выберем «Add Servers». В открывшемся окне перейдем на вкладку DNS, введем имя нашего сервера и нажмем на кнопку поиска. Если мы не забыли добавить запись о нем в DNS, он будет найден. Далее мы выделим его и нажмем на треугольник справа, чтобы добавить его к списку серверов, которыми мы будем управлять из Server Manager. Нажимаем на кнопку OK. Теперь наш новый сервер должен отобразиться в списке SERVERS.

Скорее всего напротив его имени будет находиться сообщение об ошибке — Kerberos target resolution error. Нажимаем на имя сервера правой кнопкой мыши и выбираем «Manage As …». Вводим данные учетной записи администратора удаленного компьютера (имя пользователя должно быть в формате computer_name\user_name) и нажимаем OK.

Теперь мы сможем управлять этим сервером так же, как и теми, что входят в домен.

Источник

blog.vmpress.org

Страницы

вторник, 10 ноября 2009 г.

Настройка WinRM на Windows Server 2008

Бывают случаи, когда требуется выполнить какую-либо команду на сервере локально (например, сконфигурировать iSCSI Initiator). Подключаться для этого через Remote Desktop и запускать cmd — неудобно, использовать Telnet — небезопасно, ставить на сервер демона ssh — не. хочется.

Специально для таких запущенных случаев, Microsoft, начиная с Windows Server 2003 R2, снабдила администраторов новым средством управления — Windows Remote Management (WinRM), позволяющим удаленно выполнять команды, используя стандартные средства ОС, и обеспечивая при этом должный уровень безопасности.

Вам даже не придется устанавливать дополнительных программ и компонентов — все, что называется, включено:

Настройка WinRM
В качестве примера я рассмотрю процесс настройки WinRM на Windows Server 2008. Эта процедура никак не отличается от настройки WinRM, например, на Windows Vista или Hyper-V Server.

Проще всего WinRM настроить можно, используя режим быстрой конфигурации, набрав в CMD:
winrm quickconfig
и ответив утвердительно (‘y‘) на вопрос о создании нового объекта-listener’а, прослушающего порт TCP 80, и использующего протокол HTTP для коммуникаций между клиентом и сервером.

, а заодно, как советует появившееся сообщение, добавить сервер в список доверенных узлов, либо использовать более надежный протокол для коммуникации (HTTPS).

Для добавления узла в список надежных, выполните на клиенте, с которого планируете подключаться:
winrm set winrm/config/client @ [, ]»>

Настройка WinRM с использованием HTTPS
В ряде случаев вам может потребоваться создать надежный канал для безопасной пересылки команд между клиентом и сервером. Для этого можно использовать HTTPS.

Однако, для создания listener’а с поддержкой HTTPS вам потребуется цифровой сертификат, который можно запросить у доверенного Центра Сертификации, либо воспользоваться различными утилитами по созданию самоподписанных (самозаверенных) сертификатов, например, Makecert, входящей в состав Windows SDK. Скачать Makecert отдельно можно отсюда.

Для создания самоподписанного серитификата выполните следующую команду:
makecert -a sha1 -r -pe -n «CN= » -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 -m 12
, где соответствует имени, которое будет использовать клиент при подключении к серверу;
— путь к файлу, куда будет сохранен сертификат с открытым ключем.

Если на сервере включен брандмауэр Windows, не забудьте добавить правило:
netsh advfirewall firewall add rule name=»allow WinRM on 4443″ protocol=TCP dir=in localport=4443 action=allow

При использовании самоподписанных сертификатов, вам придется добавить его к доверенным корневым сертификатам на клиенте.

После выполнения всех шагов, вы, наконец, получите возможность удаленного выполнения команд:

Заключение
Как видите, настройка Windows Remote Management достаточно проста в классических ситуациях (с использованием единого домена и CA), однако, при небольшом отклонении от данного шаблона могут обнаружиться несколько подводных камней. К WinRM привыкнуть можно достаточно быстро, особенно, если вы частенько пользуетесь консолью для настройки системы.

Источник