Заметки о Windows и других программных продуктах Microsoft...

Добавляем доменных пользователей в локальную группу безопасности

Добавляем доменных пользователей в локальную группу безопасности

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

  • Пользователи  (Users) — могут запускать приложения и работать с ними, но не имеют прав на изменение параметров системы.
  • Администраторы  (Administrators) — имеют полные и ничем не ограниченные права доступа к компьютеру.

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

Для того, чтобы добавить доменного пользователя в локальную группу безопасности на одном компьютере, можно особо не мудрить и воспользоваться оснасткой Локальные пользователи и группы (Local users and groups). Однако, если эту процедуру необходимо проделать с большим количеством компьютеров (например, добавить сотрудников техподдержки в группу локальных админов на всех компьютерах сети), то лучше воспользоваться групповыми политиками.

Групповые политики предоставляют два варианта добавления пользователей, и мы рассмотрим их оба. И первый способ, это:

Группы с ограниченным доступом, или Restricted Groups

Несмотря на свое название, эта политика не ограничивает доступ, а позволяет добавить доменных пользователей в локальные группы безопасности. Находится она в узле Конфигурация компьютера\Политики\Параметры безопасности (Computer configuration\Policies\Security Settings)

Restricteg Groups

 

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

Однако есть некоторые нюансы, а именно: если сначала добавить в Restricted Groups группу Администраторы, а затем в нее добавить доменную группу (в нашем случае HelpDesk), то локальными администраторами останутся только встроенный Администратор и добавленная нами группа HelpDesk, а все остальные, даже если они были добавлены вручную, будут из этой группы удалены. Более того, добавить обратно этих пользователей можно будет только одним способом — через Restricted Groups, при этом они станут станут локальными админами на всех компьютерах, на которые действует эта политика.

добавление доменной группы в группу локальных администраторов

 

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

добавление доменной группы в группу локальных администраторов

 

Этот способ работает на всех операционных системах, начиная с Windows 2000. Если же у вас в качестве клиентской операционной системы используется Windows 7, то можно воспользоваться вторым способом:

Предпочтения групповой политики или Group Policy Preferences

Системы на базе Windows 7 поддерживают расширения обычных групповых поли­тик, названные Предпочтениями (Preferences). Предпочтения настраиваются только в объектах групповых политик, хранящихся в доменах Active Directory на базе серверов Windows Server 2008 и 2008 R2.

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

Для добавления пользователей в локальные группы с помощью предпочтений идем в раздел Конфигурация компьютера\Настройка\Параметры панели управления (Computer Configuration\Preferences\Control Panel Settings) и выбираем пункт Локальные пользователи и группы (Local User and Groups)

Локальные Пользователи и Группы

 

Щелкаем правой клавишей мыши на пустом поле, и в контекстном меню выбираем пункт Создать — Локальная группа

открываем окно добавления доменных пользователей в локальную группу

 

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

  • Обновить (по умолчанию) — выбранные пользователи просто добавляются в локальную группу
  • Заменить — выбранные пользователи добавляются в группу, при этом все остальные члены группы удаляются
  • Создать — создается новая локальная группа, в которую добавляются выбранные пользователи
  • Удалить —  удаляются все члены выбранной локальной группы

В поле имя группы выбираем Администраторы (встроенная учетная запись), это выберет группу локальных администраторов, даже если она была переименована. Затем жмем на кнопку Добавить и в качестве членов группы выбираем доменную группу HelpDesk. Теперь осталось нажать ОК, и наша группа техподдержки будет добавлена в группу локальных админов на всех рабочих станциях домена.

А если вы хотите полностью контролировать всех участников локальной группы Администраторы, то можно отметить пункты Удалить всех пользователей-членов этой группы (Delete all member users) и Удалить все группы-члены этой группы (Delete all member groups). Теперь, даже если вручную добавить туда нового пользователя или группу, при следующей перезагрузке список членов группы будет обновлен в соответствии со списком, указанным в групповой политике.

добавление пользователей в локальную группу безопасности

 

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

 
 
Комментарии
Михаил

Спасибо за материал.
Подскажите, политика не отрабатывает, если ее настраивать внутри созданного объекта групповой политики. В чем может быть ошибка?

Политика может не отработать по разным причинам. Как вариант можно попробовать перезагрузить клиентский комп и принудительно обновить политики командой gpupdate /force.

Михаил

Спасибо за ответ. Обновление групповых политик и перезагрузку клиента пробовал неоднократно. Заметил, что если данную настройку применять к корневому объекту, то она отрабатывает, а внутри дочернего не хочет. У меня задача прописать определенных пользователей в локальных администраторов только на некоторые компы. Для этого я создал дополнительный объект, в который поместил нужные мне контейнеры из АД.

Групповые политики наследуются от родительского контейнера к дочернему. Возможно между ними возникает конфликт. Выяснить, какие политики воздействуют на конкретный объект можно из оснастки Resultant set of Policies (RSoP).
Кстати, что у вас считается корневым объектом, а что дочерним ?

Михаил

В моем случае, корневой объект, в который входит группа authenticated users, а дочерний, в который входят нужные мне группы.

Михаил

Я проверил через оснаску и нужный мне объект ГП имеет статус отклонен по причине отказа «пусто».

Политики привязываются к подразделениям (OU), а authenticated users — это группа безопасности. Или вы фильтруете политики на основании принадлежности к группам ?

Михаил

