Назад | Перейти на главную страницу

Конфигурация аутентификации с IIS 8.5 в Windows Server 2012

У меня есть сайт, размещенный с использованием IIS на сервере Windows Server 2012 R2. Приложение настроено на использование пула приложений, который использует учетную запись NetworkService в качестве удостоверения пула приложений. Сайт также настроен на использование сквозной аутентификации, а также базовой аутентификации и аутентификации Windows (в соответствии со спецификацией разработчиков).

Это приложение предполагается развернуть так, чтобы учетная запись конечных пользователей использовалась для проверки того, что они могут получить доступ к приложению (список пользователей хранится в базе данных приложений), а доступ ко всем файлам в корневом каталоге WWW осуществляется с помощью учетной записи NetworkService. . Однако похоже, что учетная запись конечного пользователя используется для доступа к файлам в каталоге WWW. Это работает только для пользователей, имеющих доступ к серверу: предоставление определенному пользователю доступа к каталогу WWW позволяет им запускать приложение. Все остальные пользователи получают ошибку 401,5, исходящую от IsapiModule.

Как мне настроить этот сервер так, чтобы он получал доступ к файлам на диске, используя идентификатор пользователя приложения, а не сквозную учетную запись, используемую для аутентификации?

Отключите анонимную аутентификацию и включите аутентификацию Windows. Чтобы это работало, клиентские компьютеры и сам сервер должны быть присоединены к одному домену AD. Затем вы предоставляете каждому пользователю AD разрешения на чтение / выполнение в корневой веб-папке (разрешения для папки NTFS) - затем аутентификация выполняется автоматически - пользователям либо будет отказано в доступе 403, либо они увидят веб-сайт. Идентификация самого пула приложений теперь играет в этом роль (однако не используйте сетевую службу, в любом случае это плохая практика безопасности, переключитесь на ApplicationPoolIdentity).

Кроме того, для управления доступом к веб-сайту не предоставляйте отдельным пользователям прямой доступ на чтение / выполнение к корневой папке. Вместо этого создайте группу AD, сделайте всех пользователей, которым нужен сайт, членами группы, а затем предоставьте группе доступ для чтения / выполнения к веб-сайту.