Я наткнулся на следующий catch22 в сценарии установки моей рабочей станции, пытаясь автоматически добавить группу домена к локальным администраторам.
Улов, который я испытываю, заключается в следующем:
- Когда я использую локального администратора, у меня есть права на добавление пользователей в локальную группу, но мне необходимо предоставить учетные данные домена для подключения к домену.
- Когда я использую пользователя домена, я могу подключиться к AD, но пользователь, который делает это, еще не является локальным администратором, поэтому я пока не могу изменять локальные группы.
Я нахожусь в среде GMP, поэтому правила и нормы есть!действительно! строгий, который ограничивает другие возможные пути.
- Роли разделены, поэтому у меня нет доступа к администратору домена.
- В OU не допускаются изменения, которые могли бы вытолкнуть группу из групповой политики.
- Использование PowerShell с удаленными сценариями запрещено
Это довольно легко обойти вручную при использовании compmgmt.msc и предоставить необходимые учетные данные при запросе ... но я бы хотел избежать добавления шагов вручную и просто максимально автоматизировать всю установку.
Несколько деталей:
- ОС рабочей станции - Windows 10
- Я использую скрипт PowerShell
- Сценарий выполняется с учетной записью локального администратора с повышенными привилегиями.
- Рабочая станция уже подключена к домену
- Учетная запись, используемая для присоединения рабочей станции к домену, не является администратором домена.
- Чтобы иметь права администратора для учетной записи моего домена, мне нужно добавить группу нашего отдела в группу локальных администраторов.
Код, который я использую для добавления группы в локальную группу администраторов:
$de = [ADSI]"WinNT://$Env:ComputerName/Administrators,group"
$de.psbase.Invoke("Add",([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path)
Этот код работает как шарм при запуске с учетной записью домена и является локальным администратором.
Так как это используется для установки новой рабочей станции, я могу запустить ее как в качестве учетной записи домена, так и в качестве локального администратора.
С первым $de.psbase.Invoke("Add",
часть не выполняется
С последним ([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path
завершается ошибкой
Я попытался использовать командлет start-process
с параметрами –verb runas
, чтобы получить другой контекст безопасности, но столкнулся с той же проблемой, что и выше.
Есть ли способ, которым я могу
- только разрешить
([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path
в контексте безопасности пользователя домена и передать его остальной части моего сценария, работающего в контексте безопасности локального администратора (это во многом compmgmt.msc делает это)
или же
- построить объект [ADSI] из жестко закодированных данных без необходимости подключения к домену
или же
- что-то еще ослепительно очевидно, я не думал о