Настройка FTP-сервера на базе встроенных служб IIS (Internet Information Services) в Windows Server 2008 R2 — классическая задача для организации обмена файлами. Однако системные администраторы часто сталкиваются со специфическими ошибками авторизации, предупреждениями тестирования доступа и сложностями при разграничении прав пользователей. В этой статье мы подробно разберем, как решить проблему с предупреждением «Cannot verify access to path...», почему «ломается» авторизация при включении изоляции пользователей, как правильно настроить разграничение доступа без использования жесткой изоляции и как подружить FTP-сервер с аппаратными межсетевыми экранами (на примере D-Link DFL-210).
При настройке физического пути к каталогу FTP-сайта или виртуального каталога администраторы часто используют кнопку «Test Settings» (Тест настроек) в IIS Manager. В результате проверки сквозной аутентификации (pass-through authentication) часто возникает следующее предупреждение:
«Authentication - The application pool identity is valid. Authorization - cannot verify access to path... The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify whether the built-in account has access...»
Проанализируем природу этого предупреждения. Важно понимать, что данное сообщение в IIS 7.0/7.5 является штатным поведением системы (by design). Оно возникает из-за того, что консоль IIS Manager пытается проверить доступ к указанному физическому каталогу от имени учетной записи текущего администратора, запустившего консоль, а не от имени фактической рабочей учетной записи пула приложений (Application Pool Identity) или сквозного пользователя.
Если права доступа на уровне файловой системы NTFS для целевой папки настроены корректно, это предупреждение можно смело проигнорировать — на реальную работоспособность FTP-сервера оно никак не влияет. Однако, если доступ действительно заблокирован при реальном подключении клиента, выполним следующие проверки:
IIS_IUSRS или конкретной учетной записи, под которой запускается пул приложений, есть права как минимум на «Чтение» (Read) и «Список содержимого папки» (List folder contents) на уровне NTFS.NetworkService или LocalSystem), необходимо предоставить доступ к сетевой папке учетной записи самого компьютера в формате ИмяДомена\ИмяКомпьютера$.Часто для разграничения доступа пользователей к файлам администраторы включают режим изоляции пользователей FTP (FTP User Isolation). Однако это действие нередко приводит к полной невозможности авторизоваться на сервере: клиенты получают ошибку 530 User cannot log in, home directory inaccessible.
Выясним причину этой проблемы. Для работы режима полной изоляции служба IIS требует строго определенной иерархии папок на диске. Если структура каталогов нарушена, сервер не сможет сопоставить авторизовавшегося пользователя с его домашним каталогом и прервет сессию.
Рассмотрим правила построения структуры каталогов для разных типов учетных записей при включенной изоляции:
LocalUser. Структура должна выглядеть так: [Путь_к_корню_FTP]\LocalUser\[Имя_Пользователя]. Дополнительно в каталоге LocalUser обязательно должна существовать пустая папка с именем Public (она необходима для обработки анонимных подключений).[Путь_к_корню_FTP]\[Имя_Домена]\[Имя_Пользователя].Если вы активируете режим полной изоляции пользователей, но в вашей структуре каталогов отсутствует папка, точно соответствующая имени учетной записи пользователя (или домена), IIS выдаст ошибку авторизации.
Если существующая структура папок (например, организованная по именам контрагентов или отделов) не позволяет быстро перестроить иерархию под требования полной изоляции, мы можем применить альтернативный и очень удобный подход — режим «Do not isolate users. Start users in: User name directory» (Не изолировать пользователей. Запускать в каталоге с именем пользователя).
Разберем этот метод по шагам:
Для начала создадим локальных пользователей в операционной системе Windows Server. Для этого перейдем в «Управление компьютером» (Computer Management) -> «Локальные пользователи и группы» (Local Users and Groups) и создадим учетную запись. Имя пользователя должно строго соответствовать названию целевой папки, в которую он должен попадать при подключении.
Пусть корневой каталог нашего FTP-сервера расположен по пути C:\ftp_root. Внутри него создадим подпапки для каждого пользователя. Имя подпапки должно в точности совпадать с именем созданного пользователя операционной системы:
C:\ftp_root\user1
C:\ftp_root\user2
Настроим права NTFS для папки конкретного пользователя (например, C:\ftp_root\user1):
user1, перейдем на вкладку «Безопасность» (Security) и нажмем «Дополнительно» (Advanced).user1.user1 права на «Изменение» (Modify), «Чтение и выполнение» (Read & Execute), «Список содержимого папки» (List folder contents) и «Запись» (Write).Теперь перейдем в консоль IIS Manager и настроим поведение FTP-сервера:
Проанализируем, как теперь работает логика подключения. Когда пользователь user1 авторизуется на FTP-сервере, служба IIS автоматически перенаправит его сессию в подпапку user1, расположенную в корне FTP-сайта. Пользователь сразу увидит содержимое своего каталога.
Внимание! Помните, что данный режим не является полноценной изоляцией. Это лишь средство автоматического перенаправления пользователя в его домашний каталог при входе. Если пользователь работает через продвинутый FTP-клиент (например, FileZilla, WinSCP или через командную строку) и выполнит команду перехода на уровень выше (cd ..), он технически сможет выйти в корень FTP-сервера.
Чтобы предотвратить доступ пользователя к чужим папкам и к корню FTP, мы должны жестко ограничить его права на уровне NTFS:
C:\ftp_root) пользователям нельзя давать права на чтение содержимого. Предоставьте им только право «Обзор папки / выполнение файлов» (Traverse folder / execute file) — это позволит им проходить сквозь корень к своим папкам, но не позволит просматривать список чужих каталогов в корне.C:\ftp_root\user2) у пользователя user1 не должно быть никаких прав доступа в NTFS. При попытке перейти в чужую папку или просмотреть ее содержимое пользователь получит ошибку отказа в доступе (Access Denied).Особое внимание следует уделить сетевой доступности FTP-сервера из внешней сети. Автор темы упомянул использование межсетевого экрана D-Link DFL-210. Специфика протокола FTP заключается в использовании двух разных каналов связи: управляющего канала (порт 21 по умолчанию) и канала передачи данных (динамические порты в пассивном режиме).
Разберем основные проблемы и методы их решения при работе за шлюзом D-Link DFL:
В межсетевых экранах D-Link серии DFL по умолчанию включен специальный модуль — FTP ALG. Он перехватывает трафик на порту 21, анализирует команды пассивного (PASV) режима и автоматически открывает на внешнем интерфейсе динамические порты для передачи данных, запрашиваемые клиентом. Это отлично работает для стандартного незашифрованного FTP.
Если вы решите обезопасить передачу данных и включите на IIS требование SSL (FTPS), управляющий канал на порту 21 станет зашифрованным. Межсетевой экран D-Link DFL-210 больше не сможет анализировать проходящие пакеты и «читать» команды согласования портов передачи данных. Как результат: пользователь успешно проходит авторизацию, но при попытке получить список файлов (команда LIST) или передать файл подключение зависает и обрывается.
Чтобы гарантировать стабильную работу FTP (как с шифрованием, так и без него) за аппаратным фаерволом, необходимо зафиксировать диапазон пассивных портов и вручную пробросить их на шлюзе:
50000-50100. Этого диапазона вполне достаточно для одновременной работы нескольких десятков пользователей.50000-50100 (TCP) на локальный IP-адрес вашего Windows Server. При этом для правила проброса пассивных портов используйте простую службу TCP без применения профиля FTP ALG, так как порты теперь жестко предопределены.Следуя этим рекомендациям, мы сможем построить надежную, безопасную и стабильную систему обмена файлами на базе Windows Server 2008 R2 и IIS, решив проблемы с авторизацией и разграничением прав пользователей.