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

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

22.06.2022
itpro
Active Directory, PowerShell, Windows 10, Windows Server 2019, Групповые политики
комментариев 14

Для предоставления прав локального администратора на компьютерах домена сотрудникам техподдержки, службе HelpDesk, определенным пользователям и другим привилегированным аккаунтам, вам нужно добавить необходимых пользователей или группы Active Directory в локальную группу администраторов на серверах или рабочих станциях. В этой статье мы покажем несколько способов управления членами локальной группы администраторов на компьютерах домена вручную и через GPO.

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

Самый простой способ предоставить пользователю или группе права локального администратора на конкретном компьютере — добавить его в локальную группу Administrators с помощью оснастки “Локальные пользователи и группы” (Local users and groups — lusrmgr.msc).

После того, как вы добавили компьютер в домен AD, в локальную группу Administrators компьютера автоматически добавляется группы Domain Admins, а группа Domain User добавляется в локальную Users. Остальных пользователей вы можете добавить в группу администраторов вручную или с помощью GPO.

Нажмите кнопку Add и укажите имя пользователя, группы, компьютера или сервисного аккаунта (gMSA), которому вы хотите предоставить права локального администратора. С помощью кнопки Location вы можете переключать между поиском принципалов в домене или на локальном компьютере.

Также вы можете вывести список пользователей с правами локального администратора компьютера из командной строки:

net localgroup administrators

net localgroup администраторы

Для получения списка пользователей в локальной группе можно использовать следующую команду PowerShell (используется встроенный модуль LocalAccounts для управления локальными пользователями и группами):

Данная команда показывает класс объекта, которому предоставлены права администратора (ObjectClass = User, Group или Computer) и источник учетной записи или группы (ActiveDirectory, Azure AD или локальные пользователи/группы).

Чтобы добавить доменную группу (или пользователя) spbWksAdmins в локальные администраторы, выполните команду

net localgroup administrators /add spbWksAdmins /domain

Через PowerShell можно добавить пользователя в администраторы так:

Add-LocalGroupMember -Group Administrators -Member (‘winitpro\a.novak’, ‘winitpro\spbWksAdmins’,’wks-pc11s22\user1′) –Verbose

В этом примере мы добавили в администраторы компьютеры пользователя и группу из домена winitpro и локального пользователя wks-pc11s22\user1.

Можно добавить пользователей в группу администраторов на нескольких компьютерах сразу. В этом случая для доступа к удаленного компьютерам можно использовать командлет Invoke-Command из PowerShell Remoting:

$WKSs = @(«wks1″,»wks2″,»wks3»)
Invoke-Command -ComputerName $WKSs –ScriptBlock

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

• Ограниченные группы (Restricted Groups)
• Управление локальным группами через предпочтения групповых политик (Group Policy Preferences)

Добавляем пользователей в локальную группу администраторов через Group Policy Preferences

Допустим, вам нужно предоставить группе сотрудников техподдержки и HelpDesk права локального админа на компьютерах в конкретном OU Active Directory. Создайте в домене новую группу безопасности с помощью PowerShell и добавьте в нее учетные записи сотрудников техподдержки:

New-ADGroup «mskWKSAdmins» -path ‘OU=Groups,OU=Moscow,DC=winitpro,DC=ru’ -GroupScope Global –PassThru
Add-AdGroupMember -Identity mskWKSAdmins -Members user1, user2, user3

Откройте консоль редактирования доменных групповых политик (GPMC.msc), cоздайте новую политику AddLocaAdmins и назначьте ее на OU с компьютерами (в моем примере это ‘OU=Computers,OU=Moscow,dc=winitpro,DC=ru’).

Предпочтения групповых политик (Group Policy Preferences, GPP) предоставляют наиболее гибкий и удобный способ предоставления прав локальных администраторов на компьютерах домена через GPO.

1. ткройте созданную ранее политику AddLocaAdmins в режиме редактирования;
2. Перейдите в секцию GPO: Computer Configuration –> Preferences –> Control Panel Settings –> Local Users and Groups;
3. Щелкните ПКМ по правому окну и добавите новое правило (New -> Local Group);
4. В поле Action выберите Update (это важная опция!);
5. В выпадающем списке Group Name выберите Administrators (Built-in). Даже если эта группа была переименована на компьютере, настройки будут применены к группе локальных администраторов по ее SID — S-1-5-32-544 ;
6. Нажмите кнопку Add и укажите группы, которые нужно добавить в локальную группу администраторов (в нашем случае это mskWKSAdmins).

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

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

Чтобы предоставить права лок. админа на одном конкретном компьютере можно использовать WMI фильтры GPO или Item-level Targeting.

Прямо в созданной ранее политике AddLocalAdmins в секции предпочтений (Computer Configuration –> Preferences –> Control Panel Settings –> Local Users and Groups) создайте новую запись для группы Administrators со следующими настройками:

1. Action: Update
2. Group Name: Administrators (Built-in)
3. Description: “Добавление apivanov в лок. администраторы на компьютере msk-ws24”

Также обратите внимание на порядок применения групп на компьютере – Order. Настройки локальных групп применяются сверху вниз (начиная с политики с Order 1).

Первая политика GPP (с настройками “Delete all member users” и “Delete all member groups” как описано выше), удаляет всех пользователей/группы из группы локальных администраторов и добавляет указанную доменную группу. Затем применится дополнительная политика для конкретного компьютера и добавит в группу вашего пользователя. Если нужно изменить порядок применения членства в группе Администраторы, воспользуйтесь кнопками вверху консоли редактора GPO.

Управление локальными администраторами через Restricted Groups

Политика групп с ограниченным доступом (Restricted Groups) также позволяет добавить доменные группы/пользователей в локальные группы безопасности на компьютерах. Это более старый способ предоставления прав локального администратора и сейчас используется реже (способ менее гибкий, чем способ с Group Policy Preferences).

1. Перейдите в режим редактирования политики;
2. Разверните секцию Computer Configuration -> Policies -> Security Settings -> Restrictred Groups (Конфигурация компьютера -> Политики -> Параметры безопасности -> Ограниченные группы);
3. В контекстном меню выберите Add Group;
4. В открывшемся окне укажите Administrators -> Ok;
5. В секции “Members of this group” нажмите Add и укажите группу, которую вы хотите добавить в локальные админы;
6. Сохраните изменения, примените политику на компьютеры пользователей и проверьте локальную групп Administrators. В ней должна остаться только указанная в политике группа.

Если вам нужно оставить текущий список группы Administrators и добавить в нее дополнительную группу нужно:

1. Создать новый элемент в Restricted Groups и указать в качестве имени группу безопасности AD, которую вы хотите добавить в локальные админы;
2. Затем в разделе This group is a member of нужно добавить группу Administrators;
3. Обновите настройки GPO на клиенте и убедитесь, что ваша группа была добавлена в локальную группу Administrator. При этом текущие принципалы в локальной группе остаются неторонутыми (не удаляются из группы).

В конце статьи оставлю базовые рекомендации по управлению правами администраторов на компьютерах пользователей AD:

В классических рекомендациях по безопасности Microsoft рекомендуется использовать следующие группы для разделения полномочиями администраторов в домене:

DomainAdmins– администраторы домена, используются только на контроллерах домена;

Работа с предпочтениями групповой политики: взаимодействие с локальными учетными записями

Как вы знаете, такие расширения клиентской стороны технологии групповой политики, как элементы предпочтения, по сути, позволяют вам выполнять большинство различных сценариев, которые попросту невозможно реализовать при помощи административных шаблонов или же параметров безопасности. Ввиду того, что весь набор предпочтений групповой политики включает в себя 21 расширение клиентской стороны (включая неработающие элементы предпочтений приложений), можно прийти к выводу, что практически все те операции, которые решались средствами сценариев можно реализовать путем таких расширений CSE.
Одно и таких расширений клиентской стороны позволяет вам управлять учетными записями пользователей и групп, которые можно найти на каждой машине еще при установке самой операционной системы. С такими учетными записями приходится сталкиваться не столь часто, но иногда могут возникнуть ситуации, когда вам придется выполнять некоторые операции по их обслуживанию, и знание того, по какому принципу следует выполнять такое обслуживание, будет как никогда кстати.
Вот как раз на таких учетных записях и сценариях по их обслуживанию мы с вами и остановимся в этой статье. Далее вы узнаете о том, какие бывают локальные учетные записи пользователей, кое-что узнаете об учетных записях групп, а также о том, каким образом можно управлять такими объектами при использовании функциональных возможностей групповой политики и элемента предпочтений «Локальные пользователи и группы». А начинать мы сейчас будем с

Определения локальных учетных записей

• Учетная запись «Администратор», которая предоставляет полный доступ на управление клиентским компьютером или же сервером и позволяет при необходимости назначать права пользователей и разрешения на управление доступом. Эта запись, в любом случае, должна использоваться только для задач, выполнение которых требует учетных данных администратора и сам административный маркер доступа. Для этой учетной записи настоятельно рекомендуется использовать надежный пароль.
• Учетная запись «Гость» используется теми, кто не имеет реальной учетной записи на целевом компьютере. Если учетная запись пользователя отключена, но не удалена, он также может воспользоваться учетной записью «Гость». Учетная запись «Гость» не требует пароля. По умолчанию она отключена, но ее всегда в случае необходимости можно включить. Учетной записи «Гость», как и любой другой учетной записи, можно предоставлять права и разрешения на доступ к объектам. По умолчанию она входит в группу «Гости», используемую по умолчанию, и позволяет пользователю войти локально на целевой компьютер. Дополнительные права, как любые разрешения, могут быть присвоены группе «Гости» членом группы «Администраторы». По умолчанию данная учетная запись отключена, и зачастую рекомендуется оставить ее в этом положении.

Использование элемента предпочтения групповой политики «Локальные пользователи и группы»

Создавая элементы предпочтения с этим расширением клиентской стороны, вы можете создавать, переименовывать, удалять учетные записи локальных пользователей, а также изменять и сбрасывать пароли, отключать учетные записи пользователей и выполнять прочие действия. Помимо этого, если смотреть на вторую возможность этого CSE, вы еще можете создавать, переименовывать, удалять, а также изменять членство в локальных группах.
В следующих примерах будут выполнены сценарии, благодаря которым будет создана новая локальная учетная запись, изменен пароль для учетной записи локального администратора, а также в группу «Администраторы» будет добавлено несколько учетных записей пользователей.
Так как для каждого из этих сценариев мы с вами будем использовать один и тот же узел редактора управления групповыми политиками, еще до выполнения пошаговых процедур нужно будет выполнить предварительные действия. Для этого в оснастке «Управление групповой политикой» будет создан новый объект групповой политики, который будет называться, скажем, «Group Policy Preferences — 17», и, несмотря на то, что все элементы предпочтения будут создаваться в узле конфигурации компьютера, исключительно для простоты, этот объект групповой политики связывается со всем доменом. Теперь остается лишь выбрать только что созданный объект GPO и из контекстного меню открыть для него редактор управления групповыми политиками.
Можно переходить к самим сценариям.

Сценарий 1

Для начала будет создаваться новая учетная запись, и для этого в отобразившейся оснастке редактора управления групповыми политиками следует перейти к узлу Конфигурация компьютера\Настройка\Параметры панели управления\Локальные пользователи и группы (Computer Configuration\Preferences\ Control Panel Setting\ Local Users and Groups). Будучи в этом узле, следует в области сведений вызвать контекстное меню, а затем, как видно на следующей иллюстрации, выбрать команду «Создать», а затем «Локальный пользователь» (New > Local User):

Рис. 1. Создание элемента предпочтений групповой политики локального пользователя

В отличие от диалоговых окон свойств рассматриваемой ранее большей части элементов предпочтений, здесь сразу заметно, что данное диалоговое окно заполнено различными настройками практически полностью. Попробуем постепенно в процессе создания двух элементов предпочтений полностью разобраться со всеми этими настройками.
С назначениями действий текущего элемента предпочтения, полагаю, все понятно и без слов, поэтому, так как в первом сценарии будет создаваться учетная запись локального пользователя, выбирается действие «Создать» (Create). Касательно действий следует отметить одну деталь: при выборе действия «Обновить» (Update) идентификатор безопасности SID у обновляемой учетной записи не изменяется, а вот если вы будете заменять учетную запись, в таком случае SID будет присваиваться новый, так как учетная запись сперва будет удалена, а после будет создаваться такая учетка, свойства которой вы будете указывать. На это обязательно следует обращать внимание.
В раскрывающемся списке «Пользователь» (User name) вы можете либо выбрать учетную запись из списка существующих, что удобно при обновлении, замене или удалении существующей учетной записи, либо для создания новой учетной записи можно просто ввести имя нового пользователя, что, собственно, сейчас и будет сделано. Именем такой учетной записи пусть будет, скажем, «MBeasley».
Текстовое поле «Переименовать» (Rename to) позволяет изменять имя учетной записи пользователя, определённого в предыдущем раскрывающемся списке, на то, которое будет указано в текущем текстовом поле. По вполне понятным причинам это поле доступно только для действия «Обновить» (Update), а сейчас оно, как вы вскоре заметите на второй иллюстрации, попросту заблокировано.
Как можно сразу догадаться, текстовое поле «Полное имя» (Full name) предназначено для заполнения ФИО создаваемого пользователя. Чтобы имя нашего пользователя сразу стало понятным, назовем его «Michael Beasley». В текстовом поле «Описание» (Description) вы можете добавить некую дополнительную информации о создаваемом или изменяемом пользователе. Пусть будет написано около этого пользователя, например, «Новая учетная запись».
В следующих двух текстовых полях – «Пароль» и «Подтверждение» (Password и Confirm Password) – вам необходимо указать и, естественно, подтвердить пароль для создаваемой или изменяемой учетной записи. Сразу предупрежу, что изощряться с генерированием пароля в этом случае вам не стоит. Объясню, почему так. Этот пароль вы задаете в объекте групповой политики, а групповые политики хранятся в общедоступной папке SYSVOL. Следовательно, локализовав требуемый объект групповой политики, можно вычислить пароль, что никоим образом положительно не скажется. Между прочим, о том, как можно расшифровать такие пароли, вы можете прочитать в статье Сергея Мариничева «Еще раз про пароли». Поэтому, если вы планируете изменять пароли для каких-либо жизненно важных учетных записей, воздержитесь от использования элементов предпочтений, а реализуйте это каким-либо иным методом. Сейчас же просто будет добавлен стандартный пароль, используемый в тестовых целях, то есть P@ssw0rd.
Также в элементе предпочтения сразу установлен флажок на опции «Требовать смену пароля при следующем входе в систему» (User must change password at next logon), и я рекомендую, чтобы этот флажок там и оставался. От пользователя не убудет, если он поменяет для своей учетной записи пароль при первом входе. Конечно, если такой пароль не будет еще более уязвимым.
Практически все следующие опции мы рассмотрим в следующем примере, а сейчас мне хотелось бы остановиться на опции «Срок действия учетной записи не ограничен» (Account never expires). Если необходимо, чтобы создаваемая учетная запись имела срок жизни, требуется снять этот флажок, а затем в соответствующем управляющем компоненте указать дату истечения действия текущей учетной записи, например, здесь укажем 21 января 2014 года. Не будем добавлять никакого нацеливания для этого создаваемого пользователя, а просто перейдём к следующему примеру. Здесь стоит обратить внимание на то, что даже при сохранении элемента предпочтения редактор управления групповыми политиками предупреждает вас о том, что этот пароль можно легко обнаружить, главное, как говорится, было бы желание.
Диалоговое окно со всеми определенными ранее настройками видно на следующей иллюстрации:

Рис. 2. Диалоговое окно создания новой учетной записи локального пользователя

Сценарий 2

В этом примере будет изменяться пароль для учетной записи локального администратора. Как вы поняли, создавать постоянный пароль при помощи элементов предпочтения небезопасно, но сейчас это делается исключительно в целях демонстрации функциональных возможностей предпочтений групповой политики. Сейчас нам следует создать новый элемент предпочтения локального пользователя, где нужно выбрать действие «Обновить» (Update). Из следующего раскрывающегося списка выбираем встроенную учетную запись администратора и переходим к следующим полям. Как вы заметите ниже на третьей иллюстрации, сейчас текстовое поле «Переименовать» (Rename to) уже стало доступным для внесения данных, и мы этим обязательно воспользуемся. Переименуем учетную запись, скажем, в «TrueAdmin» и будем двигаться дальше.
Сейчас мы изменим этому пользователю пароль и для демонстрации работы следующих опций снимем флажок с опции «Требовать смену пароля при следующем входе в систему» (User must change password at next logon). Так как пользователю более не нужно будет изменять свой пароль вручную при входе в систему, для изменения стали доступными опции «Запретить смену пароля пользователем» (User cannot change password), а также «Срок действия пароля не ограничен» (Password never expires). Этими опциями вы уже пользовались, скорее всего, не одну сотню раз при создании доменных учетных записей пользователей, но (на всякий случай) первая опция запрещает пользователю менять свой пароль, и ему придется жить с указанным вами паролем до тех пор, пока вы сами его не измените, а вторая снимает ограничения с регулярного изменения пароля. Для примера установим флажок только на опции «Срок действия пароля не ограничен» (Password never expires).
Если вам необходимо отключить учетную запись какого-то пользователя, например, гостевую запись, – без проблем! Достаточно лишь установить флажок на опции «Отключить учетную запись» (Account is disabled). Тоже не будем создавать какую-то дополнительную фильтрацию, а просто дважды нажмем на «ОК» для сохранения внесенных изменений.

Рис. 3. Изменение встроенной учетной записи администратора

Сценарий 3

Остался третий, заключительный пример, в котором в группу «Администраторы» будет добавлено несколько учетных записей пользователей. Для того чтобы реализовать эту задачу, мы воспользуемся вторым типом элемента предпочтения из текущего узла – «Локальная группа» (Local Group). В отобразившемся диалоговом окне, как в конце этого сценария будет видно на иллюстрации, уже нет такого огромного количества параметров, зато есть некоторые новые управляющие элементы, с которыми мы сейчас буквально за несколько минут разберемся.
Прежде всего, рассмотрим четыре стандартных действия, где в подавляющем большинстве случаев я рекомендую использовать именно действие «Обновить» (Update), естественно, если вам не нужно создавать новую или же удалять какую-либо существующую локальную группу. Действие «Заменить» (Replace) работает по аналогии с элементами предпочтения локальных пользователей, поэтому перед его использованием следует трижды подумать, так ли это вам необходимо.
В раскрывающемся списке «Имя группы» (Group name) вы, как и в предыдущих двух примерах, можете либо выбрать уже существующую группу, либо создать новую. Так как нам нужно в группу локальных админов добавить нескольких пользователей, мы остановимся на существующих группах и выберем группу «Администраторы».
Если вы хотите дать существующей группе новое имя, воспользуйтесь возможностями текстового поля «Переименовать» (Rename to). Всегда удобно, если у вас все красиво оформлено и задокументировано, поэтому вы можете добавить подробное описание для своей группы в соответствующем текстовом поле. Например, в описании можно ввести «Администраторы имеют полные, ничем не ограниченные права доступа на локальном компьютере».
На каждом компьютере в группы локальных администраторов может входить что угодно, ведь вы не можете предугадать все действия ваших пользователей. Специально для этого здесь предусмотрены две замечательные опции: «Удалить всех пользователей-членов для этой группы» (Delete all member users) и «Удалить все группы-члены для этой группы» (Delete all member groups). При помощи первого параметра вы удалите все учетные записи пользователей, которые принадлежат к этой группе, а второй параметр, соответственно, позволяет удалить все группы. Естественно, как первая, так и вторая опция отработает до того, как будут добавляться члены, настроенные при помощи этого элемента предпочтения.
Для того чтобы были добавлены новые учетные записи пользователей и групп, необходимо воспользоваться самым нижним контроллом, то есть группой параметров «Члены группы». В эту группу обязательно должны входить как локальные, так и доменные администраторы, поэтому, если вы удалили учетные записи при помощи соответствующих флажков, следует нажать на кнопку «Добавить» (Add) и в соответствующем текстовом поле ввести «Builtin\Администратор», после чего нажать на кнопку «ОК». Повторим эти же действия с нашим TrueAdmin-ом, а затем добавим администраторов домена. Можно либо выбрать эту группу из соответствующего списка, либо нажать на клавишу F3 и воспользоваться переменной %DomainName%, потом указать имя группы, то есть Администраторы домена, затем уже можно сохранять все внесенные изменения. На следующей иллюстрации вы можете увидеть данное диалоговое окно:

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

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

Сообщения: 4677
Благодарности: 1091

Конфигурация компьютера
Процессор: Core™i5 (3427M)
Память: 8Gb DDR3
Видеокарта: Intel HD Graphics
Ноутбук/нетбук: Dell Latitude 6430u
ОС: Windows 7 Enterprise

тогда как войти под локальной учеткой? »

——-
в личке я не консультирую и не отвечаю на профессиональные вопросы. для этого есть форум.

Сообщения: 232
Благодарности: 1

Последний раз редактировалось

, 14-06-2012 в 13:40 .

Сообщения: 5624
Благодарности: 935

ЛОкального админа никак не включишь, если только удалять AD. »

есть только учётные записи вида domain\user »

изменить "политику паролей", но она заблокирована »

Сообщения: 232
Благодарности: 1

Сообщения: 26104
Благодарности: 4379

почему на десктопной ОС можно заходить под локальным пользователем?

——-
— Пал Андреич, Вы шпион?
— Видишь ли, Юра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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