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

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

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

А когда у Вас разные версии 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

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

Вопрос

Здравствуйте, у меня возник вопрос, необходимо создать пользователя (группу), что бы тот являлся для всех ПК в парке, локальным администратором.

Вариант разово добавить на каждом ПК в группу Администратор, не рассматривается ввиду того, что появляются/заменяются ПК и ОС на них с таким же успехом. Т.е. нужно создать Пользователя (Группу) Help Desk который мог бы заниматься обслуживанием парка ПК. Группа Администраторы Домена не подходит из-за больших полномочий. Спасибо.

Ответы

Идёте в редактирование групповых политик, там создаёте объект групповой политики:

Конфигурация компьютера->Политики->Конфигурация Windows->Параметры безопасности->Группы с ограниченным доступом

Здесь укажите, что глобальная группа HelpDesk входит в группу BUILTINАдминистраторы.

• Изменено Daemon-GTC 8 июня 2012 г. 12:14
• Предложено в качестве ответа Раймонд 9 июня 2012 г. 8:59
• Помечено в качестве ответа Sergey33Rus 13 июня 2012 г. 7:30

Идёте в редактирование групповых политик, там создаёте объект групповой политики:

Конфигурация компьютера->Политики->Конфигурация Windows->Параметры безопасности->Группы с ограниченным доступом

Здесь укажите, что глобальная группа HelpDesk входит в группу BUILTINАдминистраторы.

У нас в домене именно таким образом реализован данный функционал. Т.е. в политике прописано добавлять группу «Kaspersky_admin» в группу локальных администраторов на пользовательские ПК (и это GPO прикреплена к OU с пользовательскими ПК). Вот так это выглядит визуально:

• Помечено в качестве ответа Sergey33Rus 13 июня 2012 г. 7:30

Все ответы

Идёте в редактирование групповых политик, там создаёте объект групповой политики:

Конфигурация компьютера->Политики->Конфигурация Windows->Параметры безопасности->Группы с ограниченным доступом

Здесь укажите, что глобальная группа HelpDesk входит в группу BUILTINАдминистраторы.

• Изменено Daemon-GTC 8 июня 2012 г. 12:14
• Предложено в качестве ответа Раймонд 9 июня 2012 г. 8:59
• Помечено в качестве ответа Sergey33Rus 13 июня 2012 г. 7:30

Нет, так работать не будет, для рабочей станции точкой отсчёта должна быть её локальная группа. Единственное возможное решение — создать политику для группы Administrators и перечислить всех, кто таковыми будет являться. Как правило, это Administrator + DOMAINDomain Admins + DOMAINCompany HelpDesk.

MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI

Нет, так работать не будет, для рабочей станции точкой отсчёта должна быть её локальная группа. Единственное возможное решение — создать политику для группы Administrators и перечислить всех, кто таковыми будет являться. Как правило, это Administrator + DOMAINDomain Admins + DOMAINCompany HelpDesk.

MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI

Не помнишь, вроде полгода назад было тут обсуждение, у кого-то не работало? Причина в том, что учётная запись SYSTEM (COMPUTERNAME$) рабочей станции, от лица которой будет исполняться политика, не обладает достаточными привилегиями для модификации свойств доменной группы. А применив политику для группы HelpDesk на контроллере домена, мы лишь внесём её в локальные администраторы самом контроллера .)

MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI

Не помнишь, вроде полгода назад было тут обсуждение, у кого-то не работало? Причина в том, что учётная запись SYSTEM (COMPUTERNAME$) рабочей станции, от лица которой будет исполняться политика, не обладает достаточными привилегиями для модификации свойств доменной группы. А применив политику для группы HelpDesk на контроллере домена, мы лишь внесём её в локальные администраторы самом контроллера .)

MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI

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

Продолжим про безопасность операционных систем – на этот раз «жертвой» станет 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 существует набор встроенных учетных записей с набором типовых прав. Группы немного различаются для компьютера и для домена, а также ряд сервисов привносит свои группы.

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

Если стандартных групп не хватает, то 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 ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».