Polytech-soft.com

ПК журнал
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Учетная запись домена права администратора

Поиск учетных записей администратора в Active Directory

В предыдущей статье мы описали процедуру сброса пароля стандартной учётной записи администратора домена Active Directory (учетка administrator). Данный сценарий отлично работает в «стандартной» среде Active Directory, однако в некоторых доменах подобный трюк может не сработать, т.к. при их разворачивании были использованы best practice Microsoft по обеспечению безопасности инфраструктуры AD. В реальных доменах AD для защиты учетной записи администратора домена могут применяться следующие стратегии:

  • Переименование стандартной учетной записи администратора Active Directory
  • Создание учетной записи-приманки. Учетная запись хоть и имеет имя Administrator, но никакими правами повышенными не обладает. Кроме того, с помощью политик аудита можно настроить оповещение служб безопасности о попытке авторизации с помощью этой учётной записи
  • Отключение учетной записи Administrator и предоставление полномочий администратора домена другой учетке.

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

Итак, в предыдущей статье мы показывали, каким образом с помощью создания системного сервиса на контроллере домена можно сбросить пароль домен-админа. Данная команда при загрузке DC сбросит пароль доменной учетной записи administrator (администратора домена) на P@ssw0rd.

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

Монтируем отключенную базу Active Directory

Попробуем извлечь из базы AD информацию о реальных администраторах домена. Для этого нужно загрузиться в DSRM режиме, в котором база Active Directory (ntds.dit) находится в отключенном состоянии. Нам необходимо локально смонтировать эту базу, чтобы в дальнейшем получить возможность доступа к хранимой в ней информации.

Запустите две командные строки: в первой мы запустим процесс dsamain.exe , во второй будем вводить интерактивные команды.

Совет. При работе на Server Core вторую командную строку можно открыть, выполнив в исходной cmd команду:

Перед запуском утилиты dsamain.exe, удостоверимся, что другие сервисы и процессы в настоящий момент не используют порт 389. Сделать это можно командой:

В том случае, если команда ничего не вернула – все ОК, идем дальше (если вернула нужно найти и отключить найденный процесс).

Утилита dsamain.exe позволяет смонтировать базу AD и выполнять к ней различные запросы LDAP(по сути позволяет организовать автономный LDAP сервер). Утилита запускается со следующими параметрами:

  • dbpath – задает путь к файлу ntds.dit.
  • allowNonAdminAccess – разрешает осуществлять LDAP запросы к базе AD под локальной учетной записью (по умолчанию доступ разрешен только членам групп Domain Admins и Enterprise Admins).
  • ldapPort – позволяет указать порт LDAP. Мы будем использовать стандартный LDAP порт — 389.

Смонтируем базу AD командой:

Удостоверимся, что процесс dsamain.exe запущен и слушает 389 порт. Для этого во второй командной строке выполните команду:

TCP [::]:389 [::]:0 LISTENING 614

TCP 0.0.0.0:389 *:* 614

Получаем, что процесс с Process ID 614 слушает на порту TCP 389.
Проверим, что процесс с PID 604 и есть наш процесс dsamain.exe:

Session Name: Console

Mem Usage: 11,316 K

Теперь, когда база AD смонтирована, мы можем обращаться к ней с помощью утилит ds* (dsget, dsquery и т.д.). Разберем все три варианта скрытия учетной записи администратора домена.

Переименованная учетная запись администратора домена

Как можно определить, что стандартная учетная запись администратора Active Directory переименована?
Стандартный administrator AD имеет известный идентификатор SID, формат которого S-1-5-21-[ид домена]-500, соответственно, нам просто нужно найти в домене объект с таким SID. Во второй командной строке выполните команду:

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

Теперь можно размонтировать базу AD (остановить процесс dsamain.exe комбинацией Ctrl+C). Убедитесь, что команда вернула строку

Поддельная учетная запись администратора AD

Как определить, что стандартный Administrator Active Directory не обладает необходимыми правами? Это очень просто. Зная DN (distinguished name) учетной записи administrator, мы можем получить список групп, в которых он состоит:

Как вы видите, данная учетная запись не состоит в группе администраторов домена (Domain Admins) и не подойдет для наших целей. Следующая методика поможет найти «реальных» администраторов.

Альтернативный администратор домена

Попробуем разобраться как можно получить список учетных записей, обладающих правами администратора домена? Для начала попробуем рекурсивно вывести всех членов группы Administrators (в том числе членов групп Domain Admins и Enterprise Admins).

