Настройка прав пользователей windows server 2016
Обновлено: 25.06.2024
Групповые политики являются одним из самых эффективных способов управления компьютерной сетью, построенной на базе Windows-сетей. Групповые политики используют для упрощения администрирования, предоставляя администраторам централизованное управление привилегиями, правами и возможностями как пользователей, так и компьютеров сети.
При помощи политики возможно:
- назначать сценарии пользователя и сценарии компьютера, запускающиеся в конкретно указанное время;
- определять политики параметров пароля учетных записей, блокировку пользователей;
- распространять программное обеспечение на компьютеры сети при помощи публикации или назначения;
- выполнять набор настроек безопасности для удаленных машин;
- ввести контроль над доступом к windows-компонентам, системным ресурсам, сетевым ресурсам, утилитам панели управления, рабочему столу и экрану;
- проводить настройку по распределению прав на доступ к файлам и папкам;
- настраивать перенаправление определенных папок из профиля пользователя.
Групповые политики возможно применять сразу на нескольких доменах, на отдельных доменах, на подгруппах в домене, на отдельных системах.
Политики, применяемые к отдельным системам, называются локальными групповыми политиками. Такие политики хранятся только на локальном компьютере. Остальные групповые политики соединены в объекты и хранятся в хранилище данных Active Directory.
Управление групповых политик имеется только в профессиональных и серверных версиях Windows.
Для каждой новой версии Windows вносились новые изменения в групповую политику. В некоторых случаях старые политики не применяются на новые версии Windows.
Обычно большинство политик прямо совместимы. Это означает, что, как правило, политики, предоставленные в Windows Server 2003, могут использоваться на Windows 7 и более поздних, а также на Windows Server 2008 и более поздних. Однако, политики для Windows 8/10 и Windows Server 2012/2016 обычно не применимы к более ранним версиям Windows. Для того, чтобы узнать какие версии поддерживает политика, можно открыть окно ее свойств – там посмотреть на поле Требование к версии или поддерживается. В нем указаны версии ОС, на которых эта политика будет работать:
Редактирование групповых политик
Консоль редактирования групповой политики входит в состав сервера, ее требуется установить в диспетчере сервера как дополнительный компонент управления групповыми политиками:
После этого в составе программ меню Администрирование появляется задача Управление групповыми политиками.
В оснастке Управление групповой политикой назначаются политики к подразделениям, а благодаря иерархической структуре можно визуально понять к какой группе относятся какая-либо политика:
Групповая политика изменяется в редакторе управления групповыми политиками – для этого требуется выбрать команду Изменить в меню Действия. Так же новую групповую политику можно создать либо «с нуля», для этого выбираем Объекты групповой политики выбираем команду Создать в меню Действие. Записываем новое имя объекта групповой политики после этого нажимаем ОК. Можно скопировать в нее параметры уже существующей политики в зависимости от требуемой задачи.
Чтобы применить созданную политику, требуется установить для нее связь с соответствующим объектом службы каталогов в оснастке Управление групповой политикой:
Примененную политику можно настроить по фильтру безопасности. Таким способом параметры данного объекта групповой политики возможно разделить только для заданных групп, пользователей и компьютеров, входящих в домен:
Рекомендации по применению политик
Главное заключается в том, чтобы не изменять политику по умолчанию. Потому как если в политике возникнет какая-либо серьезная ошибка, то возврат к начальному состоянию приведет к удалению не только последних настроек, но и всех других параметров. Поэтому для административных действий по управлению системой создавайте новые политики, тогда для изменения настроек вам потребуется только отключать/включать привязку политик к организационной структуре.
Обработка одной политики с наибольшим числом назначенных параметров, не отличается по времени от обработки нескольких политик, в каждой из которых назначается только часть этих параметров. Поэтому удобнее создавать несколько политик, чем включать все изменения в одну.
Не стоит удалять ранее созданные групповые политики – желательно просто отключить привязку их от объекта службы каталогов. Они могут потребоваться в дальнейшем для анализа в случае каких-либо проблем.
В рамках нашей услуги ИТ-обслуживание мы не только настраиваем групповые политики, но и берем на себя обслуживание всей ИТ-структуры клиента, включая все настройки, обновления ПО и поддержку в режиме 24/7.
Файловый сервер установлен. Об установке и настройке файлового сервера смотрите статью «Файловый сервер на базе Windows Server 2016». В этой статье я расскажу о настройке прав доступа к сетевым папкам на файловом сервере.
На логическом диске D: файлового сервера создадим папку, например, share-local. Это будет корневая папка для всего файлового сервера.
Включаем Sharing для этой папки. Нажимаем Advansed Sharing > удаляем Everyone и добавляем Authenticated Users или Domain Users.
Advansed Sharing
Устанавливаем права для Authenticated Users.
Access Based Enumeration
Возвращаемся к нашей папке share-local. Заходим на вкладку Security, нажимаем Advansed. В появившемся окне Advansed Security нажимаем Disable inheriatance (Отключить наследование). Отключаем наследование с преобразованием унаследованных прав в явные.
Отключение наследования
Оставляем полный доступ для этой папки, ее подпапок и файлов администраторам и системе, права создателя-владельца урезаем, остальные права доступа удаляем.
права создателя-владельца изменяем шаг 1 права создателя-владельца изменяем шаг 2
Добавляем группу Domain Users c правом только чтения и только этой папки.
Права Domain Users
Создаем подпапки отделов. Вновь созданные папки будут видны только администраторам. Добавим группы, которые должны получить доступ к ним. И не забываем поставить флаг Write для групп.
Как видно, теперь пользователь сети нужного отдела видит папку своего отдела и может в ней создавать папки и файлы.
доступ к папке своего отдела
Все папки на файловом сервере По прежнему только папка отдела
Помним, что один из отделов уже имеет общий ресурс для отдела. И нужно этому отделу подключить еще одну сетевую папку. Для этих целей мы создали наш Namespace. O Namespace смотрите статью
«Файловый сервер на базе Windows Server 2016».
Подключаем сетевой ресурс через \\unitec.local\share-files
Видим 2 папки нашего отдела. Одна из них корневая со старого сетевого ресурса (dc share), а вторая подпапка отдела (new share) с нового файлового сервера. У пользователя все работает, есть возможность создавать файлы и папки.
Сетевые папки первого отдела
Ошибка при попытке входа
Хочу добавить, что у меня не стояла задача создания структуры папок в корневой папке отдела и назначения прав на папки структуры.
Цель данной статьи — тонкая настройка терминального сервера. Все скриншоты будут соответствовать версии Windows Server 2016. В результате такой настройки вы сможете повысить безопасность сервера и ограничить права терминальных пользователей.
Удаляем лишние команды из Проводника
Откройте редактор групповой политики (команда gpedit.msc) и перейдите в раздел Конфигурация пользователя, Административные шаблоны, Компоненты Windows, Проводник (рис. 1.).
Рис. 1. Параметры Проводника
Как видите, есть много полезных и не очень групповых политик в Windows Server 2016. Рассмотрим несколько полезных. Так, Скрыть выбранные диски из окна Мой компьютер (рис. 2) позволяет удалить значки выбранных дисков из окна Этот компьютер (в последних версиях Windows это окно называется именно так).
Рис. 2. Ограничиваем доступ пользователей в Windows Server 2016 к определенным дискам
Впрочем, если пользователь окажется умным и введет путь диска (например, D:\) в окне Проводника, он сможет получить доступ к нему. Для таких умных пользователей предназначена групповая политика Запретить доступ к дискам через «Мой компьютер» (рис. 3).
Рис. 3. Запретить доступ к дискам
Неплохо было бы еще и запретить пользователю использовать окно Выполнить (открывается при нажатии Win + R). Для этого нужно включить групповую политику Отключить сочетания клавиш Windows + X. Правда, такая настройка «убьет» все сочетания, в том числе и Win + R, но отдельной групповой политики, которая бы отключала отдельные команды, в современных версиях Windows Server нет (хотя раньше была опция, скрывающая команду Выполнить)
Запрещаем доступ к командной строке и PowerShell
Окно Выполнить используют самые начинающие пользователи. Продвинутые пользователи используют или командную строку, или PowerShell. Запретить пользователям использовать командную строку можно, проведя настройку групповой политики Конфигурация пользователя, Административные шаблоны, Система, Запретить использование командной строки (рис. 4). Также включите опцию Запретить также обработку сценариев в командной строке, чтобы нельзя было запускать сценарии командной строки.
Рис. 4. Запрещаем использование командной строки в Windows Server
Отдельной групповой политики, запрещающей запуск PowerShell, нет, но есть групповая политика, запрещающая запуск определенных приложений. Она называется Не запускать указанные приложения Windows и находится все в том же разделе Система. Включите ее и запретите запуск powershell.exe and powershell_ise.exe (рис. 5).
Рис. 5. Запрет запуска PowerShell
Также, пока вы еще не «ушли» из раздела Система, неплохо было бы запретить запуск редактора реестра. Для этого включите Запретить доступ к средствам редактирования реестра.
Максимальное время работы пользователя
Групповая политика Конфигурация пользователя, Административные шаблоны, Компоненты Windows, Службы удаленных рабочих столов, Узел сеансов удаленных рабочих столов, Ограничение сеансов по времени, Задать ограничение по времени для активных сеансов служб удаленных рабочих столов позволяет задать максимальную продолжительность сеанса. Ее можно установить, например, в 8 часов.
Рис. 6. Ограничиваем время сеанса
К сожалению, эта настройка не помешает пользователю снова залогиниться на сервере. Ограничить время входа на сервер можно только с помощью оснастки Пользователи и компьютеры Active Directory, но далеко не все терминальные серверы являются контроллерами домена, к сожалению. Разворачивать контроллер домена только ради этой функции не хочется (например, если терминальный сервер у вас используется только ради совместного доступа к 1С, нет смысла проводить настройку контроллера домена).
Рис. 7. Установка времени входа учетной записи в Windows Server
Отключение элементов панели управления
С помощью групповых политик можно отключить некоторые элементы панели управления. В разделе Конфигурация пользователя, Административные шаблоны, Панель управления находятся две замечательных групповые политики — Скрыть указанные элементы панели управления и Запретить доступ к панели управления и параметрам компьютера. Первая позволяет запретить выбранные элементы панели управления, а вторая вообще запрещает доступ к панели управления и к параметрам компьютера.
Надеюсь, прочитав эту статью, администратору будет немного спокойнее — ведь теперь пользователи смогут сделать гораздо меньше, чего стоит только отключение командной строки и PowerShell.
Продолжим про безопасность операционных систем – на этот раз «жертвой» станет 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 ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».
Читайте также: