Оператор архива windows кто это
Профиль | Отправить PM | Цитировать | Операторы архива (Backup Operators) ≈ члены этой группы могут архивировать и восстанавливать файлы в системе независимо от того, какими правами эти файлы защищены. Кроме того, операторы архива могут входить в систему и завершать ее работу, но они не имеют права изменять настройки безопасности. |
Попробовал запустить от имени этого пользователя задание в планировщике (бэкап папки \\server\docs, в которой лежат перенаправленные папки «Мои документы» пользователей домена) — ругается, что нет доступа к папкам (в разрешениях стоит полный доступ для System, Администратора и Хозяина папки).
Захожу на сервер локально с учеткой Arch — пробую через проводник зайти в папки с документами пользователей — опять нет доступа!
Пробовал и на контроллере домена и на рядовом сервере — везде Arch имеет права только «Пользователя домена».
Проверил на контроллере домена в «Политика безопасности домена» и в «Политика безопасности контроллера домена», а так же на рядовом сервере в «Локальная политика безопасности» значение: «Архивирование файлов и каталогов» стоит по умолчанию: «Администраторы» и «Операторы архива».
Пробовал добавлять туда вручную пользователя Arch- никакого эффекта.
При этом, если для папок вручную прописать разрешение на чтение для группы «Операторы архива» — доступ появляется.
Если добавить пользователя Arch в группу «Администраторы» — доступ есть везде.
Почему пользователь, входящий в группу «Операторы архива» не может получить доступ к любым папкам?
Оператор архива windows кто это
| Операторы архива (Backup Operators) ≈ члены этой группы могут архивировать и восстанавливать файлы в системе независимо от того, какими правами эти файлы защищены. Кроме того, операторы архива могут входить в систему и завершать ее работу, но они не имеют права изменять настройки безопасности. |
Попробовал запустить от имени этого пользователя задание в планировщике (бэкап папки \\server\docs, в которой лежат перенаправленные папки «Мои документы» пользователей домена) — ругается, что нет доступа к папкам (в разрешениях стоит полный доступ для System, Администратора и Хозяина папки).
Захожу на сервер локально с учеткой Arch — пробую через проводник зайти в папки с документами пользователей — опять нет доступа!
Пробовал и на контроллере домена и на рядовом сервере — везде Arch имеет права только «Пользователя домена».
Проверил на контроллере домена в «Политика безопасности домена» и в «Политика безопасности контроллера домена», а так же на рядовом сервере в «Локальная политика безопасности» значение: «Архивирование файлов и каталогов» стоит по умолчанию: «Администраторы» и «Операторы архива».
Пробовал добавлять туда вручную пользователя Arch- никакого эффекта.
При этом, если для папок вручную прописать разрешение на чтение для группы «Операторы архива» — доступ появляется.
Если добавить пользователя Arch в группу «Администраторы» — доступ есть везде.
Почему пользователь, входящий в группу «Операторы архива» не может получить доступ к любым папкам?
Fedoseyev.ru
Группы безопасности Windows
Все нижеописанное относится к Windows 2003, являющейся членом домена Active Directory. Итак, по умолчанию в ней существуют следующие группы безопасности:
1) Administrators (Администраторы) — члены группы обладают полным доступом ко всем ресурсам системы. По умолчанию содержит встроенную учетную запись Administrator.
2) Backup Operators (Операторы архива) — члены этой группы имеют право архивировать и восстанавливать файлы в системе независимо от того, какими правами эти файлы защищены. Backup Operators могут входить в систему и завершать ее работу, но они не имеют права изменять настройки безопасности. По умолчанию пуста.
3) Guests (Гости) — эта группа позволяет выполнить регистрацию пользователя с помощью учетной записи Guest и получить ограниченные права на доступ к ресурсам системы. Члены этой группы могут завершать работу системы. По умолчанию содержит пользователя Guest.
4) Power Users (Опытные пользователи) — члены этой группы могут создавать учетные записи пользователей, но они имеют право модифицировать настройки безопасности только для созданных ими учетных записей. Кроме того, они могут создавать локальные группы и модифицировать состав членов созданных ими групп. То же самое они могут делать с группами Users, Guests и Power Users. По умолчанию пуста.
5) Replicator (Репликатор) — членом группы Replicator должна быть только учетная запись, с помощью которой можно зарегистрироваться в службе репликации контроллера домена. Ее членами не следует делать рабочие учетные записи. По умолчанию пуста.
6) Users (Пользователи) — члены этой группы могут выполнять большинство пользовательских функций. Могут создавать локальные группы и регулировать состав их членов. Они не могут получить доступ к общему каталогу или создать локальный принтер. По умолчанию содержит служебные учетные записи NT AUTHORITYAuthenticated Users (S-1-5-11) и NT AUTHORITYINTERACTIVE (S-1-5-4).
7) Network Configuration Operators (Операторы настройки сети) — группа, члены которой имеют некоторые права по настройке сетевых служб и параметров. По умолчанию пуста.
8) Remote Desktop Users (Удаленные пользователи рабочего стола) — эта группа содержит имена пользователей, которым разрешен удаленный доступ к рабочему столу.
9) HelpSenicesGroup (Группа служб поддержки) — группа для поддержки справочной службы Help and Support Service. По умолчанию содержит учетную запись SUPPORT_388945aO.
10) Performance Log Users (Пользователи журналов производительности) — члены этой группы могут просматривать журналы производительности. По умолчанию содержит служебную учетную запись NT AUTHORITYNETWORK SERVICE (S-l-5-20).
11) Performance Monitor Users (Пользователи системного монитора) — группа, члены которой могут выполнять мониторинг производительности системы. По умолчанию пуста.
12) Print Operators (Операторы принтеров) — члены этой группы могут администрировать принтеры в домене. По умолчанию пуста.
13) TelnetClients (Клиенты telnet) — группа, члены которой имеют доступ к службе Telnet Server на данном компьютере. По умолчанию пуста.
[конспект админа] Меньше администраторов всем
Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.
Сотрудникам, ответственным за определенные серверы и рабочие станции совсем не обязательно выдавать права «администратор домена». Хоть не по злому умыслу, по ошибке, но это может подпортить всем жизнь, а то и стоить чьих-то выходных. Под катом детально разберем принцип предоставления минимальных прав как одну из технологий предоставления минимальных прав.
Ограниченные группы
В качестве примера из практики могу привести грустную историю со счастливым концом. В организации исторически сложилось, что сервер печати находился на контроллере домена. В один прекрасный момент сотруднику отдела IT понадобилось перепрошить принтер, что он и проделал, запустив китайскую утилиту на сервере. Принтер заработал, но вот утилита в процессе перепрошивки перевела время на несколько лет назад. Active directory не очень любит путешественников во времени, и контроллер домена благополучно отправился в «захоронение» (tombstone).
Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.
Для профилактики подобных ситуаций неплохо будет выдавать желающим ровно столько прав, сколько нужно: если нужно администрировать только рабочие станции, достаточно выдать права только на компьютеры пользователей.
Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.
Первый способ: через Группы с ограниченным доступом (Restricted groups), расположенные в групповых политиках по адресу Конфигурация компьютера – Политики – Параметры безопасности.
Расположение политик Restricted groups.
Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:
Добавляем группу «Администраторы», в которую добавляем группу helpdesk.
И получаем локальную группу «Администраторы» без Domain admins.
Конечно, эту возможность можно использовать и во благо – зачистить локальные группы от лишних участников. Если же хочется избежать такой зачистки, то можно создать в «Группах ограниченного доступа» доменную группу и ее же назначить входящей в группу «Администраторы»:
При такой настройке локальная группа «Администраторы» не будет зачищена.
Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.
Настройка группы безопасности через GPP.
Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.
Таким же способом можно дать права и на определенные серверы нужным сотрудникам. Например, дать права группе разработчиков на тестовый стенд.
Использование встроенных групп безопасности
Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.
Но из соображений безопасности лучше так не делать. В Windows существует набор встроенных учетных записей с набором типовых прав. Группы немного различаются для компьютера и для домена, а также ряд сервисов привносит свои группы.
| Группа | Описание |
| Администраторы | Полные права на систему. |
| Пользователи | Возможность пользоваться без изменения системных параметров и без записи в системные разделы. Фактически пользователь – полноценный хозяин только в папке своего профиля. |
| Операторы архива | Группа, предназначенная для выполнения резервного копирования и восстановления. Участники группы могут завершать работу системы на серверах и переопределять права доступа в целях резервного копирования. |
| Опытные пользователи | Участники этой группы могут администрировать локальные учетные записи и группы (кроме администраторов), создавать сетевые ресурсы и управлять доступом на них, менять NTFS ACL (кроме смены владельца папки). |
| Пользователи удаленного рабочего стола | Членство дает возможность подключаться к компьютеру по RDP |
| Операторы печати | Операторы могут устанавливать и удалять принтеры, изменять их драйвера и настройки, останавливать и чистить очередь печати. |
| Операторы настройки сети | Могут менять настройки сетевых интерфейсов. Это полезная группа на случай если нужно переназначать получение адреса сетевой картой с автоматического на статическое. Мобильные пользователи скажут спасибо, если добавить их в эту группу. |
| Операторы учета | Пользователи в этой группе могут создавать/удалять/редактировать/перемещать учетные записи в Active Directory. Удобно дать эти права для сервиса, автоматически заводящего учетки сотрудников после приема на работу. |
Познакомиться со всеми группами и более полным описанием можно в официальной документации.
Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети. Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности – secpol.msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.
Настройка прав доступа через групповые политики.
Использовать эту настройку я рекомендую в крайних случаях, и ее обязательно надо документировать. Помните о том, что когда-нибудь вас кто-то сменит и будет разбираться, почему работает так, а не иначе.
Вообще лучше всегда все документировать. Представьте ситуацию, что вы уволились из организации и вместо вас пришел человек с улицы. Поставьте себя на место этого человека. Если начал дергаться глаз или зашевелились волосы – посвятите время написанию документации. Пожалуйста!
Существует еще один хороший метод ограничения доступа к объектам – делегирование. Про эту технологию на Хабре уже писали, поэтому я лишь добавлю, что с помощью делегирования удобно выдаются права для ввода нового компьютера в домен.
Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 10\2016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.
Достаточно администрирования
Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации. Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.
Подробнее про JEA можно почитать в официальной документации, поэтому разберем конкретный пример предоставления возможности перезапуска виртуальной машины.
Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.
Проверка версии и разрешение удаленных подключений при помощи PS.
Создадим группу безопасности и специального пользователя:
Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:
А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:
Теперь необходимо подготовить файл сессии PowerShell:
Зарегистрируем файл сессии:
Теперь все готово для проверки. Попробуем подключиться к серверу с учетными данными созданного пользователя командлетом:
Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.
Доступ к серверу ограничен управлением одной виртуальной машиной.
Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.
Интерфейс JEA Toolkit Helper.
При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.
Журнал выполнения PowerShell.
Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.
Файловый журнал JEA.
С помощью делегирования, назначения прав и JEA можно добиться отказа от использования учетных записей с администраторскими правами в повседневной работе. В конце-концов, к UAC в Windows ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».