Как вы видите, администраторскими правами обладают учетные записи Administrator и itpro. Проверим статус учётной записи Administrator:

Administrator S-1-5-21-2092397264-2003686862-3249677370-500 yes

Как вы видите, она отключена.

Проверим теперь статус учетки itpro:

itpro S-1-5-21-2092397264-2003686862-3249677370-1107 no

Эта учетная запись активна. Проверим в каких группах она состоит:

«CN=Denied RODC Password Replication Group,CN=Users,DC=winitpro,DC=ru»

Отлично, у нее есть права администратора домена! Осталось cбросить пароль учетной записи с samid — itpro. Опять таки, сделать это можно с помощью службы:

Не забудьте отмонтировать базу AD и перезагрузите сервер.

[конспект админа] Меньше администраторов всем

Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.

Сотрудникам, ответственным за определенные серверы и рабочие станции совсем не обязательно выдавать права «администратор домена». Хоть не по злому умыслу, по ошибке, но это может подпортить всем жизнь, а то и стоить чьих-то выходных. Под катом детально разберем принцип предоставления минимальных прав как одну из технологий предоставления минимальных прав.

Ограниченные группы

В качестве примера из практики могу привести грустную историю со счастливым концом. В организации исторически сложилось, что сервер печати находился на контроллере домена. В один прекрасный момент сотруднику отдела IT понадобилось перепрошить принтер, что он и проделал, запустив китайскую утилиту на сервере. Принтер заработал, но вот утилита в процессе перепрошивки перевела время на несколько лет назад. Active directory не очень любит путешественников во времени, и контроллер домена благополучно отправился в «захоронение» (tombstone).

Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.

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

Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.

Первый способ: через Группы с ограниченным доступом (Restricted groups), расположенные в групповых политиках по адресу Конфигурация компьютера – Политики – Параметры безопасности.

Расположение политик Restricted groups.

Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:

Читать еще:  Команды сетевого администратора

Добавляем группу «Администраторы», в которую добавляем группу helpdesk.

И получаем локальную группу «Администраторы» без Domain admins.

Конечно, эту возможность можно использовать и во благо – зачистить локальные группы от лишних участников. Если же хочется избежать такой зачистки, то можно создать в «Группах ограниченного доступа» доменную группу и ее же назначить входящей в группу «Администраторы»:

При такой настройке локальная группа «Администраторы» не будет зачищена.

Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.

Настройка группы безопасности через GPP.

Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.

Таким же способом можно дать права и на определенные серверы нужным сотрудникам. Например, дать права группе разработчиков на тестовый стенд.

Использование встроенных групп безопасности

Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.

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

ГруппаОписание
АдминистраторыПолные права на систему.
ПользователиВозможность пользоваться без изменения системных параметров и без записи в системные разделы. Фактически пользователь – полноценный хозяин только в папке своего профиля.
Операторы архиваГруппа, предназначенная для выполнения резервного копирования и восстановления. Участники группы могут завершать работу системы на серверах и переопределять права доступа в целях резервного копирования.
Опытные пользователиУчастники этой группы могут администрировать локальные учетные записи и группы (кроме администраторов), создавать сетевые ресурсы и управлять доступом на них, менять NTFS ACL (кроме смены владельца папки).
Пользователи удаленного рабочего столаЧленство дает возможность подключаться к компьютеру по RDP
Операторы печатиОператоры могут устанавливать и удалять принтеры, изменять их драйвера и настройки, останавливать и чистить очередь печати.
Операторы настройки сетиМогут менять настройки сетевых интерфейсов. Это полезная группа на случай если нужно переназначать получение адреса сетевой картой с автоматического на статическое. Мобильные пользователи скажут спасибо, если добавить их в эту группу.
Операторы учетаПользователи в этой группе могут создавать/удалять/редактировать/перемещать учетные записи в Active Directory. Удобно дать эти права для сервиса, автоматически заводящего учетки сотрудников после приема на работу.

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

Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети. Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности – secpol.msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.

Настройка прав доступа через групповые политики.

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

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

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

Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 102016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.

Достаточно администрирования

Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации. Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.

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

Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.

Проверка версии и разрешение удаленных подключений при помощи PS.

Создадим группу безопасности и специального пользователя:

Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:

А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:

Теперь необходимо подготовить файл сессии PowerShell:

Зарегистрируем файл сессии:

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

Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.

Доступ к серверу ограничен управлением одной виртуальной машиной.

Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.

Интерфейс JEA Toolkit Helper.

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

Журнал выполнения PowerShell.

Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.

Файловый журнал JEA.

С помощью делегирования, назначения прав и JEA можно добиться отказа от использования учетных записей с администраторскими правами в повседневной работе. В конце-концов, к UAC в Windows ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».

Как дать пользователям домена права локального администратора через групповые политики (GPO)

Вы, вероятно, уже знаете, как на дать права локального администратора доменным пользователям на отдельном компьютере (просто добавьте доменные учетки в группу локальных администраторов).
А когда таких компьютеров 10? 100? 1000? Как добавить доменных юзеров в локальную группу (администраторов) через групповую политику?

Читать еще:  Администрирование устройства android

А когда у Вас разные версии Windows? Разные языки: английская, русская, украинская, испанская версия windows? В этом случае главное — добавлять доменных пользователей в локальные группы, используя SID локальных групп, а не их имена. О том, что такое SID, зачем он здесь нужен и главное — как указать SID группы там, где можно вписать только имя — читайте в этой статье.

Настройка прав через GPO: Restricted Groups

  1. Подключитесь к контроллеру домена.
  2. Создайте новую групповую политику (например, с помощью gpmc.msc => Group Policy Objects => New).
  3. Откройте созданную групповую политику на редактирование.
  4. Выберите пункт «Computer Configuration» => «Policies» => «Windows Settings» => «Security Settings» => «Restricted Groups».
  5. Нажмите правой кнопкой мыши на «Restricted Groups» и выберите «Add Group. «
  6. Выполните один из 2 вариантов (обратите внимание — важно сделать правильный выбор, почему — см. ниже):
    1. Впишите имя группы доменных юзеров (это может быть имя пользователя, но обычно это все-таки группа).
    2. Нажмите «Browse. » и выберите группу пользователей домена.
  7. После добавления группы пользователей домена откроются свойства добавленной Вами группы (Вы также можете открыть свойства самостоятельно двойным щелчком мыши на добавленной группе).
  8. В окне свойств добавленной группы Вы можете задать членов этой доменной группы, либо (что используется намного чаще) указать, в какие локальные группы на компьютере должна входить данная группа доменных пользователей.
  9. Для указания того, в какие локальные группы компьютеров должна входить добавленная группа пользователей домена, в части окна «This group is a member of» нажмите кнопку «Add. » и выполните один из двух вариантов (обратите внимание — важно сделать правильный выбор, почему — см. ниже):
    1. Впишите имя локальной группы, в которую должна входить добавленная Вами группа доменных пользователей.
    2. Нажмите «Browse. » и выберите группу пользователей (да, локальную группу из AD).
  10. Обратите внимание, что Вы можете указать несколько локальных групп, членом которых Вы хотите сделать доменную группу. Для этого каждый раз необходимо нажимать кнопку «Add..» (и выполнять пункт 9).
  11. После внесения всех необходимых доменнных (и локальных) групп закройте групповую политику и назначьте (link) её к нужной Вам организационной единице (Organizational Unit).
  12. Переместите в эту организационную единицу компьютеры, при необходимости сделайте на компьютерах принудительное обновление групповой политики:
    gpupdate /force
  13. Для того, чтобы узнать, применилась ли (и каким образом применилась) созданная Вами групповая политика, Вы можете посмотреть в логи на клиентских компьютерах:
    %SYSTEMROOT%SecurityLogswinlogon.log
    %SYSTEMROOT%DebugUserModeUserenv.log
    А также в журнал событий Event Viewer (eventvwr) в разделе «Applications and Services Logs» => «Microsoft» => «Windows» => «Applications and Services Logs» => «Group Policy» => «Operational».

Новая группа доменных пользователей в Restricted Groups (пункт 6): ввод имени группы или выбор через поиск?

При добавлении новой группы доменных пользователей в «Restricted Groups» в Windows работают 2 разных механизма: ввод имени группы вручную или выбор ее из имеющегося списка доменных групп. Если совсем кратко, то при вводе имени группы вручную в конфигурацию групповой политики попадет (как правило) имя группы, а при выборе из списка доменных групп (через поиск в AD) — будет использован SID.

Дело в том, что при указании названия группы вручную windows не всегда проверяет это название на валидность и не всегда пытается сопоставить этой группе реально существующую группу доменных пользователей — SID.

Что такое SID?
У каждой группы (и пользователя) как доменных, так и локальных, есть уникальный идентификатор — SID (иначе мы не смогли бы переименовывать группы, при этом терялись бы все права на папки, принадлежащие этой группе). Так вот, при сопоставлении имён Windows понимает, что эта группа — не «Друзья Васи», а SID S-123-456-7890-49439535. И даже переименовав группу, мы не потеряем групповых политик, связанных с ней.

Если же название группы введено вручную, то скорее всего, Windows запишет группу по её названию. И если мы (например) дали группе «Друзья Васи» админские права на всех компьютерах, мы потеряем эти права, если переименуем группу, например в «Лучшие друзья Васи». Более того: поскольку сопоставление будет выполняться по имени группы, то переименовав группу «Друзья Васи» в «Лучшие друзья Васи», и создав (новую, никак с предыдущей группой не связанную) группу «Друзья Васи» (может, уже другого Васи) — мы дадим этим новым друзьям нового Васи админские права на компах!

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

Вывод: всегда добавляйте группы, делая выбор из имеющихся доменных групп (через поиск в AD), чтобы использовался SID группы.

Добавление доменной группы в локальные группы пользователей (пункт 9):
ввод имён групп вручную или выбор через поиск в AD?

При указании того, членом каких локальных групп компьютера должна быть нужная Вам доменная группа обратите внимание: в Windows работают 2 разных механизма: ввод имён групп вручную или выбор их из имеющегося списка. Если совсем кратко, то при вводе имени группы вручную в конфигурацию групповой политики попадет (как правило) имя группы, а при выборе из списка доменных групп (через поиск в AD) — будет использован SID. О том, почему это так важно — читайте ниже.

С SID мы разберемся чуть позже, но еще вопрос в том, как выбрать локальную группу там, где отображается только Active Directory (AD). Об этом также читайте далее.

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

Настройка Restricted Groups для предоставления доменным пользователям прав локального администратора: как указывать локальные группы пользователей

Рассмотрим, в чем у нас состоит задача: добавить доменного пользователя (а правильнее — группу доменных пользователей, даже если в этой группе только 1 пользователь) в локальные администраторы на всех компьютерах (можно — домена, можно — организационной единицы).

Механизм добавления ясен: берем имеющуюся доменную группу (например domainIT) и нам необходимо её добавить в локальные администраторы. Казалось бы, всё просто? Ан нет.

Добавление группы доменных пользователей в группу локальных администраторов на АНГЛОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Administrators». Всё просто, но в русскоязычных версиях Windows это не работает: группа IT не становится администраторами компьютеров, а в логах русской винды — ошибки применения нашей групповой политики.

Читать еще:  Администратор хранилища данных

Добавление группы доменных пользователей в группу локальных администраторов на РУССКОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Администраторы». Всё просто, но в англоязычных версиях Windows это не работает: группа IT не становится администраторами компьютеров, а в логах английской винды — ошибки применения нашей групповой политики.

Добавление группы доменных пользователей в группу локальных администраторов на АНГЛОязычной и РУССКОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Администраторы», а также группу «Administrators». Всё просто, группа IT становится администраторами русской и английской версий Windows, но в логах на всех windows — ошибки применения нашей групповой политики (потому что где-то нет группы «Администраторы», а где-то — «Administrators»).

А что, если (вдруг) у Вас украинская версия Windows? Испанская версия Windows? А если злобные администраторы переименовали на компьютере группу локальных администраторов, назвав ее например. «Админы»?

Права локального администратора группе доменных пользователей в любой версии Windows (для любого языка): используем SID для локальных групп

Способ очень простой: для локальных групп, членом которых будет наша доменная группа, необходимо указывать SID. Разумеется, Вы не можете указать SID напрямую (это будет воспринято как имя группы), но есть целых 2 способа заставить Windows подставить SID вместо имен локальных групп.

Прежде всего: почему SID? Это будет работать?
Да! Потому что независимо от версии, разрядности, языка(!) и других параметров Windows, у стандартных групп (таких как «Пользователи» — «Users», «Администраторы» — «Administrators» и так далее) есть заранее зарезервированные (так сказать «широко известные идентификаторы безопасности SID» — «well-known SIDs»). Для группы локальных администраторов SID всегда один и тот же, независимо от языка: S-1-5-32-544.

Способ 1. Выбор локальных групп из AD

Итак, Вы уже добавили в Restricted Groups доменную группу, открыли её свойства, нажали кнопку «Add..» и думаете, как вписать название группы локальных администраторов, чтобы Windows подставила её SID? Всё просто: нажимаете «Browse. » и ищете (в зависимости от языка Вашей AD — именно самой AD!) либо «Administrators», либо «Администраторы» (либо другое название — зависит от языка самой AD!). Эта группа располагается в AD в разделе (это не совсем OU, хотя выглядит так же) под названием «Builtin». При поиске можно также открыть настройки поиска: «Object types. » и оставить отмеченным только пункт «Built-in security principials».

Если Вы выберете локальную группу таким образом (т.е. через поиск в домене, раздел builtin), то хотя после поиска будет отображено только название группы («Administrators», «Администраторы», . ), в Windows будет записан SID группы локальных администраторов, независимо от текстового названия группы локальных админов!

Способ 2. Правка конфига групповой политики

Итак, Вы уже добавили в Restricted Groups доменную группу, открыли её свойства, нажали кнопку «Add..» и думаете, как вписать название группы локальных администраторов, чтобы Windows подставила её SID? Всё просто:

  1. Впишите любое уникальное название: например «testtesttest».
  2. Теперь откройте свойства групповой политики (правой кнопкой по имени политики) и скопируйте/запишите/запомните ее «Unique name» (т.е. GUID).
  3. Не забудьте закрыть групповую политику!
  4. Откройте папку групповой политики.
    Для этого откройте шару:
    \domain.localsysvolPolicies
  5. Перейдите в папку:
    MachineMicrosoftWindows NTSecEdit
  6. Откройте файл:
    GptTmpl.inf
  7. В разделе [Group Membership]
    В одной из строчек Вы увидите Ваше уникальное название, перед которым стоит какой-то длинный текст из букв и цифр:
    *S-1-5-21-488169584-1945689841-2750668826-1126__Memberof = testtesttest
  8. Удалите Ваше уникальное название и впишите SID группы локальных администраторов. Звездочка (программисты на С/С++ знают, что это вызов значения по указателю) указывает, что нужно использовать не само название, а содержимое того, что стоит за этим названием, так что пишем:
    *S-1-5-21-488169584-1945689841-2750668826-1126__Memberof = *S-1-5-32-544
    Итак, алгоритм действий:
    1. Находите в файле GptTmpl.inf строку с уникальным текстом, который Вы вписали в качестве имени локальной группы
    2. Удаляете в этой строке всё СПРАВА от знака «=» (т.е. Ваш текст)
    3. Вписываете СПРАВА от знака «=» (не забудьте после «=» поставить пробел!):
      . = *S-1-5-32-544
    4. Сохраняете файл GptTmpl.inf
  9. Всё.

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

При подготовке статьи использовались следующие материалы:

Статья опубликована: 26.07.2017, обновлена: 16.08.2017

Предоставление прав локального администратора на машинах домена пользователю

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

В итоге остановился на достаточно гибком решении при помощи групповых политик.

Запускаем оснастку «Active Directory — пользователи и компьютеры» и создаем глобальную группу безопасности. Для ясности назовем ее «Администраторы локальных машин»

Далее, запускаем оснастку «Управление групповой политикой» и создаем новый объект групповой политики. Для ясности, назовем политику «Локальные администраторы (PC)» /я обычно помечаю, на что действует та или иная политика. В данном случае PC — на компьютер/

Далее, изменяем созданную политику. Выбираем ветку: «Конфигурация компьютера» → «Конфигурация Windows» → «Параметры безопасности» → Группы с ограниченным доступом

И выбираем Добавить группу…

При добавлении группы указываем ранее созданную группу «Администраторы локальных машин»

Далее добавляем запись в нижней части «Эта группа входит в:»

Указываем группу «Администраторы»

Жмем Ок. Политика создана.

Можно посмотреть политику перейдя на вкладку «Параметры»

Как видно, политика применяется к компьютеру и включает группу «доменАдминистраторы локальных машин» во встроенную группу локальных администраторов компьютера.

Теперь, можно создать подразделение, например, «Рабочие станции», поместить туда компьютеры, для которых необходимо применить политику

После этого следует назначить подразделению созданную нами политику.

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

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

Как видно из примера, все достаточно просто и, надеюсь, понятно.

ВАЖНО. Используя данный метод, появляется возможность входа на сервера с такой учетной записью.
Данный вопрос изучается.

Ссылка на основную публикацию
Adblock
detector