Когда администратору по каким-либо причинам требуется передать часть своих задач другому сотруднику, перед ним обычно встает два вопроса: как сделать так, чтобы при выполнении новых задач этот сотрудник с точки зрения прав и возможностей был ничуть не хуже администратора, а с другой стороны, как добиться, чтобы он был ничуть не хуже администратора исключительно при решении делегированных задач. Технология Just Enough Administration, или JEA, дает ответы на оба вопроса.
Что такое JEA
JEA — это технология, появившаяся в языке написания сценариев PowerShell версии 5.0, которая позволяет настроить параметры сеанса, Session Configuration, часто упоминаемые как конечная точка, Endpoint, таким образом, чтобы пользователь, не являющийся администратором на компьютере, к которому подключается, установив с ним соединение с использованием указанных параметров, получил на данном компьютере административные права. Делается это при помощи виртуальных учетных записей, которые создаются при подключении пользователя и прекращают свое существование с окончанием сессии. Таким образом, эти виртуальные учетные записи не могут быть использованы для чего-либо другого, например для подключения по протоколу удаленного доступа RDP или для управления через консоль MMC.
Здесь стоит упомянуть, что и до JEA вы могли указать учетную запись, от имени которой будет действовать подключившийся пользователь. Для этого в команде Register-PSSessionConfiguration используется параметр RunAsCredential. Однако, во-первых, в этом случае указываемая в параметре учетная запись уже должна обладать административными правами. А во-вторых, каждый подключающийся пользователь будет действовать от имени одной и той же учетной записи, что приведет к некоторым сложностям при попытке проверки, кто из пользователей чем занимался.
Но вернемся к виртуальной учетной записи. Для того чтобы ее задействовать, мы устанавливаем значение параметра RunAsVirtualAccount в команде New-PSSessionConfigurationFile как $True.
По умолчанию при подключении к рабочей станции или автономному серверу (имеется в виду к серверу, который не является контроллером домена) виртуальная учетная запись, от имени которой действует пользователь, будет членом локальной группы Administrators. В случае подключения к контроллеру домена эта виртуальная учетная запись будет входить в группу Domain Admins.
В какие группы должна входить виртуальная учетная запись, вы можете указать самостоятельно при помощи параметра RunAsVirtualAccountGroups в той же команде New-PSSessionConfigurationFile. Стоит упомянуть, что указание какой-либо группы в качестве значения параметра RunAsVirtualAccountGroups приведет к тому, что группы по умолчанию (Administrators или Domain Admins) применяться уже не будут. Поэтому, если вам нужно, чтобы виртуальная учетная запись входила в группы, например Administrators и Some_Special_Group, в качестве значения параметра RunAsVirtualAccountGroups, необходимо указать обе.
Несмотря на то что группа Domain Admins предоставляет широкие возможности на уровне домена, виртуальная учетная запись, от имени которой будет действовать пользователь, в своих административных правах будет ограничена компьютером, на котором она создана. Таким образом, если в процессе работы пользователю нужно будет обратиться по сети к какому-либо другому компьютеру, это обращение будет происходить не от имени члена группы Domain Admins (в случае контроллера домена), а от имени учетной записи данного компьютера. Это справедливо и для рабочих станций и автономных серверов.
Если же ваш метод применения JEA предполагает взаимодействие с другими компьютерами, то здесь можно воспользоваться появившейся в среде управления Windows Management Framework 5.1 возможностью использования вместо виртуальной учетной записи так называемой групповой учетной записи управляемой службы, Group Managed Service Account (gMSA). В этом случае значение параметра RunAsVirtualAccount мы указываем как $False (или не указываем вообще), а в параметре GroupManagedServiceAccount задаем соответствующую учетную запись. Понятно, что компьютеры, к которым мы будем обращаться, должны иметь право ее использовать.
RestrictedRemoteServer
Вторая важная задача — это ограничение возможностей пользователя, получившего при подключении административные права. Как известно, существует два основных способа контроля доступности команд, привилегий, возможностей и т. д. Первый — это разрешить все, а потом запрещать нежелательное. Второй — запретить все и затем разрешать то, что необходимо. Так как сама идея JEA состоит в том, чтобы пользователи обладали минимальным набором возможностей, очевидно, что в данном случае актуален второй подход.
По умолчанию при задании настроек сессии (конечной точки) пользователю доступен весь набор команд, и в этом случае его возможности ограничиваются только его правами, которые в свою очередь в большинстве случаев определяются членством в группах. Однако при создании настроек сессии мы можем ограничить набор доступных команд до минимально необходимого. Таким образом, доступны будут только те команды, которые нужны для функционирования самой удаленной сессии. Это следующие команды: Clear-Host, Exit-PSSession, Get-Command, Get-FormatData, Get-Help, Measure-Object, Out-Default, Select-Object и псевдонимы (алиасы) некоторых из них: clear, cls, exsn, gcm, measure, select.
Чтобы реализовать сказанное выше, в качестве значения параметра SessionType в команде New-PSSessionConfigurationFile нужно указать RestrictedRemoteServer. В этом случае все, что потребуется сверх приведенного набора, нужно определять явным образом. Кроме того, установка параметра SessionType в значение RestrictedRemoteServer неявным образом влияет на значение еще одного параметра, а именно LanguageMode, задавая его значение как NoLanguage. Это приводит к тому, что все языковые конструкции в пределах удаленной сессии будут недоступны.
Если задачи пользователя все-таки потребуют какого-либо взаимодействия с возможностями языка PowerShell, вы можете организовать это двумя способами. Во-первых, можно определить функции, которые будут доступны пользователю в рамках сессии в файле возможностей ролей, Role Capabilities, о чем мы поговорим чуть позже. Во-вторых, вы можете создать набор функций на локальном компьютере пользователя, предусмотрев в нем все необходимые возможности для взаимодействия с удаленной сессией. Таким образом, пользователь будет работать с локальными функциями, а те в свою очередь будут задействовать удаленные подключения для выполнения требуемых задач. Теперь, запретив все, кроме команд, необходимых для работы самой сессии, перейдем к разрешениям.
Role Capabilities
Что именно будет доступно конкретному пользователю, определяется при помощи файлов описания возможностей ролей, Role Capabilities. Они представляют собой текстовые файлы с расширением. psrc. Каждый файл определяет какую-либо роль, которая в свою очередь определяет, что именно будет доступно пользователю (или группе), которому эта роль будет назначена, а именно: модули, псевдонимы, команды, функции, внешние команды и провайдеры. Создание файлов. psrc происходит при помощи команды New-PSRoleCapabilityFile, а сопоставление групп пользователей тем или иным ролям — при помощи параметра RoleDefinitions в команде New-PSSessionConfigurationFile.
Поговорим о файлах. psrc. C файлами настройки сессии. pssc все более или менее понятно. Они используются в процессе регистрации настроек сессии Session Configuration, а именно указываются в качестве значения параметра Path в команде Register-PSSessionConfiguration и служат своего рода шаблоном для создаваемой настройки. Таким образом, они нужны только в момент регистрации этой настройки и могут находиться в любом месте, на которое будет ссылаться параметр Path.
Что же касается файлов описания возможностей ролей Role Capabilities, то здесь все несколько иначе. Они тоже представляют собой текстовые файлы, но имеют расширение. psrc и создаются командой New-PSRoleCapabilityFile. Еще более важное отличие состоит в следующем: для того, чтобы содержащиеся в таких файлах настройки ролей применялись к создаваемым сессиям, файлы. psrc должны находиться в определенных местах, а точнее, в папке RoleCapabilities какого-либо модуля.
Здесь может возникнуть некоторая путаница: можно предположить, что файл описания возможностей ролей, размещенный в каталоге RoleCapabilities определенного модуля, будет влиять только на команды данного модуля. Однако это не так. Файл. psrc должен находиться в указанном месте для того, чтобы PowerShell мог его найти, но это никоим образом не ограничивает пределы его использования.
Более того, имя роли определяется именем файла описания возможностей ролей: к примеру, роль Maintenance определяется файлом Maintenance.psrc. Это приводит к тому, что файлы с одним и тем же именем, расположенные в разных модулях, будут считаться описанием одной и той же роли. Но PowerShell в этом случае не будет пытаться создать какую-то общую структуру из всех имеющихся файлов, а просто выберет первый встретившийся файл (из файлов с одинаковыми именами) и будет его использовать в качестве источника информации об определенной роли. Понятно, что взгляд PowerShell на то, какой файл будет считаться первым, может не совпадать с вашим.
Поскольку Microsoft не рекомендует без необходимости трогать файлы в каталоге $PSHOME (обычно C:\Windows\System32\WindowsPowerShell\v1.0), стоит рассмотреть вариант хранения файлов настроек в каком-либо собственном модуле, если таковой имеется. Если же в своей среде вы не используете собственноручно созданные модули, можно создать модуль исключительно для хранения файлов. psrc, что мы и сделаем чуть позже.
Что еще стоит рассмотреть, так это ограничение прав доступа к файлам описания возможностей ролей. Так как эти файлы содержат всю информацию о возможностях и полномочиях пользователей, их случайное изменение может предоставить подключающемуся пользователю привилегии, которых у него быть не должно. Минимальный набор прав должен включать в себя возможность доступа к ним учетной записи Local System, так как это необходимо для функционирования самой технологии JEA. Все остальные права — на ваше усмотрение, в соответствии с принятыми в организации стандартами.
TranscriptDirectory
Еще неплохим вариантом будет включение протоколирования всех выполненных пользователями команд, а также полученных ими результатов. Сделать это можно при помощи параметра TranscriptDirectory в команде New-PSSessionConfigurationFile. В качестве значения мы указываем каталог, где и будут храниться журналы. Опять же, для функционирования процесса протоколирования учетная запись Local System должна иметь доступ к указанной папке.
Пример настройки
Теперь давайте попробуем реализовать технологию Just Enough Administration на практике. Предположим, у нас есть две группы пользователей: DNS_Managers и AD_Managers. В них входят пользователи, которые будут выполнять некоторые административные функции по управлению сервером DNS и службой каталогов Active Directory соответственно. Причем никто из них не входит в административные группы, такие как Administrators, Domain Admins или DNSAdmins, и поэтому административными правами не обладает. Далее будем исходить из того, что для членов группы DNS_Managers мы хотим предоставить возможность задействовать все команды модуля DNSServer и утилиту командной строки dnscmd.exe.
Группе AD_Managers мы хотим предоставить возможность применять без ограничений команды Get-ADForest и Get-ADDomain. Кроме того, им должна быть доступна команда Get-ADComputer, причем использовать они смогут только параметр Identity, а в качестве его значения указывать исключительно имена компьютеров, начинающиеся с ‘cl’. Чтобы продемонстрировать еще одну возможность управления доступностью команд и их параметров, сделаем так, что им будет доступна команда Get-ADUser, где они без ограничений смогут использовать параметр Filter, а для параметра Properties будут доступны значения только Description и Department. Кроме того, предоставим им доступ к утилитам dsget.exe и dsquery.exe.
Для начала нам понадобятся каталоги для временного хранения файлов настройки сессии, а также для хранения журналов работы подключающихся к серверу пользователей. Пусть это будут C:\WorkBench и C:\WhatAreYouDoing, соответственно.
New-Item-ItemTypeDirectory-Pathc: \WorkBench New-Item-ItemTypeDirectory-Pathc: \WhatAreYouDoing
New-PSSessionConfigurationFile
Далее нам нужно создать файл настроек сессии. Сделаем мы это при помощи команды New-PSSessionConfigurationFile. Однако, поскольку параметров достаточно много и их значения порой представляют собой несколько строк, предлагаю воспользоваться технологией подстановок splatting и сначала создать в переменной $PSSessionConfigurationFile хеш-таблицу с именами параметров и их значениями, а уже затем вызывать команду для создания файла.
Итак, мы будем использовать следующие параметры. Для начала — путь и имя файла. Пусть это будет ‘C:\WorkBench\Management.pssc’. Далее — SessionType. Как уже говорилось выше, его значением должно быть ‘RestrictedRemoteServer’. Еще один обязательный в нашем случае параметр — RunAsVirtualAccount, со значением $True. Параметр TranscriptDirectory определяет, где мы хотим хранить журналы. А также нам понадобится параметр RoleDefinitions, который назначает конкретные роли пользователям, в зависимости от их членства в группах. Формат его определения следующий: @{‘группа’ = @{RoleCapabilities = ‘соответствующая_ей_роль’}}.
Причем нам никто не запрещает задать пользователю или группе несколько ролей, указав их через запятую, например: @{‘группа’ = @{RoleCapabilities = ‘роль_1’, ‘роль_2}}. Это приведет к тому, что пользователи будут располагать возможностями обеих ролей. К примеру, если ‘роль_1’ позволяет задействовать только команду Get-Item, а ‘роль_2’ — только Get-DNSServer, то пользователи будут иметь возможность запустить и Get-Item, и Get-DNSServer.
Однако вернемся к нашему файлу Management.pssc. Выше мы говорили о том, что при указании значения параметра SessionType как ‘RestrictedRemoteServer’ доступными для использования будут только несколько команд, необходимых для функционирования самой сессии. И хотя полномочия пользователей относительно доступных команд мы будем определять в файлах описания возможностей ролей, предлагаю кое-что сделать на уровне настройки сессии.
А именно, если предполагается, что пользователи будут работать с удаленными сессиями интерактивно, то есть без применения заранее написанных функций, соответствующих определенным задачам, им пригодится возможность использования сочетаний клавиш Tab и Ctrl+пробел для автоматического завершения имен команд и параметров, а также получения возможных вариантов. По умолчанию в сессиях RestrictedRemoteServer эти функции отсутствуют.
Давайте предположим, что администраторам сервера DNS и Active Directory пригодилась бы данная функция, и сделаем ее доступной для обеих групп. Здесь мы могли бы воспользоваться файлами описания возможностей ролей для каждой из групп, но, так как эти сочетания клавиш будут применяться всеми пользователями настроек сессии, определим их доступность на данном уровне.
Что касается технической реализации, то мы можем воспользоваться параметром VisibleCmdlets как при вызове команды New-PSSessionConfigurationFile для создания настройки сессий, так и при вызове New-PSRoleCapabilityFile для создания файла описания возможностей ролей. Отличие в том, что команды, заданные при вызове New-PSSessionConfigurationFile, будут доступны пользователям всех групп, которым сопоставлены какие-либо роли в пределах конкретной настройки сессии.
За сочетания клавиш Tab и Ctrl + пробел отвечает функция TabExpansion2, поэтому именно ее мы укажем в параметре VisibleCmdlets при создании настройки сессии (листинг 1).
Теперь для того, чтобы указать, что мы собираемся использовать технологию splatting, а не просто задаем переменную $PSSessionConfigurationFile в качестве значения для какого-либо параметра, при вызове команды New-PSSessionConfigurationFile символ $ перед ее именем мы заменим на @.
New-PSSessionConfigurationFile@ PSSessionConfigurationFile
Register-PSSessionConfiguration
Теперь давайте зарегистрируем настройки сессии. Сделаем мы это при помощи команды Register-PSSessionConfiguration. В качестве параметров задействуем Name (его значение будет являться именем набора настроек сессии и будет применяться пользователями при подключении (назовем его Management), а также Path, где мы укажем путь к только что созданному файлу Management.pssc.
Тот факт, что у нас еще не созданы файлы описания возможностей ролей, не помешает нам создать конечную точку, хотя для указанных групп сделает ее использование невозможным.
Как мы помним, по умолчанию возможность подключения к конечным точкам имеют пользователи групп ‘Administrators’ и ‘RemoteManagementUsers’, и для того, чтобы это изменить, требуется задействовать параметры SecurityDescriptorSddl или ShowSecurityDescriptorUI. Однако если файл *.pssc содержит сопоставление ролей определенным группам, эти группы автоматически получают право подключения к регистрируемым настройкам.
$PSSessionConfiguration= @{
Name = 'Management'
Path = 'C:\WorkBench\Management.pssc'
}
Register-PSSessionConfiguration@
PSSessionConfiguration
New-PSRoleCapabilityFile
Итак, мы создали файл настроек сессии, в котором сопоставили группу DNS_Managers роли DNS_Administration, а группу AD_Managers — роли AD_Administration. Теперь следовало бы определить полномочия этих ролей, но сначала стоит решить, где эти файлы ролей будут храниться.
Как уже говорилось выше, если у вас нет какого-либо собственного модуля, где вы бы могли хранить эти файлы, можно создать пустой модуль (не содержащий каких бы то ни было функций и других элементов) с целью использования исключительно для этих целей. Создадим мы его в предлагаемом для хранения собственных модулей каталоге C:\ProgramFiles\WindowsPowerShell\Modules и назовем, к примеру, Maintenance (листинг 2).
Для начала мы сохраняем путь к корневому каталогу нашего нового модуля в переменной $ModulePath, а затем создаем этот каталог. В нем мы создаем пустой файл Maintenance.psm1, куда в случае необходимости сможем добавить наши функции.
Далее мы создаем файл описания, или манифест, для модуля, где как единственный параметр используем RootModule. В качестве его значения мы указываем только что созданный файл Maintenance.psm1.
Затем в каталоге нашего нового модуля мы создаем папку RoleCapabilities, где будут храниться файлы описания возможностей ролей, и можем перейти непосредственно к их созданию. Причем действовать мы будем таким же образом, как и при создании файлов настройки сессии, то есть с применением технологии splatting.
DNS_Administration.psrc
Как уже говорилось выше, пользователи групп, которым будет назначена роль DNS_Administration, должны иметь возможность задействовать все команды модуля DNSServer, а также утилиту командной строки dnscmd.exe. И здесь, казалось бы, мы могли бы использовать параметр ModulesToImport, для того чтобы предоставить пользователям доступ ко всем командам модуля DNSServer. Однако, если мы это сделаем, то увидим, что ни одной ожидаемой команды для управления сервером DNS в сессии нет. Почему? Все дело в том, что чуть раньше, при создании файла настроек сессии, мы использовали параметр VisibleCmdlets, для того чтобы присутствие в сессии функции TabExpansion2 сделало возможным использование сочетаний клавиш Tab и Ctrl+пробел.
Как только мы задействуем какой-либо из параметров Visible* (VisibleAliases, VisibleCmdlets, VisibleFunctions, VisibleExternalCommands или VisibleProviders), будь то в команде New-PSSessionConfigurationFile или New-PSRoleCapabilityFile, PowerShell предполагает, что наши намерения состоят в использовании более гранулярного подхода к доступности пользователю сессии определенных команд, и ориентируется на соответствующие параметры.
Об этом важно помнить не только при создании новых настроек сессии, но и при их редактировании. Потому что при их создании мы точно знаем, чего хотим добиться, и заметим, если итоговый результат не соответствует нашим ожиданиям.
Когда мы редактируем уже имеющиеся настройки, мы можем не знать, чего именно хотели добиться их авторы, и привести их к такому виду, что сессия будет способна выполнять новые задачи, но перестанет подходить для тех задач, для которых она изначально создавалась.
Например, если ни в настройках сессии, ни в существующих файлах описания возможностей ролей не используются параметры Visible*, то все модули, указанные в ModulesToImport, пользователям будут доступны. Но, если мы создадим новый файл ролей, где эти параметры будут использоваться, и добавим конкретную роль какой-либо группе, которой ранее уже была назначена некая роль, то пользователи этой группы потеряют возможность задействовать любые команды из модулей, определенных в параметре ModulesToImport.
Вернемся к созданию файла описания возможностей ролей. Вместо параметра ModulesToImport мы можем использовать параметр VisibleCmdlets со значением ‘DNSServer\*’. Это приведет к тому, что все команды модуля DNSServer будут доступны. Однако в случае необходимости мы вполне можем указать в качестве значения ‘DnsServer\Get-*’ или ‘DnsServer\*-DnsServer’.
Кроме команд, модуль DNSServer содержит еще несколько псевдонимов, или алиасов. Раз уж мы решили, что пользователям должно быть доступно все содержимое модуля DNSServer, то предоставим им возможность применять и алиасы тоже.
Поступить с ними так же, как с командами, а именно указать их следующим образом — VisibleAliases = ‘DNSServer\*’ — у нас не получится. Потребуется указать имя каждого из них по отдельности. Кроме того, нам нужно предоставить пользователям возможность задействовать утилиту командной строки dnscmd.exe. Ее полный путь мы укажем в параметре VisibleExternalCommands (листинг 3).
О чем еще стоит сказать, так это о том, что если вы уже занимались настройкой удаленных подключений, то можете подумать: зачем нам создавать роли, если эти же ограничения, касающиеся доступности команд, мы можем задать и при создании настройки сессий?
Действительно, такой подход вполне возможен; только в этом случае доступность команд определяется на уровне настройки сессии. То есть, если вам требуется несколько наборов команд для разных групп, придется создать несколько наборов настроек, по одному для каждой группы пользователей. С помощью JEA это можно сделать в пределах единственного набора настроек.
AD_Administration.psrc
Теперь перейдем к роли для администрирования Active Directory. Здесь мы решили ограничить возможность использования не только команд, но и их параметров. В частности, команды Get-ADForest и Get-ADDomain можно будет применять без ограничений, а в командах Get-ADUser и Get-ADComputer из всех возможных параметров мы оставим только несколько.
Среди параметров команды Get-ADUser будут доступны: Filter без каких-либо ограничений и Properties, в качестве значений которого можно будет указать только ‘Description’ и ‘Department’. Для параметра Properties мы воспользуемся выражением ValidateSet, которое позволяет явным образом задать возможные значения.
Что касается команды Get-ADComputer, то мы решили, что доступен будет единственный параметр Indentity, и его значения должны начинаться с символов ‘cl’. Здесь нам пригодится выражение ValidatePattern, которое позволяет указать, как должно выглядеть значение параметра с использованием регулярных выражений. И так же, как и в предыдущем случае, мы укажем полный путь к утилитам dsget.exe и dsquery.exe в параметре VisibleExternalCommands (листинг 4).
Здесь стоит сказать, что на общие параметры, такие как ErrorAction или WarningVariable, подобные ограничения не влияют, поэтому такие параметры всегда будут доступны.
Get-PSSessionCapability
После того как мы создали все нужные файлы описания возможностей ролей, было бы неплохо проверить, ко всем ли необходимым командам они предоставляют доступ. Естественно, сделать это можно, установив подключение к созданным нами настройкам сессии с применением учетных данных пользователя, введя команду:
Get-Command-CommandTypeAll
Установка значения параметра CommandType в ‘All’ нужна для того, чтобы в дополнение к командам и функциям была выведена информация и об алиасах и внешних компонентах, таких как утилиты командной строки и файлы сценариев. Однако удобнее это сделать, введя следующую команду непосредственно на сервере:
Get-PSSessionCapability- ConfigurationNameconfiguration_ name-Usernameuser_name
В этом случае мы получим информацию обо всех доступных пользователю командах без необходимости установки подключения и использования его учетных данных.
New-PSSession
Теперь пользователи могут подключиться с использованием созданной нами настройки при помощи команд New-PSSession и Enter-PSSession.
$session= New-PSSession- ComputerNamecomputer_ name-ConfigurationNameManagement Enter-PSSession-Session$session
Изменение файлов описания возможностей ролей
Если по ходу работы мы придем к выводу, что роли в их нынешнем виде не соответствуют нашим представлениям о прекрасном, мы вполне можем это исправить. Сделать это можно как при помощи редактирования файла описания возможностей ролей вручную, так и посредством запуска команды New-PSRoleCapabilityFile с указанием нужных параметров. При этом изменения вступят в силу уже при следующем подключении, перезагрузка службы WinRM не потребуется.
Предположим, что в созданной ранее роли DNS_Administration нам очень не хватает функции для проверки состояния службы сервера DNS. Для того чтобы это изменить, возьмем уже использовавшуюся нами команду и добавим туда параметр FunctionDefinition. Кроме иллюстрации того, что в файле возможностей ролей мы можем задавать доступные пользователям функции, это еще и возможность убедиться, что в них мы можем задействовать компоненты языка, которые в сессиях типа ‘RestrictedRemoteServer’ отсутствуют. Например, конструкции if и переменные, как показано в листинге 5.
Итак, в этой статье мы познакомились с технологией Just Enough Administration, рассмотрели вопросы, касающиеся ее внедрения и использования, а также изучили возможности, которые она предоставляет в области организации и отслеживания действий при администрировании серверов в сети предприятия.
$PSSessionConfigurationFile= @{
Path = 'C:\WorkBench\Management.pssc'
SessionType = 'RestrictedRemoteServer'
RunAsVirtualAccount = $True
TranscriptDirectory = 'c:\WhatAreYouDoing'
RoleDefinitions = @{'domain_name\DNS_Managers'= @{RoleCapabilities = 'DNS_Administration'};
'domain_name\AD_Managers'= @{RoleCapabilities = 'AD_Administration'}}
VisibleCmdlets = 'TabExpansion2'
}
$ModulePath= 'C:\Program Files\WindowsPowerShell\Modules\Maintenance' New-Item-ItemTypeDirectory-Path$ModulePath New-Item-ItemTypeFile-Path$($ModulePath+ '\Maintenance.psm1') New-ModuleManifest-Path$($ModulePath+ '\Maintenance.psd1')-RootModuleMaintenance.psm1 $RoleCapabilitiesPath= $ModulePath+ '\RoleCapabilities' New-Item-ItemTypeDirectory-Path$RoleCapabilitiesPath
$PSRoleCapability_DNS_Administration= @{
Path = $($RoleCapabilitiesPath+ '\DNS_Administration.psrc')
VisibleAliases = 'Export-DnsServerTrustAnchor', 'Get-DnsServerRRL', 'Set-DnsServerRRL'
VisibleCmdlets = 'DNSServer\*'
VisibleExternalCommands = 'C:\Windows\system32\dnscmd.exe'
}
New-PSRoleCapabilityFile@PSRoleCapability_DNS_Administration
$PSRoleCapability_AD_Administration= @{
Path = $($RoleCapabilitiesPath+ '\AD_Administration.psrc')
VisibleCmdlets = 'Get-ADDomain','Get-ADForest',
@{Name = 'Get-ADUser'; Parameters = @{Name = 'Filter'}, @{Name = 'Properties'; ValidateSet= 'Description', 'Department'}},
@{Name = 'Get-ADComputer'; Parameters = @{Name = 'Identity'; ValidatePattern= 'cl.*'}}
VisibleExternalCommands = 'C:\Windows\system32\dsget.exe', 'C:\windows\system32\dsquery.exe'
}
New-PSRoleCapabilityFile@PSRoleCapability_AD_Administration
$PSRoleCapability_DNS_Administration= @{
Path = $($RoleCapabilitiesPath+ '\DNS_Administration.psrc')
VisibleAliases = 'Export-DnsServerTrustAnchor', 'Get-DnsServerRRL', 'Set-DnsServerRRL'
VisibleCmdlets = 'DNSServer\*'
VisibleExternalCommands = 'C:\Windows\system32\dnscmd.exe'
FunctionDefinition = @{Name = 'Test-DNSService'; ScriptBlock = {if($dns= Get-Service-NameDNS) {Write-Output-InputObject»Service status: OK», $dns}}}
}
New-PSRoleCapabilityFile@PSRoleCapability_DNS_Administration