Iis проверка идентификации компьютера


Проверка идентификации IISExpress AppPool

5 RT. [2013-11-09 00:48:00]

Мне нужно было запустить IISExpress под конкретную личность. Пройдя через этот пост как запустить iisexpress пул приложений под другим идентификатором, я изменил атрибуты имени пользователя и пароля processModel в файле \Documents\IISExpress\config\applicationhost.config.

Я хочу проверить изменения в своем веб-приложении. Есть ли способ проверить?

В конечном счете, то, что мне нужно, — это то, что моя безопасность работает правильно, используя атрибут PrincipalPermission. Я верю, что свойство Name этого атрибута соответствует пользователю, под которым работает IISExpress и мое приложение.

Заранее благодарим за помощь.

2 ответа

6 Решение vikomall [2013-11-12 18:20:00]

IISExpress работает с текущим идентификатором пользователя, и изменение имени/пароля ProcessModel не поможет. Единственный способ запустить с конкретным идентификатором — запустить iisexpress.exe с помощью «runas».

Возможно, мне слишком поздно помогать, но попробовали ли вы изменить свой проект для работы с локальным IIS вместо IIS Express?

Вот так, как я это делаю (вы можете начать в Visual Studio, но я нахожу это более напряженным):

  • Запустите диспетчер IIS с правами администратора (важно, чтобы у вас были права на гадость с localhost).
  • Добавить новый пул приложений, который работает с идентификацией, необходимой для вашей базы данных (возможно, вашей учетной записи Windows)
  • Создайте новое приложение на iis
    • укажите его в папку проекта
    • назначить его только что созданному пулу приложений
  • В Visual Studio откройте свои свойства проекта (выберите проект в проводнике решений, нажмите Alt-Enter или используйте контекстное меню). В веб-разделе выберите Local IIS вместо IIS Express. Нет необходимости создавать виртуальный каталог (вы уже это сделали).

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

Поннятие об анонимной идентификации и учетной записи IUSR

Dreamweaver UltraDev больше не поддерживается, а центр поддержки Dreamweaver UltraDev больше не обновляется. Функция, предоставлявшаяся в Dreamweaver UltraDev, теперь доступна в Dreamweaver, начиная с Dreamweaver MX.

Анонимный доступ, самый популярный способ управления доступом к сайтам, позволяет любому пользователю посещать открытые разделы сайта, но при этом неавторизованные пользователи не получат доступа к функциям администрирования и конфиденциальным данным на веб-сервере. Анонимная идентификация предоставляет пользователям доступ на сайт без запроса имени пользователя или пароля. Когда пользователь пытается подключиться к сайту, веб-сервер назначает такому пользователю учетную запись Windows под названием IUSR_название-компьютера, где «название-компьютера» – это имя имя сервера, на котором работает IIS.

По умолчанию учетная запись IUSR_название-компьютера включена в группу пользователей Windows «Гости» при установленном на сервере IIS. Эта группа имеет ограничения по правам, соответствующие разрешениям NTFS, которые задают уровень доступа и тип содержимого, доступного для обычных пользователей Интернета. Изменения можно внести в учетную запись, используемую для анонимной идентификации, в диспетчере служб Интернета на уровне веб-сервера или для отдельных виртуальных каталогов и файлов. Права доступа для учетной записи IUSR_название-компьютера можно изменить с помощью диспетчера пользователей для Windows NT и раздела «Локальные пользователи и группы» на консоли управления сервером для Windows 2000.

IIS использует учетную запись вида IUSR_название-компьютера следующим образом:

Настраиваем авторизацию в IIS по сертификатам используя OneToOne


Всем доброго времени суток. Так уж получилось, на работе необходимо было настроить сервер с IIS, да не просто настроить, но повесить авторизацию на разные сервисы с использованием только определенного сервису сертификата. Данная проблема может быть решена использованием нескольких центров генерации, но не будем все усложнять и приступим к настройке «ОдинКОдному» нашего IIS.

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

Переходим к делу:
1) Устанавливаем IIS и необходимые компоненты. Обязательно отмечаем «Проверка подлинности с сопоставлением сертификата клиента IIS».

2) Для привязки нам понадобится клиентский сертификат в кодировке base64, его очень просто экспортировать из остнастки (certmgr.msc) «Сертификаты» или из «Свойства обозревателя».

3) Полученный сертификат открываем в текстовом редакторе и выстаиваем в одну линию, предварительно удалив строчки «BEGIN CERTIFICATE» и «END CERTIFICATE».

С подготовкой закончили переходим к серверу.

4) Запускаем остнастку (inetmgr) «Диспетчер служб IIS», и устанавливаем сертификат сервера. В моём случае CN сертификата Localhost.

5) После этого мы можем привязать этот сертификат к сервисам. Идем в привязки и выбрав Https указываем необходимый порт и сертификат.

6) В параметрах SSL отмечаем «Требовать SSL» и сертификат клиента «требовать».

7) Теперь любой сертификат выпущенный нашим УЦ подойдет для авторизации, но цель данной статьи как раз показать следующий шаг когда клиентов с сертификатами необходимо разделить. Идем в «Редактор конфигураций» по адресу: «system.webServer/security/authentication/iisClientCertificateMappingAuthentication».

8) Здесь предстоит сделать выбор или мы пускаем по конкретным сертификатам или по определенному полю в сертификате (например уникальный OID).

9) Рассмотрим параметр «oneToOneCertificateMappingsEnabled». Установив его значении в «True» мы сможем привязать конкретный сертификат к пользователю.

10) Полученный на втором пункте сертификат вставляем в поле «certificate». Поля «userName» и «password» заполняем учетной записью, которую предварительно создали.

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

На этом этапе авторизация должна проходить только по заданному сертификату.

IIS — возможна ли анонимная и Windows-аутентификация на одном сайте одновременно?

Есть сайт на IIS 8.0 (Windows 2008 r2), к которому должен быть доступ как у анонимных пользователей, так и у доменных пользователей. Если включаем на сайте проверку подлинности Windows, то доменные пользователи заходят нормально, но анонимные пользователи не могут попасть на сайт. Если дополнительно включаем анонимную проверку подлинности, то зайти на сайт могут все, но доменные пользователи тоже считаются анонимными.

Простейшим решением выглядит завести два сайта (с проверкой подлинности windows / анонимной), но в этом случае получается две гиперссылки на один логический ресурс, что по некоторым причинам неприемлемо. Точка входа должна быть одна.

Исследуем аутентификацию в IIS

Протокол аутентификации Kerberos уже затрагивался в этом блоге ранее. В этом посте пойдет речь про аутентификацию Kerberos, NTLM и Negotiate в веб-сервере IIS. Будет проверено на практике какой протокол аутентификации используется в том или ином случае. Для этого будет проведен несколько тестов в каждом из которых будет сделан вывод. Все выводы можно прочитать в конце поста.

Kerberos

Начнем с общего описания аутентификации Kerberos. Пользователь заходит на рабочую станцию (клиент) в домене. Для аутентификации клиент связывается с центром выдачи ключей (key distribution center, KDC), для Windows это контроллер домена. Контроллер домена проверяет, что логин и хеш пароля, введенные пользователем, совпадают с хранящимися в базе KDC. Если учетные данные корректны, центр выдает удостоверение (ticket-granting ticket, TGT), подписанное особенным доменным пользователем krbtgt. TGT используется для подтверждения, что пользователь прошел аутентификацию. После этого пользователь подключается к какому-либо ресурсу в домене, например, общей папке на файловом сервере. Клиент обращается к KDC, прилагая TGT, за выдачей удостоверения запрашиваемого сервиса (service ticket, TGS). Контроллер домена проверяет, что такой сервис совпадает с хранящимся в базе KDC и выдает клиенту TGS. После этого клиент обращается к файловому серверу, прилагая TGS. Файловый сервер видит, что TGS выдан контроллером домена и принимает подключение пользователя.

Процесс показан на рисунке


Подключившись доменным пользователем можно вывести как TGT:

При запросе доступа к сервису вводится понятие название службы (service principal name, SPN). SPN позволяет клиенту однозначно указать к какому сервису запрашивает доступ пользователь. Название уникально в рамках леса. Таким образом при обращении к сервису клиент включает TGS, для того, чтобы сервис увидел, что пользователь получил разрешение от KDC. Получив ответ от сервиса, пользователь удостоверяется, что сервис работает под учетной записью ассоциированной с SPN, потому что он смог расшифровать TGS.

Существуют два вида SPN: по имени компьютера и пользователя. Когда компьютер вводится в домен Active Directory, его учетной записи присваивается стандартный список SPN.

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

Таким образом при доступе к веб сайту на компьютере iis.example.org пользователь запрашивает SPN с названием http/iis.example.org у KDC. Соединяясь с веб сайтом, клиент показывает TGS. Поскольку сервер доверяет центру, он доверяет удостоверениям, выданным центром. Напрямую между веб сайтом и пользователем обмен паролем в открытом или зашифрованном виде не происходит. Для прохождения аутентификации Kerberos необходимо чтобы у компьютера пользователя и веб сервера была связь с контроллером домена.

В рамках настройки IIS, сайт (а точнее AppPool) может запускаться от локальной записи (например, Network Service) или от доменной учетной записи пользователя. В первом случае SPN следует прописать в доменной учетной записи компьютера, во втором — пользователя.

Подготовка к тестам.

  1. Используется три компьютера:
    dc.example.org — контроллер домена EXAMPLE.ORG
    iis.example.org — веб сервер IIS
    win10.example.org — клиент с установленным Chrome.
  2. Все машины введены в домен
  3. Создана DNS запись тестового веб-сайта на котроллере домена
    website.example.org
  4. Создан доменный пользователь, который будет подключаться к сайту
    win10user
  5. Создан доменный пользователь, под которым будет запускаться IIS AppPool
    iisapppool
  6. Создан сайт в IIS со страницей default.aspx взятой отсюда.
  7. Создана привязка сайта (binding) для iis.example.org и website.example.org
  8. Включаена Windows аутентификация в IIS с провайдерами Negotiate и NTLM
  9. Устанавлен пользователь iisapppool для запуска IIS AppPool
  10. Настроена Windows аутентификация, включена аутентификация ядра и учетной записи AppPool
Илон Маск рекомендует:  Iis приостановка веб сервера (pauseweb)
  • Даны пользователю iisapppool права на папку с сайтом
  • На клиенте в Internet Explorer включены в список доверенных сайтов iis.example.org и website.example.org. И включаем автоматический вход под текущим пользователем
  • На клиенте добавляем в hosts записи iis.example.org и website.example.org

  • Тесты.

    1. Аутентификация в обычном режиме провайдеры Negotiate, NTLM.
      Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
      Клиент в домене
      Клиент имеет полную связь с контроллером домена и веб сервером

    Клиент подключается к сайту iis.example.org
    Сервер подключается к контроллеру домена на порт TCP 88 AS REQ для iisapppool

    Контроллер домена отвечает PREAUTH REQUIRED

    Сервер подключается к контроллеру домена AS REQ для iisapppool

    Контроллер домена отвечает AS REP

    Сервер подключается к контроллеру домена TGS REQ для HOST/iis.example.org

    Контроллер домена отвечает TGS REP

    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM

    Клиент подключается к контроллеру домена на порт TCP 88 AS REQ для win10user

    Контроллер домена отвечает PREAUTH REQUIRED

    Клиент подключается к контроллеру домена AS REQ для win10user

    Контроллер домена отвечает AS REP

    Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.kraftvaerk.com

    Контроллер домена отвечает TGS REP

    Клиент подключается с HTTP заголовком Authorization: Negotiate

    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate

    ВЫВОД:

    • клиент подключается к контроллеру домена;
    • клиент передает свои аутентифицированные данные контроллеру домена;
    • сервер подключается к контроллеру домена
  • Аутентификация в обычном режиме провайдер NTLM
    Север включен с Windows аутентификацией с провайдером NTLM
    Клиент подключается к сайту iis.example.org
    Сервер отвечает с HTTP заголовком WWW-Authenticate: NTLM

    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE

    Сервер отвечает с HTTP заголовком WWW-Authenticate: NTLM включающим NTLMSSP_CHALLENGE

    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_AUTH

    Сервер подключается к контроллеру домена NetrLogonSamLogonEx

    Контроллер домена отвечает NetrLogonSamLogonEx

    Сервер отвечает с HTTP кодом 200

    ВЫВОД:

    • клиент не подключается к контроллеру домена;
    • клиент передает свои аутентификационные данные серверу;
    • сервер подключается к контроллеру домена и аутентифицирует пользователя (Pass-Through Authentication).
  • Аутентификация с отсутствующим SPN
    Клиент подключается к сайту website.example.org
    Клиент подключается к контроллеру домена TGS REQ для HTTP/website.example.org
    Контроллер домена отвечает KRB ERR SPN UNKOWN

    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE

    Происходит аутентификация NTLM
    ВЫВОД:

    • аутентификация Kerberos требует наличия корректного SPN на контрлере домена;
    • без SPN происходит автоматическое переключение на NTLM.
  • Аутентификация с нестандартным портом
    Сервер IIS запущен на порту 8080.
    Клиент подключается к сайту iis.example.org:8080
    Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.kraftvaerk.com
    Происходит аутентификация Kerberos
    ВЫВОД:
    • веб-браузер запрашивает SPN без номера порта;
    • для аутентификации Kerberos на веб-сервере не обязательно указывать порт в SPN учетной записи, под которой запущен веб-сайт;
    • другие протоколы могут указывать порт в запросе SPN.
  • Аутентификация с пользователем IIS AppPool
    Сервер переключен IIS AppPool с использования iisapppool на Network Service
    Клиент подключается к сайту iis.example.org
    Происходит аутентификация Kerberos
    Сервер переключен с использования Network Service на iisappool
    У iisapppool убраны все SPN
    Клиент подключается к сайту iis.example.org
    Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.kraftvaerk.com
    Контроллер домена отвечает TGS REP
    Клиент подключается с HTTP заголовком Authorization: Negotiate
    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate KRB ERR MODIFIED

    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE
    ВЫВОД:

    • клиенту без разницы под какой учетной записью запущен веб-сайт; для Kerberos аутентификации важно чтобы у учетной записи веб-сайта был установлен SPN;
    • по умолчанию у учетной записи компьютера есть HOST SPN;
    • HOST SPN включает в себя несколько сервисов;
    • HTTP покрывается HOST SPN;
    • запрашивая HTTP SPN клиент получает TGS от компьютерной учетной записи;
    • если на контроллере домена существует учетная запись с HTTP SPN на то же имя, TGS отправляется от этой учетной записи;
    • получив ответ Kerberos Error клиент автоматически переключается на NTLM.
  • Аутентификация с ограниченным доступом и провайдеры Negotiate, NTLM
    Клиент имеет связь только с веб сервером по порту 80
    Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
    Клиент подключается к сайту iis.example.org
    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM
    Клиент запрашивает DNS SRV запись
    _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.EXAMPLE.ORG
    Клиент не получает ответ
    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE
    Происходит аутентификация NTLM
    ВЫВОД:


    • при ограниченном соединении аутентификация Kerberos не работает.
  • Аутентификация с ограниченным доступом и провайдер Negotiate
    Клиент имеет связь только с веб сервером по порту 80
    Сервер включен с Windows аутентификацией с провайдером Negotiate
    Клиент подключается к сайту iis.example.org
    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate

    Клиент запрашивает DNS SRV запись
    _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.EXAMPLE.ORG
    Клиент не получает ответ
    Клиент показывает в браузере HTTP ошибку с кодом 401 Unauthorized
    ВЫВОД:

    • Провайдер Negotiate включает в себя два протокола: Kerberos и NTLM;
    • получив ответ WWW-Authenticate Negotiate клиент сначала пробует Kerberos, затем NTLM;
    • не получив никакого ответа Kerberos клиент не переключается на NTLM.
  • Аутентификация с клиента в рабочей группе
    Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
    Клиент в рабочей группе
    Клиент имеет полную связь с контроллером домена и веб сервером
    Клиент подключается к сайту iis.example.org
    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM
    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE
    ВЫВОД:
    • если клиент не в домене, то используется NTLM аутентификация.
  • Web-сервисы. Аутентификация ОС

    Я unkairosed

    Почему-то не могу написать в свою предыдущую тему по этому вопросу, дублирую текст здесь с дополнением.

    Стоит задача разработать мобильное приложение для 1С:ЗУП для рядового сотрудника. У пользователя должна быть возможность просматривать свой расчетный листок и личные данные (кадровые). Есть центральная база 1С:ЗУП. В ней разработаны веб-сервисы, опубликованы на веб-сервере, используется IIS. При публикации указываю «Использовать аутентификацию операционной системы». Мобильное приложение также опубликовано на веб-сервере, при публикации выставлен флаг «Использовать аутентификацию операционной системы на веб-сервере». При добавлении ИБ в мобильном приложении (на мобильном устройстве) указываю доменного пользователя и его пароль, мобильное приложение успешно загружается с веб-сервера. Проблема в том, что при обращении к веб-сервису из мобильного приложения система выдает ошибку: «Аутентификация пользователя не выполнена», при обращении указываю доменного пользователя и его пароль (для WSОпределения и для WSПрокси). Если вместе с веб-сервисами опубликовать само приложение (1С:ЗУП), то при обращении к нему по адресу в веб-браузере происходит запрос на ввод пользователя и пароля (доменная учетка), ввожу, принимает, захожу в приложение. Если же через браузер обращаюсь к веб-сервису, также запрашивает пользователя и пароль, ввожу, но не прохожу авторизацию. В IIS анонимная проверка подлинности отключена, включены «Проверка подлинности Windows» (хотя пробовал «Обычная проверка подлинности» — ситуация та же). Доменный пользователь добавлен в группу IIS_IUSRS. Никак не могу разобраться с решением этой проблемы, просьба помочь, кто в теме, заранее спасибо.

    Настройка аутентификации в IIS 8

    IIS 8 поддерживает интегрированный режим ASP.NET, который помимо прочего объединяет конвейер обработки ASP.NET HTTP с конвейером обработки IIS HTTP. Это предоставляет в распоряжение богатейший набор новых возможностей, которые можно использовать в сочетании с имеющимися знаниями ASP.NET. Например, одна из них — это возможность применения аутентификации с помощью форм ASP.NET для других веб-приложений, сконфигурированных в IIS 8, которые не обязательно должны быть построены на ASP.NET.

    Более того, IIS 8 использует файл web.config для хранения многих частей конфигурации веб-приложений внутри веб-сервера. Это означает возможность настройки многих параметров приложения с использованием либо консоли управления IIS 8, либо за счет непосредственной модификации файла web.config. Благодаря тесной интеграции средств конфигурирования ASP.NET и IIS 8, любые изменения, внесенные непосредственно в файл web.config, немедленно отражаются в консоли управления, и наоборот.

    Давайте сначала рассмотрим возможности конфигурирования аутентификации с помощью форм из среды консоли управления IIS 8. Конфигурировать аутентификацию с помощью форм можно с использованием средства настройки аутентификации консоли управления IIS 8, как показано на рисунке ниже:

    После разрешения аутентификации с помощью форм подобным образом также понадобится сконфигурировать необходимые правила авторизации. Наиболее важно добавить правило deny для анонимных пользователей с помощью средства конфигурирования авторизации в консоли управления IIS 8:

    Обе конфигурационные настройки затрагивают файл web.config и веб-сервер берет эту информацию из web.config для определения собственного поведения, что видно в следующем фрагменте кода:

    Вы заметите, что аутентификация с помощью форм, сконфигурированная IIS, как и следовало ожидать, находится в разделе . Но по умолчанию (и если вы ранее не добавили этого вручную), никаких правил авторизации там не будет. Как упоминалось ранее, не все опции конфигурации по умолчанию помещаются непосредственно в файл web.config. Авторизация URL — одна из таких опций конфигурации.

    В любом случае унифицированная консоль управления очень хорошо продумана, так что настраивать безопасность IIS и ASP.NET посредством других инструментов нет необходимости. Многие опции по умолчанию сохраняются непосредственно в файле web.config. Как известно можно даже сконфигурировать IIS так, чтобы почти все опции помещались непосредственно в web.config. Однако, как упоминалось ранее, интеграция ASP.NET предоставляет множество возможностей при запуске IIS 8 в интегрированном с ASP NET режиме.

    Илон Маск рекомендует:  Макросы для автоматического создания глобальных переменных

    При запуске IIS 8 в интегрированном режиме (выбираемом по умолчанию) IIS использует канал обработки HTTP для обработки как основанных на ASP.NET HTTP-модулей, так и встроенных HTTP-модулей IIS 8.


    Поскольку аутентификация с помощью форм реализована в виде HTTP-модуля ASP.NET, ее можно использовать для любого веб-приложения и виртуального каталога, сконфигурированного в IIS, который функционирует в интегрированном режиме. Это значит, что аутентификацию с помощью форм можно применять вместе с приложениями других типов, такими как статические HTML-сайты, классические приложения ASP или даже приложения PHP. Все, что потребуется сделать — это настроить веб-приложение как виртуальный каталог и затем сконфигурировать аутентификацию с помощью форм через консоль управления IIS 8. Это автоматически добавит к приложению конфигурацию web.config.

    Поскольку нужно позаботиться об одной дополнительной детали, давайте в этом разделе кратко рассмотрим настройку аутентификации с помощью форм для приложения, отличного от ASP.NET. Предположим, что имеется следующая страница PHP, работающая на веб-сервере:

    Теперь просто откройте доступ к папке, где расположен PHP-файл (например, test.php), как к виртуальному каталогу или веб-приложению внутри IIS. После этого можно сконфигурировать аутентификацию с помощью форм и настройки авторизации, как было описано ранее.

    Поскольку IIS 8 органично поддерживает аутентификацию с помощью форм, полагаясь на HTTP-модуль аутентификации с помощью форм, поставляемый в ASP.NET, она работает точно также, как работала бы с приложением ASP.NET. Все что нужно — это удостовериться в наличии необходимой страницы входа, которая сама по себе является страницей ASP.NET. Также должны быть доступны части, необходимые для страницы ASP.NET, внутри веб-приложения (или в другом виртуальном каталоге, если применяются cookie-наборы аутентификации между приложениями).

    На рисунке ниже показана страница PHP вместе со страницей входа ASP.NET в виртуальном каталоге. Аутентификация с помощью форм просто конфигурируется через управляющую консоль IIS 8, как было описано ранее:

    Однако просто поместить содержимое PHP вместе с основанными на ASP.NET страницами входа и сконфигурировать аутентификацию с помощью форм еще недостаточно. Когда вы попытаетесь выполнить переход на страницу PHP, аутентификация с помощью форм пока работать не будет. В зависимости от аутентификации и правил авторизации, вы либо получите ответ «unauthorized» («неавторизовано»), либо сможете переходить к странице PHP без приглашения на вход.

    Причина в том, что по умолчанию управляемые HTTP-модули, в том числе и модуль аутентификации с помощью форм, настроены так, что выполняются только по запросу кода, основанного на ASP.NET. Поэтому чтобы заставить работать аутентификацию с помощью форм, потребуется изменить это поведение, вызвав средство конфигурации HTTP Modules в консоли управления IIS 8 когда ваше веб-приложение выбрано. Затем нужно отобразить детальную информацию для модуля FormsAuthentication, сконфигурированного в списке модулей, как показано на рисунке ниже:

    Открыв средство конфигурации HTTP Modules, найдите FormsAuthentication и дважды щелкните на нем или выберите ссылку Edit (Правка) в панели задач справа. В открывшемся диалоговом окне снимите отметку с флажка Invoke Only for Requests to ASP.NET Applications or Managed Handlers (Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам), как показано на рисунке ниже:

    После завершения этой настройки при обращении к странице PHP в каталоге веб-приложения запрос будет аутентифицирован посредством аутентификации с помощью форм ASP.NET. Конфигурационный файл web.config для веб-приложения будет выглядеть следующим образом:

    Конфигурация FormsAuthenticationModule важна. Флажок в неотмеченном состоянии задает preCondition=»», которое по умолчанию установлено в managedHandler.

    IIS7: настройка встроенной проверки подлинности Windows, например, в IIS6

    Это для IIS 7 на Windows Server 2008, который не является частью домена AD. Я хотел бы защитить паролем веб-сайт, где люди должны ввести имя пользователя/пароль (например, учетную запись Windows) для просмотра веб-сайта. Затем веб-сайт будет использовать свой собственный метод (формы) проверки подлинности для обработки учетных записей пользователей и решить, показывать ли его отдельные страницы и т.д.

    В IIS6 мы просто отключили анонимный доступ и включили интегрированную проверку подлинности Windows. IIS7 ведет себя по-разному, и когда я ввожу имя пользователя/пароль для просмотра сайта, сайт подходит нормально, но перенаправляется на страницу входа. Как только я войду, сайт ведет себя естественно. Мне нужно иметь возможность перемещаться по сайту без входа в систему с учетными данными веб-сайта.

    Я не думаю, что включение анонимного доступа имеет смысл здесь, так как я хочу, чтобы доступ к веб-сайту был защищен паролем (всплывающее имя пользователя/пароль при первом переходе к URL-адресу).

    Любая помощь приветствуется!

    Двухступенчатая аутентификация не поддерживается в интегрированном режиме IIS7. Теперь аутентификация является модульной, поэтому вместо аутентификации IIS, за которой выполняется asp.net, выполняющая аутентификацию, все происходит одновременно.

    • Измените домен приложения в классическом режиме IIS6.
    • Следуйте этот пример (старая ссылка) о том, как подделать двухэтапную аутентификацию в интегрированном режиме IIS7.
    • Используйте Helicon Ape и mod_auth для обеспечения базовой аутентификации

    Чтобы включить проверку подлинности Windows в IIS7 на компьютере под управлением Windows 7:

    Перейдите в Панель управления

    Выберите Программы → Программы и функции

    Выберите «Включить или отключить функции Windows» с левой стороны.


    Разверните информационные службы Интернета → Услуги World Wide Web → Безопасность

    Выберите «Аутентификация Windows» и нажмите «ОК».

    Reset IIS и проверка в IIS для проверки подлинности Windows.

    Iis проверка идентификации компьютера

    Вкладка Безопасность каталога.

    На вкладке Безопасность каталога вы можете задать способ доступа к содержимому вашего сайта для анонимных пользователей:

    • полный,
    • ограниченный
    • через безопасные соединения HTTP.

    Анонимный доступ и проверка подлинности.

    Чтобы указать, нужна ли анонимным пользователям проверка подлинности (аутентификация) при доступе к вашему сайту, откройте диалоговое окно Методы проверки подлинности, щелкнув кнопку Изменить в области Управление доступом и проверка подлинности на вкладке Безопасность каталога. Это диалоговое окно используется для конфигурирования следующих настроек:

    • Анонимный доступ. Эта настройка определяет, разрешается ли анонимный доступ и какая при этом требуется пользовательская учетная запись. Стандартная анонимная учетная запись, созданная при установке IIS на сервере, имеет имя IUSR_ИмяСервера, где ИмяСервера является NetBIOS-именем сервера. При анонимном доступе пользователи имеют доступ к содержимому сайта при помощи своих web-браузеров и им не нужно предоставлять никаких полномочий для аутентификации. Этот метод аутентификации типичен для публичных web-узлов в Интернете. Другие методы аутентификации тем или иным способом позволяют определять пользовательские полномочия и применяются в основном для интрасетей, экстрасетей и закрытых сайтов Интернета.
    • Встроенная проверка подлинности Windows (или интегрированная аутентификация). Это новое название для настройки, которая раньше называлась Аутентификация вызов/ответ Windows NT (Windows NT Challenge/ Response Authentication), а еще раньше называлась NTLM (NT LAN Manager — Authentication). Для защиты аутентификации используется криптографический обмен без фактической передачи удостоверений через соединение. Пользователю не предлагается ввести свои удостоверения, а используются удостоверения, введенные при его текущем входе в систему. В интегрированной аутентификации Windows может также применяться аутентификация протокола Kerberos, если на сервере установлена Служба каталога Active Directory и если такая аутентификация поддерживается браузером клиента.
    • Краткая проверка для серверов доменов Windows. Этот новый метод аутентификации определен в спецификациях HTTP 1.1. Он поддерживается IIS 6.0 и может работать через брандмауэры и прокси-серверы. При этом методе через соединения передаются не сами удостоверения (credentials) пользователя, а хэш (hash) сообщения. Информация передается в незашифрованном виде, но она перемешана, поэтому ее декодирование существенно затруднено, что и обеспечивает защиту. Однако контроллеру домена, к которому поступает запрос на аутентификацию, требуется копия пользовательского пароля в виде открытого текста, поэтому необходимы дополнительные меры по защите контроллера домена.
    • Обычная. При использовании обычной (базисной) аутентификации клиент вводит свои удостоверения (credentials) в диалоговом окне, после чего удостоверения передаются через сетевое соединение без шифрования. Обычная аутентификация определяется первоначальными спецификациями протокола HTTP 1 и поддерживается почти всеми типами web-браузеров, в том числе самыми старыми. Если пользователи, посещающие ваш сайт, применяют старые браузеры, неспособные аутентифицироваться при помощи других методов, вам придется применять на своем сайте базисную аутентификацию, несмотря на уязвимость, присущую этому методу.
    • Проверка подлинности в системе .NET Passport. Данный метод использует технологию Microsoft Passport для аутентификации пользователей.

    Встроенная проверка подлинности Windows спроектирована для работы в основном в интрасетях и других внутренних сетях. Она не будет работать через прокси-соединения HTTP.

    Комбинирование различных способов проверки подлинности

    Рассмотрим последствия выбора более чем одного способа проверки подлинности (метода аутентификации) в диалоговом окне Методы проверки подлинности. Если вы выбрали сразу Анонимный доступ и какую-либо разновидность доступа с аутентификацией, например, Обычная, то сначала производится попытка анонимного доступа. При неудаче делается попытка доступа с аутентификацией. Неудача анонимного доступа может произойти, например, если полномочия NTFS для доступа к ресурсу явно запрещают доступ анонимных пользователей.

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

    Ограничения IP-адресов и имен доменов.

    На вкладке Безопасность каталога вы можете также ограничить доступ клиентов к web-узлу в зависимости от их IP-адреса или доменного DNS-имени.

    Ниже показано диалоговое окно Ограничение IP-адресов и имен доменов, доступ к которому производится из страницы с вкладкой Безопасность каталога.

    При помощи этого диалогового окна можно либо разрешить доступ к сайту всем клиентам, за исключением имеющих заданные в нем IP-адреса или доменные имена, либо запретить доступ всем клиентам, кроме имеющих заданные IP-адреса или доменные имена. Ограничения можно задавать одним из трех способов:

    • задать IP-адрес некоторого клиента;
    • задать идентификатор сети и маску подсети, представляющую диапазон IP-адресов;
    • задать DNS-имя некоторого домена.
    Илон Маск рекомендует:  Как в Word вставить таблицу Excel

    Заметьте, что последний способ существенно ухудшает производительность сервера, т.к. при его использовании для всех клиентов до получения разрешения соединиться необходим обратный поиск DNS.


    На вкладке Безопасность каталога (область Безопасные подключения) вы можете также разрешить использование соединений HTTP, защищенных при помощи протокола SSL, который применяется для шифрования web-трафика между клиентом и сервером. Шифрование при помощи SSL важно, если вы планируете использовать сервер для исполнения web-приложений, связанных с финансовыми операциями, или для хранения важной информации. Web-браузеры осуществляют доступ к защищенным серверам при помощи SSL, применяя URL, начинающиеся с https://, а не с http://.
    Протокол SSL основан на криптографии с открытым ключом, в которой идентификация и доверие к серверам (и клиентам) основываются на парах открытый/личный ключ, используемых для шифрования и расшифровки сообщений, что гарантирует защищенность и целостность передаваемой информации (другими словами, вы можете быть уверены, что сообщения приходят именно от тех, кто говорит, что послал их).
    Если вы хотите организовать работу с защищенными соединениями, нужно сначала установить доступ к сертификационному центру, способному выдать вашему серверу IIS необходимые ему сертификат сервера и пару ключей (открытый и личный). Для этого вы можете:

    • Воспользоваться доверяемым публичным сертификационным центром (например, VeriSign) и получить сертификат и пару ключей. Это решение подходит, если вы собираетесь использовать защищенные соединения для публичного сайта Интернета, размещенного на вашем сервере, или
    • Установить Службу сертификации на одном или нескольких серверах Windows Server 2003 вашего предприятия и завести свой собственный сертификационный центр. Это решение оптимально для организации защищенных соединений с сайтом приватной внутренней сети (интрасети), поддерживаемым вашим сервером.

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

    Чтобы получить сертификат сервера, выполните описанные ниже действия. В нашем примере запрашивается сертификат сервера для Веб-узла по умолчанию на сервере Win2003s.test.fio.ru, а Служба сертификации работает на контроллере домена dc1. fio.ru. Сертификационный центр для нашего предприятия fio.ru будет иметь имя Fio.

      В странице окна свойств Веб-узла по умолчанию с вкладкой Безопасность каталога щелкните кнопку Сертификат. Запустится Мастер сертификатов веб-сервера.

    Щелкните кнопку Далее. Выберите Создание нового сертификата.

    Щелкните кнопку Далее. Если вы хотите «подать на рассмотрение» файл запроса публичному сертификационному центру, то выберите Подготовить запрос сейчас, чтобы отправить его позднее. В этом случае позднее вам нужно будет установить или присоединить на вашем сервере сертификат, который вы получите от сертификационного центра. А если вы хотите сразу сделать запрос, получить и присоединить сертификат, подав запрос непосредственно в сертификационный центр своего предприятия, то выберите Немедленно отправить запрос в локальную службу сертификации. Сейчас выберите второй вариант.

    Щелкните кнопку Далее. Задайте понятное имя для сертификата (в нашем примере — Веб-узел по умолчанию) и длину в битах, определяющую силу шифровального ключа (512 или 1024 бит).

    Щелкните кнопку Далее. Задайте в вашем сертификате название организации и имя организационной единицы. Затем щелкните кнопку Далее.

    Задайте обычное имя вашего сайта. Если ваш сайт является публичным сайтом Интернета, то используйте полностью квалифицированное DNS-имя сайта. Если сайт используется внутри офисной сети, достаточно указать NetBIOS-имя компьютера. В нашем примере в качестве обычного имени Веб-узла по умолчанию мы используем Win2003s.

    Щелкните кнопку Далее. Укажите город, штат и страну. Используйте официальные названия и не используйте сокращений (за исключением двухбуквенных кодов стран).

    Щелкните кнопку Далее. Укажите имя файла в котором будет сохранен запрос на сертификацию. Можно оставить имя файла созданное мастером по умолчанию.

    Затем щелкните кнопку Далее.


    Подтвердите введенную информацию и щелкните кнопку Далее.

  • После нажатия кнопки Готово мастер закончит свою работу.
  • Как только сертификат сервера будет установлен на вашем web-узле, вы сможете посмотреть информацию о нем, для чего нужно щелкнуть кнопку Просмотр на вкладке Безопасность каталога.

    Для завершения подключения протокола SSL для сайта Веб-узел по умолчанию на сервере Win2003s.test.fio.ru выполните следующие действия:

    • Перейдите на вкладку Веб-узел окна свойств узла Веб-узел по умолчанию и убедитесь, что в качестве порта SSL задан порт 443 (используемый SSL по умолчанию). (При помощи кнопки Дополнительно вы можете сконфигурировать и другие параметры идентификации SSL для сайта)
    • Снова перейдите к странице с вкладкой Безопасность каталога и щелкните кнопку Изменить, находящуюся в области Безопасные подключения. Откроется диалоговое окно Безопасные подключения.
  • Установите флажок Требуется безопасный канал (SSL) и щелкните кнопку ОК, чтобы завершить конфигурирование SSL для сайта Веб-узел по умолчанию (Другие настройки, имеющиеся в этом диалоговом окне, обсуждаются в разделе «Настройка защищенных соединений»). Для применения настроек снова щелкните кнопку ОК.
  • Проверьте защищенные соединения: в Internet Explorer откройте URL http://Win2003s.test.fio.ru. В дереве консоли IIS выберите Веб-узел по умолчанию, щелкните кнопку Действие и выберите Обзор в раскрывающемся меню.
  • Internet Explorer попытается открыть домашнюю страницу http://Win2003s.test.fio.ru, принятую по умолчанию, но в результате появится сообщение «The page must be viewed over a secure channel» («Эта страница должна просматриваться через защищенный канал»). Введите измененный URL — https://Win2003s.test.fio.ru.
  • Может появиться диалоговое окно, сообщающее, что вы сейчас увидите страницы через защищенное соединение.
  • Если окно появится, то щелкните кнопку ОК. Должна открыться домашняя страница Default.htm.
  • Настройка безопасных подключений

    Безопасные подключения можно использовать не только для того, чтобы включить SSL с использованием сертификата сервера, установленного на компьютере с IIS, но и чтобы:

    • Указать, что соединения SSL будут использовать сильное 128-битное шифрование
    • Указать, каким способом следует обрабатывать сертификаты клиентов. Клиентские сертификаты удостоверяют идентичность клиентов и обычно используются дистанционными пользователями, нуждающимися в защищенном доступе к корпоративной внутренней сети через незащищенные соединения Интернета. Вы можете задать игнорирование, принятие или необходимость клиентских сертификатов для соединений SSL.
    • Включить отображение клиентских сертификатов. Эта возможность позволяет администраторам создать отображение между пользовательскими учетными записями Windows Server 2003 и клиентскими сертификатами, благодаря чему пользователи, имеющие соответствующие клиентские сертификаты, смогут автоматически аутентифицироваться и входить в сеть.
    • Включить список доверенных сертификатов. Список доверенных сертификатов — это принятый список сертификационных центров, которые рассматриваются данным web-узлом как надежные. Списки доверенных сертификатов создаются при помощи Мастера списков доверия сертификатов, для запуска которого нужно щелкнуть кнопку Создать в нижней части диалогового окна Безопасные подключения.

    Iis проверка идентификации компьютера

    Обновлен: Ноябрь 2007

    IIS предоставляет несколько схем проверки подлинности, которые можно применять для защиты веб-приложения. Наиболее распространенные сценарии включают использование встроенной проверки подлинности Windows (NTLM) в корпоративной интрасети для определения идентификации пользователей приложения на основе их имени пользователя в Windows или указание одной анонимной идентификации для конкретного приложения. Идентификация Windows, предлагаемая IIS, может затем использоваться для определения, имеет ли веб-приложение доступ к защищенным ресурсам Windows, таким как файл, защищенный с помощью списка управления доступом (ACL), или к сетевым ресурсам, таким как файловый сервер или сервер баз данных. Можно настроить ASP.NET для использования идентификации Windows, предоставляемой IIS, включив олицетворение.

    По умолчанию ASP.NET настраивается для использования режима проверки подлинности Windows , который применяет идентификацию Windows, предоставляемую IIS, к свойству User текущего объекта HttpContext . Это позволяет определить идентификацию, предоставляемую IIS, с помощью свойства User (при использовании анонимной идентификации имя Name пользователя оставляется пустым), но не использовать предлагаемую идентификацию как WindowsIdentity для текущей страницы. Идентификация WindowsIdentity для приложения используется во время определения, имеет ли данное приложение доступ к конкретному файловому или сетевому ресурсу.

    Чтобы настроить ASP.NET для олицетворения идентификации Windows, предлагаемой IIS, как WindowsIdentity для приложения ASP.NET, следует отредактировать файл Web.config этого приложения и установить для атрибута impersonate элемента конфигурации identity значение true , как показано в следующем примере.

    Олицетворение не зависит от режима mode проверки подлинности, настроенного с помощью элемента конфигурации проверка подлинности. Этот элемент проверки подлинности используется для определения свойства User текущего контекста HttpContext . Олицетворение используется для определения идентификации WindowsIdentity приложения ASP.NET.

    В качестве примера далее описывается способ разрешения олицетворения с помощью сценария интрасети. В этом сценарии внутренний корпоративный веб-узел настраивается для отправки сведений сотрудникам. Предполагается однако, что некоторая информация предназначена только для менеджеров. Информация для менеджеров может быть отправлена во вложенную папку информационного узла для сотрудников так, чтобы можно было ограничить к ней доступ. IIS определяет удостоверение пользователя с помощью встроенной службы безопасности Windows (NTLM). В сценарии предполагается:

    На веб-узле установлена операционная система Microsoft Windows NT Server, Windows 2000 Server или Windows Server 2003.

    На веб-сервере установлены службы IIS 6.0.

    Жесткий диск веб-сервера отформатирован с помощью NTFS.

    Все сотрудники, которым нужно предоставить доступ к ограниченному ресурсу, используют Windows.

    Администратор приложения в этом сценарии должен выполнить следующие действия:

    Создать файлы и каталоги, как показано на следующем рисунке:

    Создать группу Windows с именем «Менеджеры» и включить в нее всех пользователей, которые должны иметь доступ к файлу ManagerInfo.aspx.

    С помощью диспетчера IIS отключить в этом приложении анонимную проверку подлинности и включить встроенную проверку подлинности Windows.

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL