Включение и отключение встроенной учетной записи администратора
При производстве компьютеров можно использовать встроенную учетную запись администратора для запуска программ и приложений перед созданием учетной записи пользователя.
Этот раздел посвящен производству компьютеров. Для получения справки по учетной записи администратора на вашем компьютере воспользуйтесь одной из следующих страниц:
- Вход с правами администратора
- Удаление учетной записи с именем «Администратор»
- Контроль учетных записей пользователей
Эта учетная запись используется при входе в систему в режиме аудита или при добавлении скриптов в этап конфигурации auditUser .
Включение встроенной учетной записи администратора
Для включения встроенной учетной записи администратора можно использовать любой из следующих способов:
- Использование файла ответов
- Вход в систему в режиме аудита
- Использование MMC «Локальные пользователи и группы» (только для версий сервера)
Использование файла ответов
Вы можете включить встроенную учетную запись администратора во время автоматической установки, задав AutoLogon для параметра значение Администратор в компоненте Microsoft-Windows-Shell-Setup. Это позволит включить встроенную учетную запись администратора, даже если пароль не указан в параметре AdministratorPassword .
Файл ответов можно создать с помощью диспетчера системных образов Windows (Windows SIM), который доступен в комплекте средств для развертывания и оценки.
В следующем примере файла ответов показано, как включить учетную запись администратора, указать пароль администратора и автоматически войти в систему.
Microsoft-Windows-Shell-Setup\Autologon Раздел и Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword раздел необходимы для работы автоматического входа в режиме аудита. Этап конфигурации auditSystem должен включать оба этих параметра.
В следующих выходных данных XML показано, как задать соответствующие значения:
SecurePasswd123 true Administrator true 5 SecurePasswd123 true
Чтобы избежать необходимости вводить пароль для встроенной учетной записи администратора после завершения работы с готовым интерфейсом, задайте в Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword параметре oobeSystem configuration pass (Настройка oobeSystem ).
В следующих выходных данных XML показано, как задать соответствующие значения:
SecurePasswd123 true
Вход в систему в режиме аудита
Если компьютер еще не прошел через встроенный интерфейс (OOBE), вы можете войти в встроенную учетную запись администратора, повторно перейдя в режим аудита. Дополнительные сведения см. в разделе Загрузка Windows в режиме аудита или при первом включении компьютера.
Использование MMC «Локальные пользователи и группы» (только для версий сервера)
Измените свойства учетной записи администратора с помощью консоли управления (MMC) локальных пользователей и групп.
- Откройте MMC и выберите Локальные пользователи и группы.
- Щелкните правой кнопкой мыши учетную запись администратора и выберите Свойства. Откроется окно Свойства администратора .
- На вкладке Общие снимите флажок Учетная запись отключена проверка.
- Закройте MMC.
Теперь доступ администратора включен.
Отключение встроенной учетной записи администратора
Для новых установок после того, как пользователь создаст учетную запись пользователя в OOBE, встроенная учетная запись администратора будет отключена.
Для установки обновления встроенная учетная запись администратора остается включенной, если на компьютере нет других активных локальных администраторов и компьютер не присоединен к домену.
Чтобы отключить встроенную учетную запись администратора, используйте один из следующих способов:
- Выполнение команды sysprep /generalize При выполнении команды sysprep /generalize при следующем запуске компьютера встроенная учетная запись администратора будет отключена.
- Использование команды net user Выполните следующую команду, чтобы отключить учетную запись администратора:
net user administrator /active:no
Изготовители оборудования (OEM) и сборщики систем должны отключить встроенную учетную запись администратора перед доставкой компьютеров клиентам. Для этого можно использовать один из следующих методов.
Настройка встроенного пароля администратора
При выполнении команды sysprep /generalize Sysprep сбрасывает пароль встроенной учетной записи администратора. Средство Sysprep очищает пароль встроенной учетной записи администратора только для серверных выпусков, но не для клиентских выпусков. При следующем запуске компьютера программа установки отобразит запрос на ввод пароля.
Builtin администраторы что это
Сообщения: 105
Благодарности: 5
здравствуйте, уважаемые форумчане !
есть следующий вопрос, который наверняка уже много раз задавался, но найти его не так-то просто
вот скажите, пожалуйста, кто на сервере в windows server (например, 2008 r2) входит в состав группы BUILTIN\Администраторы ?
1. это те пользователи, которые на самом сервере входят в локальную группу Администраторы
2. это те пользователи, которые входят в локальную группу Администраторы на сервере, и в локальную группу Администраторы на клиентских машинах в домене
3. как-то ещё (и совсем по-другому, как?)
контекст вопроса — групповые политики:
если в объекте групповой политики указать разрешения для BUILTIN\Администраторы,
1. эти разрешения будут распространяться (требования политики будут применяться к) только если войти под пользователем Администратор (или входящем в группу Администраторы) на самом сервере,
2.эти разрешения будут распространяться на (требования политики будут применяться к) пользователей, входящих в локальные группы Администраторы на клиентских машинах в домене
3. как-то ещё (и совсем по-другому, как?)
и такой же вопрос относительно учетной записи system(система)
1. это пользователь «система» на самом сервере,
2. это пользователь «система» на самом сервере и на клиентских машинах в домене
3. как-то ещё (и совсем по-другому, как?)
контекст вопроса тоже связан с объектами групповых политик (разрешения в объекте)
спасибо за уделённое моей проблеме, время
с уважением, я
Я правильно понимаю права группы Администаторы?
Мне нужно дать юзеру права администратора на его ПК (Он юзает очень дикий спец софт). Как это сделать? В домене есть группа Администраторы и Администраторы домена. В чем разница? Администраторы это локальные администраторы?
- Вопрос задан более трёх лет назад
- 4015 просмотров
Комментировать
Решения вопроса 2

Внимание! Изменился адрес почты!
Нужно подключиться к его компу оснасткой управления компьютером и добавить его учетку в локальную группу «Администраторы» на его компьютере. После чего скорее всего ему нужен будет ребут.
Ответ написан более трёх лет назад
Нравится 5 4 комментария

Ульрих @ulrich-schnauss
+1 и никаких велосипедов
Ребут не обязателен, достаточно перелогиниться
Безопаснее наверно все-таки не учетку юзера добавить в локальные администраторы, а просто добавить еще одну локальную учетную запись с правами администратора и при надобности в повышении прав использовать «Запуск от имени. «.

Денис: Не будет разраб постоянно делать запуск от имени. Это притормозит его работу и в конечном итоге он просто руководству доложит — и все равно придется убрать. Поэтому обычно когда разрабам даются права локальных админов, другие оргвопросы сразу решаются
Администраторы (Administrators) — находится в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы (Administrators) в корневом домене леса может изменять членство в группах Администраторы предприятия (Enterprise Admins), Администраторы Схемы (Schema Admins) и Администраторы домена (Domain Admins). Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.
Администраторы домена (Domain Admins) — находится в контейнере Users каждого домена. Эта группа входит в группу Администраторы своего домена. Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ

- Linux
- +2 ещё
Существуют визуальные панели управления сервером?
- 3 подписчика
- вчера
- 396 просмотров
Встроенные группы домена
Группы — это объекты, являющиеся участниками системы безопасности (security principals) и предназначенные для управления доступом к ресурсам. Каждой группе присваивается уникальный идентификатор безопасности (Security Identifier, SID), который сохраняется в течение всего срока службы.
Условно группы можно разделить по области их действия.
Локальные группы
Локальные группы безопасности создаются на локальном компьютере, и использовать их можно для управления доступом к ресурсам, находящимся только на этом компьютере. Управляются они менеджером учетных записей безопасности (Security Account Manager, SAM).
Локальные группы можно условно разделить на два типа — встроенные (BuiltIn) и дополнительно созданные. Встроенные группы — это группы, имеющиеся в операционной системе по умолчанию, например та же группа Administrators. Ну а дополнительно созданные — группы, созданные вручную, для предоставления доступа к локальным ресурсам, например общим папкам.

Различить эти группы легко можно по SID-у. У встроенных групп SID формата S-1-5-32-XXX, где XXX — число от 500 до 1000. У обычных же формат вида S-1-5-21-XXX-XXX-XXX-YYY, где XXX-XXX-XXX — это 48-битный идентификатор системы, YYY- относительный идентификатор (Relative ID, RID). RID состоит из четырех чисел (от 1000 и больше) и однозначно идентифицирует участника безопасности в локальном домене.

Примечание. SID-ы встроенных групп во всех операционных системах Windows идентичны.
Доменные группы
С локальными группами все более менее понятно, переходим к доменным. Группы безопасности в домене Active Directory разделяются по области применения:
• Локальные в домене (Domain Local);
• Глобальные (Global);
• Универсальные (Universal).
Для наглядности сведем различия между ними в таблицу.
| Область применения | Может включать в себя | Может быть преобразована | Может предоставлять разрешения | Может быть участником групп |
|---|---|---|---|---|
| Локальные в домене | Учетные записи из любого домена или любого доверенного домена |
Глобальные группы из любого домена или любого доверенного домена
Универсальные группы из любого домена в одном лесу
Другие локальные группы домена из того же домена
Другие глобальные группы из того же домена
Глобальные группы из любого домена в одном лесу
Локальные группы в одном лесу или доверенных лесах
Встроенные доменные группы
И вот теперь плавно переходим к группам, ради которых и задумана эта статья, а именно встроенные группы домена (Builtin Local).
При повышении сервера до контроллера домена локальная база SAM становится недоступной, так же как и оснастка Local Users and Groups, а для входа на сервер используется база данных Active Directory. Это сделано с целью повышения безопасности.

Примечание. Единственный случай, когда для входа на контроллер домена используется SAM — это загрузка в режиме восстановления (Directory Service Restore Mode, DSRM). Это связано с тем, что пароль администратора DSRM хранится локально в базе SAM, а не в Active Directory (что вполне логично).
А что же происходит с локальными группами на сервере, когда мы делаем его контроллером домена? Сам сервер становится общей базой данных пользователей, групп и других объектов безопасности в домене, а все его локальные пользователи и группы переносятся в базу Active Directory. Пользователи и дополнительно созданные группы попадают в контейнер Users

а встроенные группы — в Builtin.

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

Не смотря на то, что формально встроенные доменные группы считаются Domain Local, на практике они стоят отдельно от остальных групп и имеют свою уникальную область действия.

Для примера возьмем группу, созданную вручную, и сравним ее со встроенной доменной.

Как видите, у обоих групп SID остался таким же, как был на локальном сервере. И так же, как у локальных групп, встроенные группы домена не содержат в своем SID-е идентификатор домена. По сути встроенные доменные группы дублируют локальные встроенные группы, но на уровне домена. Как я уже говорил, SID встроенных групп во всех операционных системах Windows идентичны, и получается, что на каждом компьютере домена (кроме домен-контроллеров) имеются свои локальные встроенные группы, идентификаторы которых совпадают с идентификаторами встроенных групп домена.
Поэтому использовать их на рабочих станциях и рядовых серверах домена невозможно. Например, вы не сможете добавить добавить доменных BuiltIn\Administrators в список доступа на файловую шару на рядовом сервере домена, ее там просто не будет видно. Область действия доменных Builtin Local групп ограничена системами, на которых локальная база SAM недоступна — то есть контроллерами домена.
Domain Local группы, созданные из обычных локальных групп, такого ограничения не имеют. Их SID содержит компонент с идентификатором домена, поэтому уникальность в сравнении с другими локальными группами домена сохраняется. Что важно — при превращении сервера в первый контроллер домена в новом домене SID этих групп не меняется. Поэтому если создать на сервере локальную группу и выдать ей права например на папку с файлами, то после повышения сервера эта группа станет Domain Local и все её права сохранятся.
Но вернемся к нашим баранам Builtin Local группам и рассмотрим их поподробнее.
Как видите, не смотря на ограниченную область действия встроенные группы домена обладают весьма широкими возможностями. Особенно аккуратно стоит относиться к группе Administrators, которая имеет неограниченные полномочия в рамках всего домена, а в корневом домене леса — и во всем лесу.
Как можно использовать Builtin Local группы и стоит ли это вообще делать? Вопрос спорный. Практически все административные задачи можно решить с помощью обычных доменных групп, поэтому лично я стараюсь встроенные группы не использовать. В качестве заключения расскажу одну историю, приключившуюся со мной лично.
Итак, есть организация. В организации, как положено, есть отдел техподдержки, который занимается поддержкой пользователей. Чтобы сотрудники техподдержки имели возможность заходить на компьютеры пользователей, всех их добавляют в локальные админы с помощью групповой политики.
И вдруг оказывается, что некоторые сотрудники техподдержки каким то образом заходят на контроллеры домена и вносят изменения в Active Directory, хотя прав на это у них быть не должно. В группе доменных админов они отсутствуют, делегированных полномочий тоже нет. А права тем не менее есть.
Стали выяснять и оказалось, что политика, которая добавляет пользователей в локальные админы, применена ко всему домену. Отработала она и на контроллерах домена, и поскольку локальных администраторов там нет, добавила техподдержку в доменную Builtin\Administrators. Со всеми вытекающими последствиями.
Ничего страшного в итоге не произошло, политику переназначили, пользователей из группы убрали. Но после этого я стараюсь со встроенными группами обращаться очень аккуратно