Не совсем понял, но по-видимому второй вариант. Если оставлять группу authenticated users, в фильтрах безопасности, то правило групповой политики применится ко всем объектам класса пользователь, прошедшим проверку.

Для того, чтобы политика применялась только к определенным компам, достаточно создать отдельный OU, перенести в него нужные компы и привязать к этому OU свою политику. Все.
В некоторых случаях можно дополнительно отфильтровать политики на основании членства в группах безопасности, указав к кому их можно применять (или к кому нельзя). По умолчанию политика применяется к группе authenticated users.
Тоесть политики нельзя применять к группам, но группы можно применять для фильтрации политик.
Вот как то так.

Михаил

Здравствуйте.
Насколько я понимаю, у меня так и сделано — есть несколько OU, которые я поместил в фильтр безопасности(предварительно удалив оттуда authenticated users)внутри объекта групповой политики. Но правило для этих OU не отрабатыает.

Михаил

Если же в фильтре безопасности объекта оставить authenticated users, то правило отрабатывает, но естественно для всех пользователей домена.

Попробую по другому. При наличии в фильтре безопасности authenticated users политика может применяться ко всем пользователям домена, но применится только на тех компах, которые находятся внутри OU, к которому эта политика привязана.
Если же выкинуть authenticated users, то политике ни к кому применяться нельзя. Вместо этой группы надо добавить кого нибудь — пользователя или другую группу.

Если что, OU и группы безопасности — совершенно разные вещи.

Михаил

«Вместо этой группы надо добавить кого нибудь — пользователя или другую группу.» — Имеется в виду группа безопасности?

Пользователя добавлял — тоже самое, не применяется.
Вот результат применения политики для пользователя помещенного в фильтры:

Следующие политики GPO не были приняты, поскольку они отфильтрованы
———————————————————————
Local_admins
Фильтрация: Не применяется (пусто)

Тогда дам один простой совет — не надо трогать фильтры вообще, пусть там остаются authenticated users. Политика все равно применится только на тех компах, которые находятся внутри OU.

Михаил

Возможно, тогда я что-то не понимаю. Постараюсь описать порядок своих действий.
Захожу в Управление групповой политикой -> выбираю домен -> создать объект групповой политики и связать его…(принудительно)(связь включена) -> в созданном объекте через функцию «изменить» создаю правило описанное в данной статье -> в созданном объекте выбираю фильтры и туда добавляю одного пользователя, и также оставляю группу authenticated users.
Авторизуюсь под пользователем добавленным в фильтры — правило применяется. Удаляю примененное правило и захожу под другим пользователем, которого нет в фильтрах и правило опять применяется. В чем ошибка?

Политику надо связывать не со всем доменом, а с конкретным подразделением (OU), а в это подразделение поместить нужные компы. Тогда политика применится только к ним.

Михаил

Нужные компы или все же пользователей?
Сделал следущее — в фильтрах оставил группу безопасности authenticated users, и связал политику с конкретной OU в которой состоят нужные мне пользователи. Связь с доменом убрал. В итоге политика не отрабатывает.

Restricted Groups находится в конфигурации компьютера (не пользователя), соответственно и применяется к компьютерам.

Михаил

Кирилл, спасибо за содействие.
Есть также способ применить групповую политику для пользователей, но к сожалению работает только на OS Windows 7 и выше.
В редакторе управления GP необходимо открыть следующий раздел:
Конфигурация пользователя > Настройка > Локальные пользователи и группы, далее создаем локальную группу, для этого в разделе «Имя группы:» указываем встроенную учетную запись Администраторы, (в моем случае пришлось удалить пояснение в скобках иначе создается новая группа). В этом же окне в разделе «Члены группы:» добавляем группу безопасности из AD, которая будет использована для этой политики.

А можно поподробнее объяснить действия показанные на 2м и 3м рисунках, ато я что-то не пойму смысла — сначала мы добавляем группу helpdesk в разделе «Члены этой группы:», а потом на 3й картинке я уже вижу совершенно другое! И сразу вопрос появился — зачем сначала helpdesk нам необходимо туда добавить, если потом мы его должны удалить? Не понимаю манёвра….

Дмитрий

Спасибо все работает по первому варианту. Тестировал на WinXp Win7

Добрый день, все сделано как в статье, на Windows7 политика отрабатывает, но на Windows 8/8.1/10 не отрабатывает. Подскажите в чем может быть проблема.

Для начала надо выяснить, применяется ли политика. Сделать это можно с помощью утилиты gpresult.

Zloy Troll

Отличная идея добавить тех. поддержку во встроенную группу Администраторы, они так же становятся членами встроенной доменной группы Администраторы, члены которой имеют полный доступ к контроллерам домена!

Мы добавляем пользователей в локальную группу администраторов на компьютерах, находящихся в определенной OU. При чем тут контроллеры домена?
К ним имеют доступ только члены группы Domain\Enterprise Admins.

Интересно второй способ является более предпочтителен если в сети нет ОС ниже вин7?

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

Денис

Спасибо за статью.
С помощью политики на рабочую станцию с Windows 10 добавил доменную группу в локальную группу Администраторы (как описано в статье в п. «Предпочтения групповой политики или Group Policy Preferences»). После обновления политики группа там появилась. Но доменный пользователь, входящий в эту группу, не может запустить от имени администратора. Windows отвечает «Запрошенная операция требует повышения».

Денис

Если же в политике добавляю не доменную группу, а доменного пользователя явно, то прав достаточно.

Возможно влияет тип группы (локальная, глобальная и т.д).