Builtin администраторы что это

Об управлении исполняемыми файлами

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

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

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

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

Доверенные владельцы по умолчанию:

• SYSTEM
• BUILTIN\Administrators
• %ComputerName%\Administrator
• NT Service\TrustedInstaller

Это означает, что по умолчанию Управление приложениями доверяет файлам, принадлежащим группе BUILTIN\Administrators и локальному администратору. Управление приложениями не выполняет групповой поиск доверенных владельцев — пользователи, члены BUILTIN\Administrators, НЕ являются доверенными владельцами по умолчанию. Другие пользователи, даже если они являются членами группы «Администраторы», должны быть явно добавлены в список «Доверенные владельцы». Вы можете расширить представленный ранее список для добавления других пользователей или групп.

Технологии

Управление приложениями использует драйверы безопасных фильтров и политики безопасности Microsoft NTFS для перехвата всех запросов на выполнение. Запросы на выполнение осуществляются через привязку Управление приложениями , и любые нежелательные приложения будут блокированы. Права приложений основаны на владении приложениями с использованием информации доверенного владения, которое обычно есть у администраторов. С использованием этого метода текущая политика доступа к приложениям будет применяться без использования сценариев или функции управления списками. Это называется доверенным владением. В дополнение к исполняемым файлам Управление приложениями также управляет доступом к содержимому приложений, такому как сценарии VBScripts, командные файлы, пакеты MSI и файлы конфигурации реестра.

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

Важной функцией этого метода обеспечения безопасности является возможность не рассматривать сами данные файла. Используя этот способ, Управление приложениями может управлять как известными, так и неизвестными приложениями. Обычные системы безопасности, такие как антивирусные приложения, сравнивают шаблоны файлов со списком известных уязвимостей для определения потенциальных угроз. Таким образом, предлагаемая защита прямо пропорциональна точности используемого для сравнения списка. Многие вредоносные приложения либо никогда не идентифицируются, либо, в лучшем случае, идентифицируются только через некоторое время, которое системы остаются уязвимыми. Управление приложениями по умолчанию разрешает данные ВСЕХ локальных установленных исполняемых файлов, если их владелец указан в списке доверенных владельцев в конфигурации. Затем администратор должен предоставить список приложений, выполнение которых он хочет запретить в локальной дисковой подсистеме и которые обычно являются административными приложениями, такими как mmc.exe, eventvwr.exe, setup.exe и т.д.

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

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

Правило доверенного владения

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

Зачастую можно увидеть группу BUILTIN\Administrators на консоли Управление приложениями в качестве владельца файлов. Также можно обнаружить, что владельцем файла является отдельная учетная запись администратора. Это приводит к следующим ситуациям:

• Владелец файла — это группа BUILTIN\Administrators, и данная группа — это доверенный владелец. Атрибут «Доверенное владение» разрешает выполнение файлов.
• Владелец файла — это отдельный администратор, и отдельный администратор — это доверенный владелец. Атрибут «Доверенное владение» разрешает выполнение файлов.
• Владелец файла — это отдельный администратор, а отдельный администратор не является доверенным владельцем, но группа BUILTIN\Administrators сама является доверенным владельцем. Атрибут «Доверенное владение» не разрешает выполнение файлов.

В последнем случае, даже если администратор, которому принадлежит файл, находится в группе BUILTIN\Administrators, владелец файла не считается доверенным. Группа не расширяется, чтобы было ясно, можно ли доверять отдельному владельцу. В этом случае для разрешения выполнения файла необходимо изменить владение файла на доверенного владельца, например, на локального или доменного администратора

Уровни безопасности

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

Самоавторизация

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

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

Разрешенные и запрещенные элементы

Разрешенные элементы

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

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

Управление приложениями полностью поддерживает эту модель управления и добавляет значительные возможности для обеспечения ее безопасности. Одним из таких дополнений является возможность включения цифровых подписей SHA-1, SHA-256 и Adler-32, чтобы совпадали не только имя приложения и путь к файлу, но также и цифровая подпись этого исполняемого файла, и его цифровая подпись в базе данных. Кроме того, Управление приложениями также добавляет полный путь к исполняемому файлу в список для обеспечения соответствия всех трех элементов до запуска приложения:

Имя файла — например, winword.exe.

Путь файла, например, C:\Program Files\Microsoft Office\Office\digital signature

Для применения технологий более высокого уровня Управление приложениями не только использует данные об исполняемых файлах, но также требует от администраторов указывать конкретные библиотеки DLL, а также все другие данные исполняемых файлов, такие как элементы управления ActiveX, сценарии Visual Basic и командные сценарии.

Белые списки Управление приложениями представляют собой разрешенные элементы. Элементы в списке разрешенных элементов:

• Файлы
• Папки
• Диски
• Хеши файлов
• Коллекции правил

Запрещенные элементы

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

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

Одной из основных причин запрета приложений с помощью черных списков является разрешение использования доверенного владения для управления лицензиями без допуска выполнения даже известных (поэтому доверенных и имеющих владение) приложений, пока администратор явно не разрешит доступ к этим приложениям посредством указания конкретного пользователя/группы или клиентского правила. Эта защита не нуждается в конфигурации за исключением разрешения запуска внешних приложений. Кроме того, использование черного списка полезно для запрета доступа к файлам, принадлежащим доверенным владельцам, которые могут вызвать скрытый риск безопасности. Например, regedit.exe, ftp.exe и т.д.

Родственные темы

Была ли эта статья полезна?

Как удалить группу BUILTIN\Администраторы из раздела «Безопасность» в консоли KSC11?

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

Похожий контент

Друзья!
«Лаборатория Касперского» много внимания уделяет обеспечению безопасности автомобилей, доля которых на рынке только увеличивается. Например, в России «Лаборатория Касперского» участвует в создании первой в стране платформы кибербезопасности транспортных средств.
У нас в Клубе много автолюбителей. Поэтому в честь приближающегося праздника Дня автомобилиста в России, предлагаем вам поучаствовать в викторине об автомобилях и их безопасности.

НАГРАЖДЕНИЕ
Без ошибок — 1200 баллов Одна ошибка — 1000 баллов Две ошибки — 600 баллов
ПРАВИЛА ПРОВЕДЕНИЯ

Викторина проводится до 20:00 02 ноября 2023 года (время московское).
Правильные ответы будут опубликованы не позднее 10 дней с момента окончания викторины. Публичное обсуждение вопросов и ответов викторины запрещено. Итоги будут подведены в течение десяти дней с момента публикации правильных ответов. Баллы будут начислены в течение двадцати дней с момента опубликования итогов викторины.

Все вопросы, связанные с корректностью проведения викторины, необходимо отправлять пользователю @kmscom (пользователей @Friend и @Ellyвключать в копию адресатов) через систему личных сообщений с подробным описанием ситуации. Ответ будет дан коллегиальным решением организаторов викторины и дальнейшего обсуждения не предполагает.
Вопросы по начислению баллов направлять пользователю@Ellyчерез систему личных сообщений.

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

Администрация, официально уведомив, может в любой момент внести изменения в правила викторины, перезапустить или вовсе прекратить её проведение, а также отказать участнику в получении приза, применить иные меры (вплоть до блокировки аккаунта) в случае выявления фактов его недобросовестного участия в ней и/или нарушения правил викторины, передачи ответов на викторину иным участникам. При ответе на вопросы викторины запрещается использовать анонимайзеры и другие технические средства для намеренного сокрытия реального IP-адреса.

Вопросы по начислению баллов, принимаются в течение 30 дней с момента подведения итогов викторины. Викторина является собственностью клуба «Лаборатории Касперского», её использование на сторонних ресурсах без разрешения администрации клуба запрещено.

Участие в викторине означает безоговорочное согласие с настоящими правилами. Для перехода к вопросам викторины нажмите ЗДЕСЬ.

От Иван Клешня

Доброго времени суток всем. Уважаемые коллеги не так давно получил повышение до системного администратора и получил в наследство парк компьютеров. Имеется несколько подсетей — около 5. В них пользователей в районе сотни +-5 человек. У конечных пользователей стоят операционные системы: WIN7, WIN8 и WIN10. Серверные ос от 20012 до 2016 (один на 2019).
Столкнулся с тем что на компьютерах установлены очень старые версии клиентов (KES_11.0.0.6499 и местами KES_11.0.1.90), версия агента обновления NetAgent_10.5.1781. Соответственно они не обновляются.
Управляется все как я понял через Kaspersky Security Center 10 Service Pack 3 (версия 10.5.1781.0) Жизненный цикл которого тоже окончился.
Соответственно захотелось обновить все до актуальной версии. Так стал сис админом не так давно, и не имел раньше большого опыта с продуктами лаборатории касперского чтоб не наломать дров решил спросить у знающих людей как поступить лучше?
Я так понял что с десятой версии нельзя обновится сразу до последней 14. Соответственно я подумал что у меня только два пути если есть еще варианты буду признателен за советы.
1) Можно только обновить Kaspersky Security Center 10 до 11 версии и с нее уже на 14. При этом обновив Endpoint для клиентов до актуальных версий.
2) Удалить полностью антивирусники и KSC 10 с рабочих станций и сервера и произвести чистовую установку всего с 0.
Хотелось бы узнать мнение профессионалов и тех кто сталкивался с подобными случаями как поступить лучше?
Также при установке Endpoint для клиентов или обновлении если пойду по 1 пути, могли бы порекомендовать надежные версии которые два года не нужно будет обновлять которые имеют необходимые сертификации и имеют наименьшее количество глюков и проблем и плюс поддерживают операционные системы о которых писал выше или можно смело обновлять все до самых последних версий? Хотелось бы прочитать разные варианты развития событий но в итоге получить способ который принесет мне наименьшее количество проблем которые придется разгребать бегая в мыле доказывая что я не дурак)))

У меня установлен касперский плюс, а также есть на винде 11 встроенный защитник виндовс. Последнюю неделю защитник виндовс ругается, пишет:
«Защита локальной системы безопасности отключена».
Ползунок «вкл.» не помогает. Все равно пишет, что отключена. Перезагрузка не помогает. Подскажите пожалуйста, что делать?

От admin_admin

Друзья всем доброе утро. Возник вопрос по поводу KSC11, Endpoint и т.д.

Имеется несколько подсетей — около 6 штук. В них пользователей. ну около 100 плюс/минус.
У конечных пользователей стоят и WIN7, WIN8 и WIN10. И серваки от 2008 до 2016 (и один или два на 2019).

На некоторых компах Endpoint не обновляется вообще, как был 11.1.1.126 так и висит и базы за 2019.
А на моём рабочей стоит 11.11.0.452 и всё отлично работает естессно.

Сейчас есть 3 лицензии: 1:) Kaspersky Endpoint Security для бизнеса – Стандартный Russian Edition. 50-99 Node 1 year Renewal License
2) Kaspersky Endpoint Security для бизнеса – Стандартный Russian Edition. 50-99 Node 1 year Renewal License: Kaspersky Security for WS and FS
3) Kaspersky Endpoint Security для бизнеса – Стандартный Russian Edition. 50-99 Node 1 year Renewal License: Security Center

Все они истекут 25 мая 2023 года в 5:00 утра.

—Как перейти (и нужно ли?) с KSC11 до KSC14 и чтоб всё это работало и на старых компах и на новых? Или может нужна другая версия KSC? Желательно чтоб одобрено всё было ФСТЭК и т. д.
—Если перейдём на новую версию KSC будут ли поддерживаться клиенты WIN7 и серваки 2008?
—Каким образом нужно будет произвести обновление сервера и клиентов конечных, чтоб желательно всё это происходило «бесшовно»?
—Подскажите пожалуйста где и как купить ключи чтобы продлить лицензию?

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

П.П.С. Ещё вопрос по Exchange Server 2008, скажите пожалуйста каким образом на него можно продлить лицензию? (с этим можно после разобраться, сейчас вопрос стоит по KSC и endpoint’ам)

Ну собственно на картинке
нажатие на кнопку Открыть службу . , ни к чему не приводит. Окно службы может открыться начальное, но потом закроется само.
Не знаю как давно такое стало. Антивирус Kaspersky установлен. в настоящее время 21.9, но возможно и на 21.8 не открывалось.
Не знаю также, возможно это ожидаемое поведение. Вирусное заражение я исключаю, я давно уже ничего случайного не качаю и не запускаю, я давно определился с используемым набором ПО, многое покупное.
Официальной информации, как должно это работать — не нашел.

Встроенные группы домена

Группы — это объекты, являющиеся участниками системы безопасности (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. Со всеми вытекающими последствиями.

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

Группы по умолчанию в Active Directory

После установки роли AD на Windows Server появляются несколько стандартных групп безопасности, которые в основном связаны с управлением Active Directory. Какие же группы создаются?

1) Администраторы предприятия (Enterprise Admins) – находится в контейнере Users корневого домена леса. Эта группа – член группы Администраторы (Administrators) в каждом домене леса; она представляет полный доступ к конфигурации всех контроллеров домена. Данная группа также является владельцем раздела Конфигурация (Configuration) каталога и имеет полный доступ к содержимому именования домена во всех доменах леса.

2) Администраторы схемы (Schema Admins) – находится в контейнере Users корневого домена леса. Эта группа имеет полный доступ к схеме Active Directory.

3) Администраторы (Administrators) – находится в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы (Administrators) в корневом домене леса может изменять членство в группах Администраторы предприятия (Enterprise Admins), Администраторы Схемы (Schema Admins) и Администраторы домена (Domain Admins). Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.

4) Администраторы домена (Domain Admins) – находится в контейнере Users каждого домена. Эта группа входит в группу Администраторы своего домена. Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.

5) Операторы сервера (Server Operators) – находится в контейнере Builtin каждого домена. Эта группа может решать задачи технической поддержки на контроллерах домена. Операторы сервера могут локально входить в систему, запускать и останавливать службы, выполнять резервное копирование и восстановление, форматировать диски, создавать и удалять общие ресурсы, а также завершать работу контроллеров доменов. По умолчанию данная группа не содержит членов.

6) Операторы учета (Account Operators) – находится в контейнере Builtin каждого домена. Эта группа может создавать, модифицировать и удалять учетные записи пользователей, групп и компьютеров в любом подразделении домена (кроме подразделения Domain Controllers), а также в контейнерах Users и Computers. Операторы учета не могут модифицировать учетные записи, включенные в группы Администраторы и Администраторы домена, а также не могут модифицировать эти группы. Операторы учета также могут локально входить на контроллеры домена. По умолчанию эта группа не содержит членов.

7) Операторы архива (Backup Operators) – находится в контейнере Builtin каждого домена. Эта группа может выполнять операции резервного копирования и восстановления на контроллерах домена, а также локально входить на контроллеры домена и завершать их работу. По умолчанию эта группа не содержит членов.

8 ) Операторы печати (Print Operators) – находится в контейнере Builtin каждого домена. Эта группа может обеспечивать поддержку очередей заданий печати на контроллерах домена. Она также может локально входить на контроллеры домена и завершать их работу.

Добавить комментарий Отменить ответ

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