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


11

Я программист застрял, пытаясь администрировать настройки Active Directory для небольшой компании. Контроллер домена работает под управлением Windows Small Business Server 2008.

У нас есть штат полевых работников, использующих планшетные ПК; Из-за проблем конфигурации с вирусом ThinkVantage на планшете эти пользователи должны иметь права администратора при использовании планшетов. Все в порядке - для них полезно иметь широкие привилегии, когда я провожу их через телефон, так что я не ищу обходной путь.

Я хотел бы использовать групповую политику для настройки следующего сценария: пользователи в определенной группе безопасности (или организационной единице) должны входить в группу BUILTIN / Administrators при входе на компьютеры в определенной группе безопасности (или организационной единице). Это нормально, если компьютеры должны быть в подразделении, но я бы предпочел распределять пользователей по группам.

Конечно, полевые работники не должны быть администраторами на других рабочих станциях, а сотрудники офисного офиса не должны быть администраторами на планшетах.

В настоящее время это решается локально на каждом планшете, но по мере добавления новых сотрудников это становится все труднее.

Я чувствую, что Restricted Groups - это ответ здесь, но без твердой основы в понятиях и методах AD, мне трудно сделать это.

Какова правильная техника для этой задачи, и как бы я ее реализовал?

Ответы:


13

Создайте группу для инкапсуляции пользователей (Local-Admins-Tablets) и добавьте их в эту группу.

Создайте подразделение OU текущих рабочих станций и поместите сюда планшеты (Workstations \ Tablets)

Создайте объект групповой политики (Local-Admins-Tablets-Policy) и свяжите его с OU рабочих станций \ Tablets

В объекте групповой политики установите следующее:

  • Comp Config - Политики - Настройки Windows - Настройки безопасности - Группы с ограниченным доступом
  • Щелкните правой кнопкой мыши, Добавить группу
  • «Администраторы», ОК
  • Члены этой группы: myDomain \ Local-Admins-Tablets

Перезагрузите ПК, и готово.

Имейте в виду, что настройка Restricted Groups перезапишет на машинах существующий список локальных администраторов. Если у вас уже есть другие пользователи / группы, вам необходимо добавить их и в эту политику. Другими примерами будут myDomain \ Domain Admins и т. Д.

РЕДАКТИРОВАТЬ: Да, и изменить фильтрацию в объекте групповой политики и добавить доменные компьютеры . Самый простой способ сделать это - использовать оснастку MMC для управления групповыми политиками (вы можете получить ее из средств удаленного администрирования сервера от Microsoft)


5
+1. Ограниченные группы является решением здесь. Для вступления изменений в силу достаточно gpupdate / force на рабочих станциях, что исключает необходимость перезагрузки.
Joeqwerty

Если планшеты находятся в поле , обычно пользователю проще перезагрузить компьютер, чем объяснять «open cmd, введите gpupdate / force / boot» и т. Д. :)
Izzy

1
Используя настройки групповой политики ( technet.microsoft.com/en-us/library/cc731892%28WS.10%29.aspx ), вы можете обновить локальную группу, не перезаписывая ничего.
Зоредаче

1
Ну, вот и все! Всего два вопроса: я так понимаю, это полностью уничтожит всех нынешних членов группы администраторов, включая локальных пользователей, правильно? Это может оказаться неприятным сюрпризом. Я предполагаю, что учетная запись администратора по умолчанию не будет затронута этим; это самонадеянно с моей стороны?
WCWedin

1
Я никогда не проверял это, я просто добавил Builtin \ Administrators в эту группу с ограниченным доступом. Пояс и подтяжки :)
Иззи

12

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

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

  • Создайте структуру OU / Group так же, как и раньше
  • Когда вы находитесь в разделе «Группы с ограниченным доступом» объекта групповой политики, добавьте группу, но вместо указания администраторов укажите YOURDOMAIN \ Local-Admins-Tablets .
  • В разделе «Эта группа является членом» нажмите «Добавить» и введите « Администраторы».

Это тонкое, но важное различие в работе двух секций. Члены этой группы эффективно работают так: «Группа A будет содержать только группы X, Y и Z». Эта группа является членом, эффективно работающим над тем, чтобы быть «убедитесь, что группа A является членом групп X, Y и Z».

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


2

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

Простой стартовый скрипт для добавления участников группы.

DomainName="example"
Set oShell = WScript.CreateObject("WScript.Shell")
Set oProcsEnv = oShell.Environment("Process")
ComputerName = oProcsEnv("COMPUTERNAME")
Set oGroup = GetObject("WinNT://" & ComputerName & "/" & "Administrators")
If Not oGroup.IsMember("WinNT://"&DomainName&"/_Group_Tablet_Admins") Then _
    oGroup.Add ("WinNT://"&DomainName&"/_Group_Tablet_Admins")

Предполагая, что он использует W2K8, чего я не могу сказать по его вопросу.
Joeqwerty

Настройки на стороне клиента поддерживаются в домене 2003r2. У меня просто не было ссылки на статью 2003r2 под рукой.
Зоредаче

Отредактировал вопрос по добавлению ОС. Похоже, что GPP хорошо подходит для этого сценария, поскольку пользователи вряд ли впоследствии изменят свои группы, что делает его временный характер спорным. Тем не менее, развертывание необходимых компонентов на каждом клиентском компьютере кажется огромной головной болью.
WCWedin

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

1

Единственная проблема с перечисленным решением состоит в том, что оно предоставляет права локального администратора всем компьютерам, к которым применяется эта политика. Обычно вы хотите предоставить права администратора только конкретной машине. Я заметил, что когда пользователь понимает, что у него есть права локального администратора, он устанавливает программное обеспечение для всех своих партнеров.

Есть несколько разных способов сделать это, но я мог бы просто предложить один. Поэтому выполните шаги, описанные выше, но также создайте группу для каждого компьютера, где пользователям требуются дополнительные права. Каждая из этих «групп компьютеров» добавляется в группу myDomain \ Local-Admins.

Затем пользователи добавляются в группу, соответствующую машине, к которой им необходим доступ.

Так что они администраторы, но только этой машины.


0

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

Я буду делать что-то вроде этого:

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

На каждой таблетке добавьте эту группу в группу администраторов.

Является ли это правильной техникой или нет, я не знаю. Это всего лишь первая идея, которая приходит ко мне на реализацию.


2
Это не должно быть добавлено вручную к каждой машине. Это то, для чего предназначена групповая политика
Иззи

1
При настройке нового планшета я должен добавить 15 пользователей на один планшет. При добавлении нового сотрудника мне нужно добавить одного пользователя к 20 планшетам. Обе проблемы, но механика перехода от машины к машине делает последний процесс утомительным и медленным. Тем не менее, ваш подход значительно облегчит это, даже если он не особенно элегантен.
WCWedin

1
+1 на этом голосовании, чтобы немного поднять его. Возможно, это не самое лучшее решение, но это правильное решение. Люди не должны быть опущены за то, чтобы предложить правильное решение только потому, что это не предпочтительное решение. Единственное, чего не хватает в этом решении - это использование групп с ограниченным доступом для автоматизации процесса добавления группы в группу локальных администраторов. Я говорю +1 за усилия и за вклад в ответ.
Joeqwerty

0

Я написал скрипт, который запускается как политика компьютера с правами администратора на локальной рабочей станции. Он проверяет последнее вошедшее в систему описание пользователя в AD, которое администратор домена может установить из «Active Directory Users and Computers», если оно содержит имя рабочей станции, сценарий добавляет пользователя в группу локальных администраторов, если имя рабочей станции отсутствует в Описание пользователя, оно удаляет пользователя из локальной группы администраторов. Описание может включать более одного имени компьютера, например:

Описание пользователя: «Локальный администратор на WKST-E445R и WKST-VM398»

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

Разве это не самое лучшее решение? :-)

Вот сценарий:

    @if "%debug%" neq "%username%" echo off
set ver=MakeLocalAdmin.cmd henrik@c o m m o r e.se 20150423
:: Adds last logged on domain user to local Administrators group if run by computer GPO with Administrative rights and the user's Comment contains Computername

set log=nul
:: or set log=c:\logs\MakeLocalAdmins.txt

:: Check who was last logged on user
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI" /v LastLoggedOnUser') DO (
set DomainAndUserName=%%G)

:: Remove the spaces
set DomainAndUserName=%DomainAndUserName: =%

:: Get only username part
set LastLoggedOnUserName=%DomainAndUserName:*\=%


:: Check OS language, so we can adapt to localized name of Admin group and Comment
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage') DO (
set Language=%%G)

echo %date% %Time% ; %0 ; %computername%; %LastLoggedOnUserName%; %DomainAndUserName%, %Language% >> %log%
goto %Language%

:: Add any langauage specific part below, but if an unknown install language is found,
:: an error 'label not found' should mean script terminates, but anyway make sure it terminates. 
goto end

:0409
:: English
net user /domain %LastLoggedOnUserName% | find "Comment " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrators /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrators /del "%DomainAndUserName%" >> %log%
goto end

:041D
:: Swedish 
:: †„” åäö (Swedish char's)
net user /domain %LastLoggedOnUserName% | find "Kommentar " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrat”rer /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrat”rer /del "%DomainAndUserName%" >> %log%
goto end



:end
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.