Настройка прав доступа к папкам и файлам в домене

Обновлено: 06.07.2024

В средах рабочей группы или в доменах, не являющихся доверенными, доступ на основе групп в Windows Admin Center не поддерживается.

Определения ролей доступа к шлюзу

Существует две роли для доступа к службе шлюза Windows Admin Center.

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

Администраторы шлюза могут настраивать доступ, а также способ выполнения проверки подлинности для пользователей на шлюзе. Просматривать и настраивать параметры доступа в Windows Admin Center могут только администраторы шлюза. Локальные администраторы на компьютере шлюза всегда являются администраторами службы шлюза Windows Admin Center.

Доступ к шлюзу не подразумевает доступ к управляемым серверам, отображаемым шлюзом. Для управления целевым сервером подключающийся пользователь должен использовать учетные данные (через переданные учетные данные Windows или учетные данные, предоставленные в сеансе Windows Admin Center с помощью действия Управлять как) с административным доступом к этому целевому серверу.

Active Directory или группы локальных компьютеров

По умолчанию для управления доступом к шлюзу используются Active Directory или группы локальных компьютеров. При наличии домена Active Directory доступом пользователей и администраторов шлюза можно управлять из интерфейса Windows Admin Center.

На вкладке Пользователи можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве пользователя шлюза. По умолчанию, и если не указать группу безопасности, доступ будет иметь любой пользователь, обращающийся к URL-адресу шлюза. После добавления одной или нескольких групп безопасности в список пользователей доступ будет ограничен членами этих групп.

Если в вашей среде не используется домен Active Directory, доступ контролируется локальными группами Users и Administrators на компьютере шлюза Windows Admin Center.

Проверка подлинности смарт-карты

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

На вкладке Администраторы можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве администратора шлюза. Локальная группа администраторов на компьютере всегда будет иметь полный доступ администратора и ее не можно удалить из списка. Добавляя группы безопасности, вы даете членам этих групп разрешения на изменение параметров шлюза Windows Admin Center. Список администраторов поддерживает проверку подлинности смарт-карты такую же, как и для списка пользователей: с условием AND и для группы безопасности и для группы смарт-карт.

Azure Active Directory

Если ваша организация использует Azure Active Directory (Azure AD), вы можете добавить дополнительный уровень безопасности в Windows Admin Center, требуя для доступа к шлюзу проверку подлинности Azure AD. Чтобы обеспечить доступ к Windows Admin Center, учетной записи Windows пользователя также следует предоставить доступ к серверу шлюза (даже при использовании проверки подлинности Azure AD). При использовании Azure AD управление правами доступа пользователя и администратора Windows Admin Center осуществляется на портале Azure, а не из пользовательского интерфейса Windows Admin Center.

Доступ к Windows Admin Center при включенной проверке подлинности Azure AD

В зависимости от используемого браузера некоторые пользователи, обращающиеся к Windows Admin Center с настроенной проверкой подлинности Azure AD, получат дополнительный запрос из браузера, в котором нужно будет указать данные учетной записи Windows для компьютера, на котором установлен Windows Admin Center. После ввода этих данных пользователи увидят дополнительный запрос на проверку подлинности Azure Active Directory, для которого требуются учетные данные учетной записи Azure, которой предоставлен доступ к приложению Azure AD в Azure.

Пользователи, учетная запись Windows которых имеет права администратора на компьютере шлюза, не будут получать запрос на проверку подлинности Azure AD.

Настройка проверки подлинности Azure Active Directory для Windows Admin Center (Предварительная версия)

В Windows Admin Center последовательно выберите Параметры > Доступ и используйте выключатель, чтобы включить параметр "Use Azure Active Directory to add a layer of security to the gateway" (Использовать Azure Active Directory для добавления уровня безопасности в шлюз). Если вы не зарегистрировали шлюз в Azure, вам будет предложено сделать это в данный момент.

По умолчанию все участники клиента Azure AD имеют доступ пользователей к службе шлюза Windows Admin Center. Доступ администратора к шлюзу Windows Admin Center имеют только локальные администраторы на компьютере шлюза. Обратите внимание, что права локальных администраторов на компьютере шлюза нельзя ограничить. Локальные администраторы могут выполнять любые действия независимо от того, используется ли Azure AD для проверки подлинности или нет.

Если вы хотите предоставить доступ к службе Windows Admin Center определенным пользователям Azure AD, группам пользователей шлюза или администраторам шлюза, необходимо выполнить следующие действия.

Перейдите в приложение Azure AD Windows Admin Center на портале Azure, используя гиперссылку, указанную в Параметрах доступа. Примечание. Эта гиперссылка доступна, только если включена проверка подлинности Azure Active Directory.
- Приложение также можно найти на портале Azure, перейдя в Azure Active Directory > Корпоративные приложения > Все приложения и выполнив поиск по фразе WindowsAdminCenter (приложение Azure AD будет называться WindowsAdminCenter-<gateway name>). Если поиск не дает результатов, убедитесь, что для Показать задано значение Все приложения, а для Состояние приложения, а — Любой и нажмите кнопку "Применить", а затем повторите поиск. Найдя приложение, перейдите в раздел Пользователи и группы
На вкладке "Свойства" задайте для параметра Требуется назначение пользователей значение "Да". После этого доступ к шлюзу Windows Admin Center смогут получить только участники, перечисленные на вкладке Пользователи и группы.
На вкладке "Пользователи и группы" выберите Добавить пользователя. Для каждого добавляемого пользователя или группы необходимо назначить роль пользователя или администратора шлюза.

После включения проверки подлинности Azure AD служба шлюза перезапустится и вам потребуется обновить браузер. Вы можете в любое время обновить доступ пользователя к приложению SME Azure AD на портале Azure.

При попытке доступа к URL-адресу шлюза Windows Admin Center пользователям будет предложено войти, используя удостоверение Azure Active Directory. Помните, что пользователи также должны быть членами локальных "Пользователей" на сервере шлюза для доступа к центру администрирования Windows Admin Center.

Пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD с вкладки Учетная запись в параметрах Windows Admin Center.

Настройка проверки подлинности Azure Active Directory для Windows Admin Center

Чтобы настроить проверку подлинности Azure AD, необходимо сначала зарегистрировать шлюз в Azure (это необходимо сделать только один раз для шлюза Windows Admin Center). На этом этапе создается приложение Azure AD, с помощью которого вы можете управлять доступом пользователей шлюза и администраторов шлюза.

Перейдите к приложению SME Azure AD на портале Azure.
- Если щелкнуть Изменить контроль доступа, а затем выбрать Azure Active Directory из раздела параметров доступа Windows Admin Center, можно использовать гиперссылку, предоставленную в пользовательском интерфейсе, для доступа к приложению Azure AD на портале Azure. Эта гиперссылка также доступна в параметрах доступа после нажатия кнопки "Сохранить" и выбора Azure AD в качестве поставщика удостоверений управления доступом.
- Приложение также можно найти на портале Azure, перейдя в Azure Active Directory > Корпоративные приложения > Все приложения и выполнив поиск по фразе SME (приложение Azure AD будет называться SME-<gateway>). Если поиск не дает результатов, убедитесь, что для Показать задано значение Все приложения, а для Состояние приложения, а — Любой и нажмите кнопку "Применить", а затем повторите поиск. Найдя приложение, перейдите в раздел Пользователи и группы
На вкладке "Свойства" задайте для параметра Требуется назначение пользователей значение "Да". После этого доступ к шлюзу Windows Admin Center смогут получить только участники, перечисленные на вкладке Пользователи и группы.
На вкладке "Пользователи и группы" выберите Добавить пользователя. Для каждого добавляемого пользователя или группы необходимо назначить роль пользователя или администратора шлюза.

Как только вы сохраните контроль доступа Azure AD в панели Изменить контроль доступа, служба шлюза перезапустится и вам потребуется обновить свой браузер. Вы можете в любое время обновить доступ пользователя к приложению Windows Admin Center Azure AD на портале Azure.

Используя вкладку Azure в общих параметрах Windows Admin Center, пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD.

Условный доступ и многофакторная проверка подлинности

Одним из преимуществ использования Azure AD в качестве дополнительного уровня безопасности для контроля доступа к шлюзу Windows Admin Center является то, что вы можете использовать эффективные функции безопасности Azure AD, такие как условный доступ и многофакторная проверка подлинности.

Настройте единый вход

Единый вход при развертывании в качестве службы в Windows Server

После установки Windows Admin Center в Windows 10 все готово к использованию единого входа. Однако если вы собираетесь использовать Windows Admin Center в Windows Server, то перед использованием единого входа необходимо настроить в среде некоторую форму делегирования Kerberos. Делегирование настраивает компьютер шлюза как доверенный для делегирования к целевому узлу.

Чтобы удалить эту связь, выполните следующий командлет:

Управление доступом на основе ролей

Управление доступом на основе ролей позволяет предоставлять пользователям ограниченный доступ к компьютеру, не делая их полными локальными администраторами. Role-based access control (Управление доступом на основе ролей)

Настройка RBAC состоит из 2 шагов: включения поддержки на целевых компьютерах и назначения пользователям соответствующих ролей.

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

Применение управления доступом на основе ролей к одному компьютеру

Модель развертывания на одном компьютере идеально подходит для простых сред, в которых управление нужно представить только нескольким компьютерам. Настройка компьютера с поддержкой управления доступом на основе ролей приведет к следующим изменениям:

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

Откройте Windows Admin Center и подключитесь к компьютеру, который нужно настроить для управления доступом на основе ролей, используя на целевом компьютере учетную запись с правами локального администратора.
В инструменте Обзор щелкните Настройки > Контроль доступа на основе ролей.
Щелкните Применить в нижней части страницы, чтобы включить на целевом компьютере поддержку управления доступом на основе ролей. Процесс приложения включает копирование скриптов PowerShell и вызов конфигурации (с помощью Desired State Configuration PowerShell) на целевом компьютере. Выполнение может занять до 10 минут, и приведет к перезапуску WinRM. Это приведет к временному отключению пользователей Windows Admin Center, PowerShell и WMI.
Обновите страницу, чтобы проверить состояние управления доступом на основе ролей. Когда оно будет готово к использованию, состояние изменится на Применено.

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

Вы также можете последовательно заполнять эти группы по всему домену, настраивая объект групповой политики с помощью параметра Restricted Groups Policy Setting (Настройка политики групп с ограниченным доступом).

Применение управления доступом на основе ролей к нескольким компьютерам

При развертывании на крупном предприятии вы можете использовать существующие средства автоматизации для распространения функции управления доступом на основе ролей на компьютеры, скачав пакет конфигурации со шлюза Windows Admin Center. Пакет конфигурации предназначен для использования с Desired State Configuration PowerShell, но его можно адаптировать для работы с предпочтительным решением для автоматизации.

Скачивание конфигурации управления доступом на основе ролей

Чтобы загрузить пакет конфигурации управления доступом на основе ролей, необходимо иметь доступ к Windows Admin Center и командной строке PowerShell.

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

Если вы используете шлюз Windows Admin Center на компьютере с Windows 10, выполните следующую команду:

При развертывании ZIP-архива вы увидите следующую структуру папок:

InstallJeaFeatures.ps1
JustEnoughAdministration (каталог)

Модули (каталог)

Microsoft.SME.* (каталоги)
WindowsAdminCenter.Jea (каталог)

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

Скопируйте JustEnoughAdministration, Microsoft.SME.* и модули WindowsAdminCenter.Jea в каталог модуля PowerShell на целевом компьютере. Как правило, они расположены в C:\Program Files\WindowsPowerShell\Modules .
Обновите файл InstallJeaFeature.ps1 в соответствии с требуемой конфигурацией для конечной точки RBAC.
Запустите InstallJeaFeature.ps1, чтобы скомпилировать ресурс DSC.
Разверните конфигурацию DSC на всех компьютерах, чтобы применить ее.

В следующем разделе объясняется, как это сделать с помощью удаленного взаимодействия PowerShell.

Развертывание на нескольких компьютерах

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

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

Удалите из файла 3 ресурсы группы:

"Группа MS-Readers-Group"
"Группа MS-Hyper-V-Administrators-Group"
"Группа MS-Administrators-Group"

"[Group]MS-Readers-Group"
"[Group]MS-Hyper-V-Administrators-Group"
"[Group]MS-Administrators-Group"

'$env:COMPUTERNAME\Windows Admin Center Administrators'
'$env:COMPUTERNAME\Windows Admin Center Hyper-V Administrators'
'$env:COMPUTERNAME\Windows Admin Center Readers'

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

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

Стандарт управления правами доступа к корпоративным файловым информационным ресурсам (далее – Стандарт) регламентирует процессы предоставления доступа к файловым информационным ресурсам, размещенным на компьютерах, работающих под управлением операционных систем семейства Microsoft Windows. Стандарт распространяется на случаи, когда в качестве файловой системы используется NTFS, а в качестве сетевого протокола для совместного доступа к файлам SMB/CIFS.

Информационный ресурс – поименованная совокупность данных, к которой применяются методы и средства обеспечения информационной безопасности (например, разграничение доступа).
Файловый информационный ресурс – совокупность файлов и папок, хранящихся в каталоге файловой системы (который называется корневым каталогом файлового информационного ресурса), доступ к которой разграничивается.
Составной файловый информационный ресурс – это файловый информационный ресурс, содержащий в себе один или несколько вложенных файловых информационных ресурсов, отличающихся от данного ресурса правами доступа.
Вложенный файловый информационный ресурс – это файловый информационный ресурс, входящий в составной информационный ресурс.
Точка входа в файловый информационный ресурс – каталог файловой системы, к которому предоставляется сетевой доступ (shared folder) и который используется для обеспечения доступа к файловому информационному ресурсу. Данный каталог обычно совпадает с корневым каталогом файлового информационного ресурса, но может быть и вышестоящим.
Промежуточный каталог – каталог файловой системы, находящийся на пути от точки входа в файловый информационной ресурс к корневому каталогу файлового информационного ресурса. Если точка входа в файловый информационный ресурс является вышестоящим каталогом по отношению к корневому каталогу файлового информационного ресурса, то она также будет являться промежуточным каталогом.
Группа доступа пользователей – локальная или доменная группа безопасности, содержащая в конечном счете учетные записи пользователей, наделенные одним из вариантов полномочий доступа к файловому информационному ресурсу.

Доступ разграничивается только на уровне каталогов. Ограничение доступа к отдельным файлам не проводится.
Назначение прав доступа выполняется на базе групп безопасности. Назначение прав доступа на отдельные учетные записи пользователей не проводится.
Явно запрещающие полномочия доступа (deny permissions) не применяются.
Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Чтение/Запись» / Everyone – Change).
При настройке сетевого доступа к файловому информационному ресурсу в настройках SMB/CIFS устанавливается опция «Перечисление на основе доступа (Access based enumeration)».
Создание файловых информационных ресурсов на рабочих станциях пользователей недопустимо.
Не рекомендуется размещать файловые информационные ресурсы на системных разделах серверов.
Не рекомендуется создавать несколько точек входа в файловый информационный ресурс.
Следует по возможности избегать создание вложенных файловых информационных ресурсов, а в случаях, когда имена файлов или каталогов содержат конфиденциальную информацию, это вовсе недопустимо

Доступ пользователей к файловому информационному ресурсу предоставляется путем наделения их одним из вариантов полномочий:

Доступ «Только на чтение (Read Only)».
Доступ «Чтение и запись (Read & Write)».

Имена групп доступа пользователей формируются по шаблону:

FILE-Имя файлового информационного ресурса–аббревиатура полномочий

Имя файлового информационного ресурса
должно совпадать с UNC именем ресурса или состоять из имени сервера и локального пути (если сетевой доступ к ресурсу не предоставляется). При необходимости в данном поле допускаются сокращения. Символы «\\» опускаются, а «\» и «:» заменяются на «-».

Аббревиатуры полномочий:

RO — для варианта доступа «Только на чтение (Read Only)»
RW — для варианта доступа «Чтение и запись (Read & Write)».

Пример 2
Имя группы доступа пользователей, имеющих полномочия «Чтение и запись» для файлового информационного ресурса, размещенного на сервере TERMSRV по пути D:\UsersData, будет:
FILE-TERMSRV-D-UsersData-RW

Таблица 1 – Шаблон NTFS-прав доступа для корневого каталога файлового информационного ресурса.

Субъекты	Права	Режим наследования
Наследование прав доступа от вышестоящих каталогов отключено
А) Обязательные права
Специальная учетная запись: «СИСТЕМА (SYSTEM)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Локальная группа безопасности: «Администраторы (Administrators)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.1) Полномочия «Только чтение (Read Only)»
Группа доступа пользователей: «FILE-Имя ресурса-RO»	Базовые права: а) чтение и выполнение (read & execute); б) список содержимого папки (list folder contents); в) чтение (read);	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.2) Полномочия «Чтение и запись (Read & Write)»
Группа доступа пользователей: «FILE-Имя ресурса-RW»	Базовые права: а) изменение (modify); б) чтение и выполнение (read & execute); в) список содержимого папки (list folder contents); г) чтение (read); д) запись (write);	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.3) Другие полномочия при их наличии
Группа доступа пользователей: «FILE-Имя ресурса-аббревиатура полномочий»	Согласно полномочиям	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)

Табилца 2 – Шаблон NTFS-прав доступа для промежуточных каталогов файлового информационного ресурса.

Субъекты	Права	Режим наследования
Наследование прав доступа от вышестоящих каталогов включено, но если данный каталог является вышестоящим по отношению к файловым информационным ресурсам и не входит ни в один другой файловый информационный ресурс, то наследование отключено
А) Обязательные права
Специальная учетная запись: «СИСТЕМА (SYSTEM)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Локальная группа безопасности: «Администраторы»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.1) Полномочия «Проход через каталог (TRAVERSE)»
Группы доступа пользователей информационных ресурсов, для которых этот каталог является промежуточным	Дополнительные параметры безопасности: а) траверс папок / выполнение файлов (travers folder / execute files); б) содержимое папки / чтение данных (list folder / read data); в) чтение атрибутов (read attributes); в) чтение дополнительных атрибутов (read extended attributes); г) чтение разрешений (read permissions);	Только для этой папки (This folder only)

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

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

Г. Блокирование доступа пользователя к файловому информационному ресурсу
Учетная запись пользователя удаляется из групп доступа пользователей файлового информационного ресурса. Если работник увольняется, то членство в группах не меняется, а блокируется учетная запись целиком.

Регистрируется вложенный файловый информационный ресурс (согласно процессу А)
В группы доступа пользователей вложенного файлового информационного ресурса добавляются группы доступа пользователей вышестоящего составного файлового информационного ресурса.

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

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

Рассмотрим применение данного стандарта на примере гипотетической организации ООО «ИнфоКриптоСервис», где для централизованного хранения файловых информационных ресурсов выделен сервер с именем «FILESRV». Сервер работает под управлением операционной системы Microsoft Windows Server 2008 R2 и является членом домена Active Directory с FQDN именем «domain.ics» и NetBIOS именем «ICS».

Подготовка файлового сервера
На диске «D:» сервера «FILESRV» создаем каталог «D:\SHARE\». Этот каталог будет единой точкой входа во все файловые информационные ресурсы, размещенные на данном сервере. Организуем сетевой доступ к данной папке (используем апплет «Share and Storage Management»):

Создание файлового информационного ресурса
Постановка задачи.
Пусть в составе организации ООО «ИнфоКриптоСервис» имеется Отдел разработки информационных систем в составе: начальника отдела Иванова Сергея Леонидовича (SL.Ivanov@domain.ics), специалиста Маркина Льва Борисовича (LB.Markin@domain.ics), и для них нужно организовать файловый информационный ресурс для хранения данных подразделения. Обоим работникам требуется доступ на чтение и запись к данному ресурсу.

«FILE-FILESRV-SHARE-Отд. разр. ИС-RO»
«FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Предоставление доступа пользователю к файловому информационному ресурсу
Постановка задачи.
Предположим, в отдел разработки приняли еще одного работника – специалиста Егорова Михаила Владимировича (MB.Egorov@domain.ics), и ему, как и остальным работникам отдела, требуется доступ на чтение и запись к файловому информационному ресурсу отдела.

Решение.
Учетную запись работника необходимо добавить в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Создание вложенного информационного ресурса. Расширение доступа
Постановка задачи.
Предположим, Отдел разработки информационных систем решил улучшить качество взаимодействия с Отделом маркетинга и предоставить руководителю последнего — Кругликовой Наталье Евгеньевне (NE.Kruglikova@domain.ics) — доступ на чтение к актуальной документации на продукты, хранящейся в папке «Документация» файлового информационного ресурса Отдела разработки информационных систем.

Решение.
Для решения данной задачи необходимо сделать вложенный ресурс «\\FILESRV\share\Отдел разработки информационных систем\Документация», доступ к которому на чтение и запись должен быть (остаться) у всех пользователей, имевших доступ к «\\FILESRV\share\Отдел разработки информационных систем\ и добавиться доступ на чтение для пользователя Кругликовой Натальи Евгеньевне (NE.Kruglikova@domain.ics)

«FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO»
«FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

Теперь, если Кругликова Наталья Евгеньевна (NE.Kruglikova@domain.ics) обратится по ссылке «\\FILESRV\share\Отдел разработки информационных систем\Документация», то она сможет попасть в интересующую ее папку, но обращаться по полному пути не всегда удобно, поэтому настроим сквозной проход к данной паке от точки входа «\\FILESRV\share\» («D:\SHARE\»). Для этого настроим права доступа на промежуточные каталоги «D:\SHARE\» и «D:\SHARE\Отдел разработки информационных систем\».

Проведем настройку «D:\SHARE\»:

Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

и «D:\SHARE\Отдел разработки информационных систем»:

Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

Создание вложенного информационного ресурса. Сужение доступа
Постановка задачи
В целях организации резервного копирования наработок Отдела разработки информационных систем начальнику отдела Иванову Сергею Леонидовичу (SL.Ivanov@domain.ics), в рамках файлового информационного ресурса отдела, понадобилась сетевая папка «Архив», доступ к которой был бы только у него.

Решение.
Для решения данной задачи в файловом информационном ресурсе отдела требуется сделать вложенный ресурс «Архив» («\\FILESRV\share\Отдел разработки информационных систем\Архив»), доступ к которому предоставить только начальнику отдела.

24.11.2020

Windows 10, Windows Server 2016

комментариев 13

По умолчанию, при доступе к общей сетевой папке на сервере, включенном в домен Active Directory, с компьютеров из рабочей группы (не добавленных в домен) у пользователя появляется запрос на ввод пароля доменной учетной записи. Попробуем разобраться, как разрешить анонимный доступ к общим сетевым папкам и принтерам на доменном сервере с компьютеров рабочей группы без авторизации на примере Windows 10 / Windows Server 2016.

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

Локальные политики анонимного доступа

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

Перейдите в раздел Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options)

Настройте следующие политики:

Учетные записи: Состояние учётной записи ‘Гость’ (Accounts: Guest Account Status): Включен (Enabled);
Сетевой доступ: разрешить применение разрешений “Для всех” к анонимным пользователям (Network access: Let Everyone permissions apply to anonymous users): Включен (Enabled);
Сетевой доступ: Не разрешать перечисление учетных записей SAM и общих ресурсов (Network access: Do not allow anonymous enumeration of SAM accounts and shares): Отключен (Disabled).

В целях безопасности желательно также открыть политику “Запретить локальный вход” (Deny log on locally) в разделе Локальные политики -> Назначение прав пользователя и убедиться, что в политике указана учетная запись “Гость”.

Затем проверьте, что в этом же разделе в политике “Доступ к компьютеру из сети” (Access this computer from network) присутствует запись Гость, а в политике “Отказать в доступе к этому компьютеру из сети” (Deny access to this computer from the network) учетка Гость не должна быть указана.

Также убедитесь, что включен общий доступ к сетевым папкам в разделе Параметры -> Сеть и Интернет -> Ваше_сетевое_подключение (Ethernet или Wi-Fi) -> Изменение расширенных параметров общего доступа (Settings -> Network & Internet -> Ethernet -> Change advanced sharing options). В секции “Все сети” должен быть выбрана настройка “Включить общий доступ, чтобы сетевые пользователи могли читать и записывать файлы в общих папках” и выбрать “Отключить парольную защиту (если вы доверяете всем устройствам в вашей сети)” (см. статью о проблемах обнаружения компьютеров в рабочих группах).

Настройка анонимного доступа к общей папке

Также на вкладке Доступ нужно предоставить права анонимным пользователям на доступ к шаре (Доступ -> Расширенная настройка -> Разрешения). Проверьте, что у группы Все есть право на Изменение и Чтение.

Теперь в редакторе локальных политик в секции Локальные политики -> Параметры безопасности нужно в политике “Сетевой доступ: разрешать анонимный доступ к общим ресурсам” (Network access: Shares that can be accessed anonymous) указать имя сетевой папки, к которой вы хотите предоставить анонимный доступ (в моем примере имя сетевой папки – Share).

Предоставление анонимного доступа к общему сетевому принтеру

Чтобы разрешить анонимный доступ к сетевому принтеру на вашем компьютере, нужно открыть свойства общего принтера в Панели управления (Панель управления\Оборудование и звук\Устройства и принтеры). На вкладке доступа отметьте опцию “Прорисовка задания печати на клиентских компьютерах” (Render print jobs on client computers).

Затем на вкладке безопасность для группы “Все” отметить все галки.

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

Файловый сервер установлен. Об установке и настройке файлового сервера смотрите статью «Файловый сервер на базе 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) с нового файлового сервера. У пользователя все работает, есть возможность создавать файлы и папки.

Сетевые папки первого отдела

Ошибка при попытке входа

Хочу добавить, что у меня не стояла задача создания структуры папок в корневой папке отдела и назначения прав на папки структуры.

Читайте также: