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

Группы пользователей в Windows — локальные пользователи и группы

Это первая из двух статей, посвященных группам пользователей в Windows. Сегодня поговорим о локальных пользователях и группах, вторая статья будет посвящена группам в Active Directory.

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

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

Посмотреть перечень существующий в системе групп можно через консоль Управление компьютером. Она находится в Панели управления, раздел Администрирование.

Администраторы — группа локальных администраторов, способных управлять конкретным компьютером. Локальные администраторы не являются администраторами домена;

Администраторы Hyper-V — группа пользователей, имеющий полный доступ к функциям Hyper-V. Не являются локальными администраторами и администраторами домена;

Гости — по умолчанию члены этой группы имеют те же права, что и пользователи, за исключением учетной записи Гость, которая ещё больше ограничена в правах;

Операторы архива — имеют права на создание резервных копий и восстановления из них даже тех объектов, к которым не имеют доступа;

Операторы настройки сети — имеют административные права для настройки сетевых параметров операционной системы;

Опытные пользователи — на текущий момент оставлена для совместимости с предыдущими версиями Windows. Может быть использована для разграничения прав пользователей. Например, если одним пользователям на компьютере нужно больше прав, чем другим;

Пользователи — основная пользовательская группа. Пользователи могут изменять крайне ограниченное число настроек, но, как правило, могут запускать большинство приложений в системе;

Пользователи DCOM — члены этой группы могут запускать, активизировать и использовать объекты DCOM;

Пользователи журналов производительности — по функционалу похожа на группу Пользователи системного монитора, но имеет куда больший доступ к Системному монитору, который позволяет отследить использование ресурсов компьютера;

Пользователи удаленного рабочего стола — состоящие в данной группе пользователи могут подключаться к указанному компьютеру через удалённый рабочий стол;

Читатели журнала событий — входящие в эту группу пользователи могут просматривать журналы событий компьютера;

IIS_IUSRS — группа, появившаяся в IIS 7.0 как замена группе IIS_WPG. Операционная система автоматически заносит в данную группу учётные записи, когда они назначаются в качестве удостоверения для пула приложений. Как правило, эта группа не требует действий со стороны администратора.

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

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

Если вы знаете имя пользователя/группы, просто введите его в большое поле и нажмите Проверить имена. Обратите внимание также на кнопки Типы объектов и Размещение. Нажав на первую, можно выбрать объекты, которым мы ищем. Нажав на вторую, указать место поиска объектов (локальный компьютер или домен). Внизу ещё есть кнопка Дополнительно, она открывает окно с более удобным интерфейсом поиска.

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

Удалить пользователя/группу из группы ещё проще. Просто откройте свойства интересующей вас группы, выделите пользователя/группу и нажмите кнопку Удалить.

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

Что ещё можно сделать с группами? Щёлкнем по группе правой кнопкой мыши, чтобы вызвать контекстное меню (альтернатива — выделить группу и открыть меню Действие).

Как видим, группу ещё можно переименовать и удалить. Естественно, можно создать и новую группу. Для этого, не выделяя никакую из существующих групп, либо воспользуйтесь меню Действие → Создать группу, либо щёлкните правой кнопкой мыши по пустой области, чтобы вызвать контекстное меню с этим пунктом.

Создание группы в Windows.

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

Как видите, наша группа появилась в перечне групп.

Теперь поговорим о том, для чего можно использовать группы в Windows. Как уже было сказано, главное предназначение групп — разграничение прав в системе. Для нас важно понимать как группы используются для назначения прав на уровне файловой системы.

Группы позволяют гибко настраивать права на файлы и каталоги. В конечном счёте, таким образом мы можем определять, кому разрешено запускать исполняемые файлы (а значит и программы), кто может добавлять, удалять, читать файлы в папках. Это может быть не так важно на домашнем компьютере, где небольшое число пользователей. А вот в корпоративном сегменте важно.

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

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

Нажмите кнопку Добавить.

Сперва нужно выбрать субъект, на который будут распространяться новые права.

Впишите название группы и нажмите кнопку Проверить имена.

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

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

Итак, мы познакомились с локальными группами в Windows. Во второй статье о группах в Windows мы поговорим про группы в Active Directory.

«кто кого»: локальный или доменный администратор

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

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

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

Исключение компьютера из домена.

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

После чего необходимо создать локального пользователя, имя которого и пароль совпадают с данными пользователя домена. В результате пользователь сохранит практически всю функциональность работы в сети, но исключит любое централизованное управление.

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

Отключение совместного использования административных ресурсов.

Локальный пользователь может отключить создание административных ресурсов, если добавит параметр

AutoShareWks : DWORD = 0

в ветвь реестра

HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters (Для восстановления необходимо удалить этот параметр.)

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

Исключение администратора домена из группы локальных администраторов.

Поскольку локальный администратор имеет полные права над своей системой, то он может ограничить администратора предприятия, исключив его из группы локальных администраторов. В системах с Windows NT 4.0 против такого решения практически не было «противоядия». C Windows 2000 и далее появилась возможность регулировать членство в группах с помощью групповых политик. Хотя практика контроля состава групп локальных администраторов вызывает крайнее недовольство рядовыми пользователями, но администратор предприятия может самостоятельно определить список членов этой группы.

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

Блокировка администратора домена на уровне файловой системы.

С помощью ограничений доступа к файлам локального компьютера можно запретить, например, конкретным администраторам домена локальный вход в систему. Для этого следует установить для учетной записи такого администратора запрет доступа к файлам nddagnt.exe, userinit.exe, win.com, wowexec.exe. Выполнять операцию следует внимательно, чтобы случайно не запретить доступ, например, самому себе.

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

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

Блокирование групповой политики.

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

Примечание В доменах Windows 2003 по умолчанию групповая политика не загружалась на медленных каналах связи. А поскольку для определения скорости канала использовалась оценка времени ответа на команду ping, то блокировка таких пакетов была самым простым методом отключения применения групповой политики. Во-первых, локальный администратор может переопределить параметры, установленные групповой политикой. Групповая политика для компьютера применяется при старте системы, а для пользователя — в момент его входа в сеть. Впоследствии система периодически проверяет изменения настроек групповой политики и применяет только обнаруженные изменения в групповой политике. Конечно, можно задать периодическое применение всех параметров групповой политики. В этом случае параметры, занесенные локальным администратором, будут вновь переписаны на централизованные. Но администраторы домена редко используют такие настройки, поскольку это существенно увеличивает нагрузку на контроллеры домена.

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

Во-вторых, можно заблокировать применение всех политик, сохранив членство компьютера в домене. Например, поскольку групповые политики копируются в виде файлов с контроллеров домена (из папок SYSVOL), то можно создать такую настройку ipsec, которая будет блокировать SMB-трафик с контроллеров домена («закрыть» порты 137, 139, 445).

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

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

Вопрос

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

Вариант разово добавить на каждом ПК в группу Администратор, не рассматривается ввиду того, что появляются/заменяются ПК и ОС на них с таким же успехом. Т.е. нужно создать Пользователя (Группу) 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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