Настройка удаленного взаимодействия в PowerShell (часть 2)

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

Каждый раз при удаленном подключении в PowerShell используется конфигурация сессии. Это относится как к постоянным сессиям, создаваемым с помощью командлетов New-PSSession или Enter-PSSession, так и к временным сеансам, которые создаются при использовании Invoke-Command.

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

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

При подключении к удаленному компьютеру используется конфигурация сессии по умолчанию. Ее значение хранится в переменной $PSSessionConfigurationName, обычно это конфигурация microsoft.powershell.

При необходимости свойства конфигурации можно изменить. Для изменения свойств конфигурации используется командлет Set-PSSessionConfiguration.

Настройка дескриптора безопасности

В свойствах конфигурации есть поле Permission. В нем указан список пользователей, которые имеют право использовать эту конфигурацию. По умолчанию в этот список входят члены локальной группы Administrators, а также Remote Management Users (эта группа есть только в Windows 8 и Server 2012). Все остальные пользователи, не входящие в эти группы, удаленно подключаться к компьютеру и использовать PS Remoting не могут.

Исправить это можно двумя способами — либо добавив пользователей в соответствующие локальные группы, либо изменив дескриптор безопасности конфигурации. Добавлять всех подряд в локальные админы на сервере не очень хорошая идея, а группа Remote Management Users есть только в Windows 8 и Server 2012. Поэтому пойдем вторым путем и изменим дескриптор безопасности конфигурации сессии по умолчанию.

Для изменения воспользуемся командлетом Set-PSSessionConfiguration с ключом -ShowSecurityDescriptorUI. Этот ключ выводит все разрешения в графическом виде, и мы можем добавлять в него как отдельных пользователей, так и группы. Для примера я создал в домене группу безопасности HelpDesk и добавил ее в список доступа конфигурации по умолчанию:

 Set-PSSessionConfiguration microsoft.powershell -ShowSecurityDescriptorUI

Теперь все члены этой группы имеют возможность подключаться к данному компьютеру. Обратите внимание, что для успешного подключения пользователю необходимо дать право выполнения — Execute (Invoke).

Запуск сессии от имени другого пользователя

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

 $cred = Get-Credential contoso\administrator
 Set-PSSessionConfiguration microsoft.powershell -RunAsCredential $cred -Force

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

Примечание. Изменение дефолтной конфигурации сеанса, на мой взгляд, не очень правильный подход. Если же вам удалось настроить 🙂 конфигурацию до полной неработоспособности, вернуть настройки по умолчанию можно, запустив Enable-PSRemoting. В числе прочего этот командлет заново регистрирует конфигурации сеанса с настройками по умолчанию.

Файл конфигурации сессии

В PowerShell 3.0 появилась возможность создавать файл конфигурации, с помощью которого очень удобно настраивать конфигурации сессии. Файл конфигурации создается командлетом New-PSSessionConfigurationFile. Этот командлет имеет множество параметров, о некоторых из них стоит рассказать подробнее:

-Path — имя и расположение файла конфигурации сессии. Расширение файла должно быть .pssc, имя можно задать любое. Это единственный обязательный параметр.

-AliasDefinitions — определяет значения алиасов в удаленном сеансе. Представляет из себя массив такого вида : @{Name=″dir″; Definition=″Get-ChildItem″}, @{Name=″help″; Definition=″Get-Help″}

-FunctionDefinitions — определяет функции в удаленном сеансе. Также представляет из себя массив: @{Name=″Get-PowerShellProcess″; ScriptBlock={Get-Process PowerShell} }

-EnvironmentVariables — список переменных окружения, добавляемых в удаленную сессию. Представляет из себя одномерный массив: @{Share1=″\\SRV1\Share″; Share2=″\\SRV2\Share″}

-ExecutionPolicy — задает политику выполнения скриптов в удаленном сеансе. По умолчанию Restricted, т.е. скрипты выполнять нельзя.

-LanguageMode — определяет элементы языка PowerShell, которые можно использовать в удаленной сессии. Может иметь значения:

FullLanguage — все элементы доступны (по умолчанию);

NoLanguage — можно использовать командлеты и функции, недоступны такие элементы как скриптблоки, переменные и операторы;

RestrictedLanguage — можно использовать командлеты и функции, недоступны скриптблоки, переменные и операторы кроме переменных $PSCulture, $PSUICulture, $True, $False, $Null и базовых операторов (-eq, -gt, -lt).

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

-ModulesToImport — определяет модули и оснастки, автоматически импортируемые в сессию. По умолчанию импортируется только ядро PowerShell (модуль Microsoft.PowerShell.Core).

-SessionType — задает тип сессии. Может иметь значение:

Empty — никаких модулей и оснасток не добавляется в сессию автоматически. Если не импортировать что-либо явно или с помощью скриптов, то работать в такой сессии будет невозможно;

Default — добавляет в сессию модуль Microsoft.PowerShell.Core. Этот модуль содержит команды Import-Module и Add-PSSnapin, которыми можно добавить в сеанс необходимые инструменты;

RestrictedRemoteServer — добавляет в сессию фиксированый набор из 7 командлетов — Exit-PSSession, Get-Command, Get-FormatData, Get-Help, Measure-Object, Out-Default, и Select-Object.

-VisibleAliases, -VisibleCmdlets, -VisibleFunctions и -VisibleProviders — список алиасов, командлетов, функций и провайдеров, видимых в удаленной сессии. Это позволяет еще больше контролировать среду выполнения. Например, можно импортировать модуль целиком, но использовать из него лишь несколько разрешенных команд. Обратите внимание, что параметр Visible вовсе не означает, что нужный элемент будет импортирован в сеанс автоматически.

Создание эндпойнта

И вот теперь мы подошли к созданию новой конфигурации сессии, или custom endpoint. Скажем у нас есть задача разрешить группе пользователей подключаться к контроллеру домена и производить манипуляции с учетными данными пользователей — удалять, редактировать и заводить новых. При этом они не должны входить в группу доменных администраторов и иметь возможность делать что либо кроме этих разрешенных действий.

Создаем файл конфигурации сессии ADUser.pssc. В нем указываем импортировать в сессию модуль ActiveDirectory и сделать видимыми несколько командлетов:

 New-PSSessionConfigurationFile -Path ADUser.pssc -ModulesToImport ″ActiveDirectory″ -VisibleCmdlets *-ADUser, Get-Help, Exit-PSSession, Get-Command, Get-FormatData, Measure-Object, Out-Default, Select-Object

Протестируем созданный файл на валидность:

 Test-PSSessionConfigurationFile .\ADUser.pssc

Теперь сохраним учетные данные администратора домена и зарегистрируем новую конфигурацию с именем ADUser. Права на подключение дадим членам доменной группы HelpDesk:

 $cred = Get-Credential contoso\administrator
 Register-PSSessionConfiguration -Name ADUser -Path  .\ADUser.pssc -RunAsCredential $cred -ShowSecurityDescriptorUI

Проверим, что получилось. Заходим в систему с учетной записью vpupkin, входящей в группу HelpDesk. Открываем сессию на компьютер SRV4 и указываем использовать конфигурацию сессии ADUser:

 $session = New-PSSession -ComputerName SRV4 -ConfigurationName ADUser

Затем в этой сессии пробуем создать нового пользователя и проверить результат. Как видите все получилось. Однако если теперь попытаться сделать что либо еще, хотя бы просто посмотреть список процессов, то получим ошибку.

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

Примечание. При создании эндпойнта необходимо импортировать в сессию набор из этих 7 командлетов: Get-Help, Exit-PSSession, Get-Command, Get-FormatData, Measure-Object, Out-Default, Select-Object, а также сделать их видимыми. Если хотя бы одного из них не будет — установить сессию не удастся, при попытке подключения будет выдаваться ошибка. Это актуально только при создании сессии с помощью Enter-PSSession или New-PSSession, Invoke-Command работает и без них.

И еще пара моментов, которые стоит иметь в виду при настройке удаленного взаимодействия.

Администраторы из других доменов

Даже если пользователь из другого домена является членом группы ″Администраторы″ на локальном компьютере, удаленно подключиться к локальному компьютеру с правами администратора он не сможет. По умолчанию удаленные подключения из других доменов запускаются только с разрешениями обычного пользователя. Для того, чтобы изменить подобное положение вещей и разрешить удаленным пользователям выполнять операции с правами администратора, необходимо изменить значение параметра реестра LocalAccountTokenFilterPolicy. Для этого можно воспользоваться следующей командой, устанавливающей для LocalAccountTokenFilterPolicy значение 1:

 New-ItemProperty -Name LocalAccountTokenFilterPolicy -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -PropertyType Dword -Value 1

Внимание! Параметр реестра LocalAccountTokenFilterPolicy, равный 1, фактически полностью отключает контроль учетных записей (UAC) для всех удаленных пользователей. Перед его изменением внимательно изучите возможные последствия.

Second-hop

Для наглядности проведем небольшой эксперимент. На сервере SRV4 есть файловая шара Share. Находясь на компьютере WKS8 я запускаю команду Test-Path для проверки доступности этой шары и получаю положительный ответ. Затем, открыв удаленную сессию на компьютер SRV5 и попробовав проделать то же самое оттуда, получаю отказ в доступе. В чем же дело ?

В данном случае мы столкнулись с проблемой второго шага (Second-hop). Она заключается в том, что находясь в удаленной сессии нельзя подключиться к другому компьютеру со своими учетными данными. По умолчанию передача учетных данных по сети запрещена.

Чтобы решить эту проблему, необходимо разрешить аутентификацию CredSSP на клиенте и на сервере, а также включить политику передачи учетных данных. Для этого есть два способа.

Способ 1

Включаем аутентификацию CredSSP на клиенте:

 Set-Item WSMan:\localhost\ Client\Auth\CredSSP -Value $true

И на сервере:

 Set-Item WSMan:\localhost\service\Auth\CredSSP -Value $true

Затем открываем редактор групповой политики и идем в раздел Computer Configuration\Policies\Administrative Templates\System\Credential Delegation. Включаем политику Allow delegating fresh credentials (Разрешить передачу новых учетных данных) и указываем сервера, которым доверено передавать эти данные. Можно указать как конкретные сервера, так и использовать символ подстановки * , например wsman/ *.contoso.com.

Способ 2

Если возиться с групповыми политиками влом не очень хочется, то есть способ проще. На сервере включаем CredSSP:

 Enable-WSManCredSSP -Role Server -Force

Затем на клиенте включаем аутентификацию CredSSP и указываем сервер\сервера, которым мы доверяем делегировать свои учетные данные:

 Enable-WSManCredSSP -Role Client -DelegateComputer SRV5.contoso.com -Force

Примечание: команда Enable-WSManCredSSP также изменяет политику Allow delegating fresh credentials, но только на локальном компьютере. Имейте это в виду, если вы используете доменные политики для определения доверенных серверов.

Теперь остается подключиться и проверить, что получилось. Помните, что в строке подключения обязательно нужно указать тип аутентификации и учетные данные. Также имя компьютера должно соответствовать тому, что указано в политике. В нашем случае строка подключения будет выглядеть так:

 Enter-PSSession -ComputerName SRV5.contoso.com -Authentication CredSSP -Credential contoso\administrator

Установив сессию, еще раз пробуем проверить доступность шары. И как видите, теперь команда Test-Path прошла успешно.

Ну, пожалуй все. Для более глубокого понимания механизмов удаленного взаимодействия в PowerShell рекомендую прочесть книгу Secrets of PowerShell Remoting. А также не пренебрегайте справочной документацией PowerShell, в ней можно найти много интересного.