Сценарий входа в PowerShell от имени администратора - PullRequest
Новая
       40

Сценарий входа в PowerShell от имени администратора

0 голосов
/ 16 мая 2018

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

$env:DOMAINNAME
$env:USERNAME
$env:APPDATA
$env:TEMP

И вот почему он мне нужен для входа в систему, но ядумаю, это вопрос разрешения.

Есть идеи, как я мог это сделать?Я попытался добавить сценарий в Конфигурация пользователя → Политики → Настройки Windows → Сценарии → Вход в систему , но он не работал, также попытался в Конфигурация компьютера .

Добавлено -ExecutionPolicy Bypass в качестве параметра и все еще ничего.

Я также пытался добавить это как запланированное задание и запускать его как другой пользователь, но все равно не повезло.

1 Ответ

0 голосов
/ 20 мая 2018

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

Модуль ActiveDirectory

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

Используемые командлеты - это просто Get-ADUser, Get-ADGroup и Get-ADPrincipalGroupMembership. Это командлеты поиска, использующие протокол облегченного доступа к каталогам (LDAP), поэтому мы можем заменить их собственными функциями поиска с использованием классов .NET.

Get-ADUser

Мы можем заменить поисковый командлет Get-ADUser нашей собственной функцией, определенной во время выполнения, следующим образом: 

function Get-ADUser 
{
    Param ( [string]$Identity = $null )
    IF ($Identity)
    {

        $UserSearcher = New-Object DirectoryServices.DirectorySearcher
        $UserSearcher.SearchRoot = "LDAP://$("DC=$(($ENV:USERDNSDOMAIN).Replace(".",",DC="))")"
        $UserSearcher.Filter = "(&(objectCategory=person)(SAMAccountName=$Identity))"

        $UserSearcher.FindAll() | foreach {New-Object PSObject -Property:$_.Properties}
    }
}

Get-ADgroup

Нам также необходимо заменить командлет Get-ADGroup, чтобы мы могли получить группы AD, указанные вами в списке $OfficeLocations. 

function Get-ADGroup 
{
    Param ( [string]$Identity = $null )
    IF ($Identity)
    {

        $GroupSearcher = New-Object DirectoryServices.DirectorySearcher
        $GroupSearcher.SearchRoot = "LDAP://$("DC=$(($ENV:USERDNSDOMAIN).Replace(".",",DC="))")"
        $GroupSearcher.Filter = "(&(objectCategory=group)(SAMAccountName=$Identity))"

        $GroupSearcher.FindAll() | foreach {New-Object PSObject -Property:$_.Properties}
    }
}

Get-ADPrincipalGroupMembership

Этот командлет не нужно заменять - не потому, что он будет работать сам по себе, а потому, что вам не требуется его для достижения желаемого конечного результата. Вы использовали его для получения членства в группах от пользователя AD, однако пользователь AD имеет список своих членств, прикрепленный к его объекту пользователя AD. Таким образом, по сути, мы можем получить список членства пользователя AD непосредственно из объекта пользователя AD, и мы сделаем это следующим образом: 

$userObject = Get-ADUser -Identity $env:USERNAME
$objGroup = $userObject.memberOf

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

Развертывание вашего кода

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

Контекст

Метод, который вы используете для развертывания этого кода, должен соответствовать самому коду. Если ваш сценарий делает предположения о контексте, в котором он выполняется (например, используя $env:USERNAME для сбора пользовательского SAMAccountName для AD), то вам необходимо убедиться, что метод развертывания также делает это предположение. Скрипт в том виде, в каком он есть сейчас, делает это предположение - предположение, что этот код выполняется в собственном контексте пользователя.

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

Зависимость

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

Убедитесь, что вы просматриваете свой код и перечисляете все задачи, которые выполняет код. Под этим я имею в виду, что код будет читать собственный объект AD пользователя и читать сетевое расположение для доступа к файлам подписи, и он будет читать & запись в собственный реестр пользователя, а также запись в путь appdata пользователя.

В заключение

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

...