sergey vasin

The IT blog

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

leave a comment »

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

Enter-PSSession -ComputerName computer_name

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

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

New-PSSession : [10.0.0.5] Connecting to remote server 10.0.0.5 failed with the following error message : 
The WinRM client cannot process the request. 
Default authentication may be used with an IP address under the following conditions: 
the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. 
Use winrm.cmd to configure TrustedHosts. 
Note that computers in the TrustedHosts list might not be authenticated. 
For more information on how to set TrustedHosts run the following command: winrm help config. 
For more information, see the about_Remote_Troubleshooting Help topic.

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

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

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

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

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

В качестве второго варианта нам предлагается взять ответственность на себя и явным образом вписать все имена и 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 для обращения к этому компьютеру, хотя он по-прежнему остается членом рабочей группы.

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

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=computer_name.domain_name.com" -KeyUsage DigitalSignature, KeyEncipherment -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1","2.5.29.17={text}DNS=computer_name.domain_name.com&DNS=computer_name&IPAddress=10.0.0.5")

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

При помощи параметра -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

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

Enable-PSRemoting -Force

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

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

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

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

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

Get-ChildItem -Path Cert:\LocalMachine\My

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

winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Hostname="computer_name.domain_name.com";CertificateThumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

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

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

Invalid use of command line. Type "winrm -?" for help.

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

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

--%

Например, так:

winrm --% create winrm/config/listener?Address=*+Transport=HTTPS @{Hostname="computer_name.domain_name.com";CertificateThumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

Firewall

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

New-NetFirewallRule -DisplayName 5986 -Protocol TCP -LocalPort 5986

Trust Issues

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

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

Enter-PSSession : Connecting to remote server workstation failed with the following error message : 
The server certificate on the destination computer (computer_name:5986) has the following errors:
The SSL certificate is signed by an unknown certificate authority. 
For more information, see the about_Remote_Troubleshooting Help topic.

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

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

$cert = Get-ChildItem -Path Cert:\LocalMachine\My\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Export-Certificate -Cert $cert -Type CERT -FilePath c:\cert.cer

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

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

Import-Certificate -FilePath C:\cert.cer -CertStoreLocation Cert:\LocalMachine\Root\

Enter-PSSession

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

$cred = Get-Credential -Credential username

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

Enter-PSSession -ComputerName 10.0.0.5 -UseSSL -Credential $cred

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

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

Add-DnsServerResourceRecordA -Name computer_name -IPv4Address 10.0.0.5 -ZoneName domain_name.com

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

Enter-PSSession -ComputerName computer_name -UseSSL -Credential $cred

так и полное:

Enter-PSSession -ComputerName computer_name.domain_name.com -UseSSL -Credential $cred

TrustedHosts

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

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

Get-ChildItem WSMan:\localhost\Client\TrustedHosts

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

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "computer_name,computer_name.domain_name.com,10.0.0.5"

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

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

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "computer_name,computer_name.domain_name.com,10.0.0.5" -Force

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

Enter-PSSession -ComputerName 10.0.0.5 -Credential $cred
Enter-PSSession -ComputerName computer_name -Credential $cred
Enter-PSSession -ComputerName computer_name.domain_name.com -Credential $cred

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.

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


Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell


Реклама

Written by Сергей Васин

Апрель 18, 2017 в 13:05

Опубликовано в PowerShell

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s