В данной лекции описываются следующие основные типы аутентификации IIS.

• Анонимная аутентификация.
• Базовая аутентификация.
• Аналитическая и дополнительная аналитическая аутентификация.
• Интегрированная аутентификация Windows.
• Аутентификация при помощи .NET Passport.

Анонимная аутентификация

Анонимная аутентификация открывает пользователям доступ к веб-сайтам и FTP-сайтам без предоставления имени пользователя и пароля. При доступе клиента к веб- или FTP-сайту IIS использует для аутентификации учетную запись Guest Account (Гостевая учетная запись интернета). Гостевая учетная запись интернета создается в процессе установки IIS и называется IUSR_<имя-компьютера>, где <имя_компьютера> – имя главного компьютера. Использование учетной записи анонимного доступа позволяет указывать, к каким ресурсам осуществляют доступ на данном сервере анонимные пользователи. При установке IIS в группу Guests (Гости) добавляется анонимная учетная запись, поэтому любые ограничения или разрешения для этой группы применимы и к этой учетной записи.

При получении IIS запроса вначале выполняется автоматическая анонимная аутентификация. Если анонимная аутентификация не дает результата, то осуществляется попытка входа пользователя в систему с использованием другого метода. Если другие методы аутентификации недоступны, то IIS передает клиенту сообщение об ошибке HTTP "403 Access Denied" ("403 Доступ запрещен").

Методы входа в систему

Одним из кардинальных изменений в функционировании анонимного доступа является то, что произошла смена метода входа по умолчанию – с INTERACTIVE на NETWORK_CLEARTEXT. Раньше каждой учетной записи пользователя для доступа к IIS требовалось право Log On Locally (Осуществлять локальный вход в систему). Теперь, когда по умолчанию используется NETWORK_CLEARTEXT, этого больше не требуется, что снижает степень уязвимости, связанную с большим числом прав IIS.

В IIS используются четыре основные категории аутентификации.

• INTERACTIVE (Интерактивная).
• BATCH (Пакетная).
• NETWORK (Сетевая).
• SERVICE (Служба).

NETWORK_CLEARTEXT является разновидностью аутентификации NETWORK и используется по умолчанию в базовой аутентификации.

Подаутентификация в IIS

Если вы работали с IIS 5, то, вероятно, заметили, что в IIS 6 отсутствует поддержка автоматической синхронизации паролей. Автоматическая синхронизация паролей позволяла IIS контролировать пароль любой учетной записи, используемой для анонимного доступа. Очевидно, что это являлось угрозой безопасности, поскольку соответствующая динамически подсоединяемая библиотека (IISSUBA.DLL) могла быть использована для изменения пароля любой учетной записи. В IIS 6 такая возможность отключена по умолчанию. Тем не менее, при необходимости ее можно включить, но только в том случае, если учетная запись отвечает следующим критериям:

• рабочий процесс, настроенный для приложения, выполняется как LocalSystem (Локальная система), а не Network Service (Сетевая служба);
• IISSUBA.DLL зарегистрирована как компонент COM (использовать rundll32);
• включен параметр метабазы AnonymuosPasswordSynch.

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

При использовании режима изоляции IIS 5.0 внутрипроцессные приложения будут выполняться как LocalSystem.

Если операционная система Windows 2000 с IIS 5 обновлена до Windows Server 2003 (WS03) с IIS 6, и на веб-сайте IIS 5 включена автоматическая синхронизация паролей, то параметр метабазы AnonymousPasswordSynch будет установлен, однако вручную нужно будет внести два оставшихся изменения.

Базовая аутентификация

Наиболее широко используется базовая аутентификация. Поскольку вся информация представляется и передается в открытом виде, данный метод аутентификации прост для обеспечения несложных программных взаимодействий. Но в этом случае пароли будут раскрыты быстрее, чем вы произнесете: "Угроза безопасности".

Компоненты веб-сервера и FTP-сервера поддерживают базовую аутентификацию. Она работает в IIS следующим образом.

1. Пользователь вводит имя и пароль для аутентификации.
2. Браузер выполняет 64-разрядное кодирование пароля и передает его на сервер.
3. IIS проверяет правильность имени пользователя и пароля и предоставляет доступ к ресурсам.

Довольно просто, не правда ли? Поскольку базовая аутентификация встроена в спецификацию HTTP, большая часть веб-браузеров ее поддерживает, что весьма полезно при работе с браузерами не от Microsoft. Проблему, связанную с передачей пароля в открытом виде, можно обойти, используя протокол защищенных сокетов (SSL) для шифрования всего трафика при передаче через сеть.

Браузеры Internet Explorer версии 2.0 и выше перед использованием базовой аутентификации пытаются выполнить интегрированную аутентификацию Windows.

Маркеры доступа базовой аутентификации

Для входа в систему с использованием базовой аутентификации IIS выполняет кэширование. При входе на сервер Windows создается маркер доступа со всеми идентификаторами SID для всех групп, членом которых является входящее лицо. Данный маркер доступа хранится в кэш-памяти, и IIS использует его при разрешении доступа к объектам; при этом IIS не проводит аутентификацию при каждом обращении пользователя к объекту. Несмотря на повышение производительности IIS, данная функция представляет собой угрозу безопасности, поскольку злоумышленник может получить доступ к маркеру в кэше доступа, перед тем как кэш от него избавится. По умолчанию время жизни (TTL) маркера равно 900 с. Этот риск можно уменьшить следующим образом.

• Не осуществляйте вход в систему посредством базовой аутентификации с учетной записью пользователя, обладающей повышенными правами, особенно администраторскими.
• Уменьшите значение параметра UserTokenTTL в реестре, чтобы маркер доступа быстрее становился недействительным. Установите этот параметр равным 0, чтобы вовсе отключить кэширование маркеров доступа.
• Отсутствие кэширования маркеров доступа вызовет снижение производительности. Необходимо сопоставить этот факт с потребностью в учетных записях Administrator (Администратор) для доступа к серверу.

Учетные записи пользователей и базовая аутентификация

Для использования базовой аутентификации учетная запись пользователя должна быть определена либо на локальном компьютере, либо на доверенном контроллере домена. Контроль доступа, осуществляемый учетной записью, обеспечивается посредством разрешений файловой системы NTFS. Щелкните правой кнопкой на объекте в левой части консоли IIS MMC и выберите команду Properties (Свойства). В области Authentication And Access Control (Аутентификация и контроль доступа) вкладки Directory Security (Безопасность каталога) окна Properties (Свойства) нажмите на кнопку Edit (Изменить). Затем укажите тип используемой аутентификации, а также домен по умолчанию (если компьютер является членом домена). Можно указать и область, но это поле не играет особой роли на сервере, оно лишь отображает указанное значение клиенту при появлении окна входа в систему.

Аналитическая аутентификация

Аналитическая аутентификация доступна в том случае, если осуществляется работа с учетными записями Active Directory. Несмотря на то, что данный метод аутентификации сопряжен с некоторыми угрозами безопасности, он более безопасен, чем базовая аутентификация. Аналитическая аутентификация не является универсальным средством обеспечения безопасности в интернете; она разработана для решения проблем, связанных с базовой аутентификацией. Наряду с Active Directory этому типу аутентификации требуется протокол HTTP 1.1, и он работает только с новыми версиями браузеров, поддерживающими данный протокол.

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

Ниже приведен порядок работы аналитической аутентификации.

• Сервер отправляет клиенту уведомление о том, что для доступа к данному ресурсу необходимо пройти аналитическую аутентификацию.
• Сервер отправляет клиенту некоторую случайным образом сгенерированную информацию для ее включения в аутентификационный хэш. Этот фрагмент информации позволяет предотвратить повторные атаки.
• Клиент добавляет эту информацию в свою комбинацию имени пользователя/пароля и выполняет одностороннее хэширование с помощью алгоритма хэширования MD5.
• Клиент передает хэш на сервер. Также передается сгенерированный сервером фрагмент данных в открытом виде.
• Сервер комбинирует случайные данные с локальной копией комбинации имени/пароля в открытом тексте и выполняет ее одностороннее хэширование с помощью алгоритма хэширования MD5.
• Данный хэш сопоставляется с полученным, и при совпадении проверка подлинности завершается положительным результатом.

Дополнительная аналитическая аутентификация

Дополнительная аналитическая аутентификация работает точно так же, как и обычная, только с одним важным отличием: пароли хранятся на контроллере домена в виде хэша MD5, а не в открытом виде. Это предотвращает возможность выяснения паролей злоумышленником. Дополнительная аналитическая аутентификация поддерживается протоколом HTTP 1.1, поэтому она работает с любым браузером, совместимым с этим протоколом. Дополнительная аналитическая аутентификация обеспечивает больший уровень безопасности по сравнению аналитической .

Для работы дополнительной аналитической аутентификации требуется следующее.

• Функционирует сервер Active Directory.
• И сервер IIS, и контроллер домена используют операционную систему WS03.
• Клиенты работает в веб-браузере IE, по крайней мере, версии 5.
• Учетная запись пользователя находится в домене Active Directory, пользующемся доверием сервера IIS (или того же домена).

Включение дополнительной аналитической аутентификации

Дополнительная аналитическая аутентификация включается в метабазе. Ее можно применить на любом уровне в W3SVC. W3SVC – это имя, присвоенное службе Web Server (Веб-сервер) в метабазе. Данный параметр метабазы является наследуемым всеми дочерними уровнями. Параметром метабазы для дополнительной аналитической аутентификации является UseDigestSSP. Выполните следующие действия.

1. Откройте файл MetaBase.xml в Notepad (Блокнот) (изменение файла будет происходить прямо в процессе работы).
2. Перейдите на уровень, на котором нужно включить дополнительную аналитическую аутентификацию.
3. Введите UseDigestSSP="TRUE" (см. рис. 7.1).

    

   
   
   Рис. 7.1.  Редактирование параметра UseDigestSSP в метабазе

    

    
4. Сохраните и закройте файл.
5. Откройте консоль IIS MMC, затем – окно Authentication Methods (Методы аутентификации) для уровня, на котором нужно включить дополнительную аналитическую аутентификацию. Для этого щелкните правой кнопкой мыши на узле в левой части консоли MMC и выберите команду Properties (Свойства). Затем откройте вкладку Directory Security (Безопасность каталога) и нажмите на кнопку Edit (Изменить).
6. Включите опцию Digest Authentication For Windows Domain Servers (Аналитическая аутентификация серверов доменов Windows).
7. Введите значение в поле Realm (Область) либо нажмите на кнопку Select (Выбрать) для выбора области. Область является важным элементом и должна соответствовать области или домену, на котором будет осуществляться аутентификация клиентов.
8. Нажмите на кнопку OK.
9. Нажмите на кнопку OK еще раз.

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

1. Сервер отправляет клиенту уведомление, что для доступа к данному ресурсу нужно пройти аналитическую аутентификацию (аналитическая и дополнительная аналитическая аутентификации используют один и тот же протокол).
2. Сервер передает имя области.
3. Клиент комбинирует свои имя и пароль с именем области и создает хэш MD5. Затем серверу отправляется запрос на ресурс, причем хэш MD5 передается в заголовке запроса HTTP.
4. Сервер IIS передает этот хэш контроллеру домена для проверки.
5. Контроллер домена сверяет полученный хэш с тем, что хранится в Active Directory. При их совпадении контроллер домена отправляет серверу IIS подтверждение.

Интегрированная аутентификация Windows

Интегрированная аутентификация Windows является наиболее безопасным методом аутентификации, однако она доступна только в Internet Explorer. Этот тип аутентификации раньше был известен как аутентификация NTLM и аутентификация Windows NT вопрос/ответ. При интегрированной аутентификации Windows браузер клиента проверяет сам себя на сервере посредством криптографического обмена данными..

Интегрированная аутентификация Windows поддерживает как протокол Kerberos v5, так и протокол NTLM (NT LAN Manager) для аутентификации посредством пакета Negotiate. При наличии Active Directory и соответствующей поддержке браузером (IE 5 или выше на платформе Windows 2000) используется протокол Kerberos, иначе – протокол NTLM. Как Kerberos, так и NTLM имеют некоторые ограничения. Интересен тот факт, что преимущества одного соответствуют слабым местам другого. Kerberos, как правило, работает с прокси-серверами, но с межсетевыми экранами его функционирование не столь эффективно. NTLM обычно работает через межсетевые экраны, но достаточно посредственно взаимодействует с прокси-серверами.

Несколько слов о Microsoft Negotiate

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

Аутентификация NTLM

NTLM представляет собой расширенную версию старого протокола аутентификации LM (LAN Manager). NTLM работает посредством вопросов/ответов между сервером и клиентом без передачи пароля пользователя через сеть в открытом виде. Клиент должен подтвердить то, что он знает пароль пользователя, посредством отправки зашифрованного хэша.

NTLM функционирует следующим образом.

1. Пользователь указывает имя пользователя, пароль и имя домена при входе на компьютер-клиент.
2. Клиент создает хэш данного пароля и удаляет оригинал.
3. Клиент отправляет серверу имя пользователя в открытом виде.
4. Сервер отправляет клиенту 16-битный фрагмент случайных данных.
5. Клиент шифрует этот фрагмент, а также хэш пароля пользователя и передает их на сервер.
6. Сервер передает имя пользователя, случайный фрагмент данных и ответ клиента на контроллер домена.
7. Контроллер домена шифрует отрезок случайных данных вместе со своим собственным хэшем пароля пользователя, после чего сравнивает их с элементами, присланными сервером.
8. Если значения совпадают, контроллер домена уведомляет сервер об успешном завершении аутентификации.
9. Если значения или имя пользователя не совпадают, контроллер домена уведомляет об этом сервер, который передает клиенту соответствующее сообщение. После этого браузер клиента запрашивает у пользователя аутентификационные данные.

Аутентификация Kerberos

В древнегреческой мифологии Керберос – это сказочная трехглавая собака, охранявшая подземный мир от людей. В настоящее время термином Kerberos называется протокол безопасной аутентификации для доступа к ресурсам. Kerberos основывается на аутентификации с секретным ключом, при которой клиент и сервер используют один и тот же ключ для шифрования и расшифровки. Клиент доказывает знание ключа посредством шифрования сообщения, а сервер доказывает знание ключа посредством расшифровки этого сообщения. Затем сервер берет часть сообщения, шифрует ее и отправляет клиенту. При сохранении целостности сообщения результат аутентификации будет положительным.

Работа Kerberos основывается на центральном сервере, называемом Key Distribution Center (KDC) (Центр распределения ключей), который предоставляет все необходимые ключи. KDC выпускает так называемые билеты TGT (Ticket-Granting Tickets) ("Билеты для получения билетов") и предоставляет их клиентам, запрашивающим доступ к ресурсу на сервере.

Ниже показан процесс получения клиентом начального билета TGT.

1. Пользователь осуществляет вход на компьютер-клиент с указанием имени пользователя и пароля.
2. Клиент шифрует пароль и сохраняет его.
3. Клиент отправляет KDC сообщение с запросом на аутентификационные данные для службы TGT, а также зашифрованный пароль пользователя.
4. KDC сравнивает зашифрованный пароль со своей эталонной копией для проверки их идентичности. Также осуществляется проверка временного штампа, приложенного клиентом к запросу, для подтверждения того, что указанное в штампе время находится в пределах пяти минут собственного времени KDC.
5. В случае полного соответствия KDC создает запрошенные аутентификационные данные для службы TGT посредством генерации сеансового ключа входа и шифрования его на пользовательском ключе.
6. KDC создает другой фрагмент аутентификационных данных посредством шифрования сеансового ключа входа и TGT пользователя своим собственным эталонным ключом.
7. KDC отправляет оба фрагмента аутентификационных данных клиенту.
8. Клиент расшифровывает сеансовый ключ входа из первого отрезка аутентификационных данных с помощью зашифрованного пароля и сохраняет этот сеансовый ключ входа в кэше своего билета.
9. Клиент также сохраняет TGT в своем кэше билета.

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

1. Клиент запрашивает у KDC билет на доступ к ресурсам на сервере. Клиент предоставляет свой TGT центру KDC вместе с именем нужного ресурса и аутентификационным сообщением, зашифрованным на сеансовом ключе входа.
2. KDC расшифровывает TGT с помощью эталонного ключа, извлекает сеансовый ключ входа и использует его для расшифровки аутентификационного сообщения. Если оно совпадает с эталоном, подлинность клиента подтверждается.
3. KDC создает сеансовый ключ службы для клиента, предназначенный для представления серверу при подаче запросов на ресурсы, и шифрует сеансовый ключ службы на сеансовом ключе входа клиента.
4. KDC шифрует сеансовый ключ входа с использование эталонного ключа сервера, в результате чего создается билет.
5. KDC передает клиенту оба фрагмента аутентификационных данных клиенту, который расшифровывает сеансовый ключ с помощью своего сеансового ключа входа и сохраняет сеансовый ключ службы и билет в своем кэше.

Теперь у клиента есть билет, с помощью которого он получает доступ к ресурсам на сервере.

1. Клиент передает серверу сеансовый билет и аутентификационное сообщение, зашифрованное на сеансовом ключе службы.
2. Сервер расшифровывает сеансовый билет и проверяет временной штамп клиента на запросе (значение штампа должно находиться в пятиминутном интервале собственного времени сервера). Затем сервер получает из данного билета сеансовый ключ.
3. Сервер шифрует временной штамп сеансового билета на сеансовом ключе, после чего отправляет его клиенту.
4. Клиент расшифровывает сообщение и сравнивает временной штамп с оригиналом. Если все совпадает, процесс аутентификации считается успешно завершенным.

Это очень сложный процесс, но он обеспечивает подлинность каждого лица, устанавливающего соединение. Очевидно, что KDC играет важную роль в данном процессе, поэтому необходимо обеспечить безопасность центра KDC.

Аутентификация посредством .NET Passport

IIS 6 может использовать паспорт Microsoft .NET Passport для аутентификации пользователей, запрашивающих ресурсы на веб-сайте или в виртуальном каталоге веб-сайта. Преимуществом данного подхода является то, что аутентификационные данные сохраняются и управляются другим сервером, за работу которого пользователь не несет никакой ответственности. Пользователи проходят аутентификацию с помощью службы .NET Passport и затем осуществляют доступ к веб-сайту, расположенному на сервере WS03. Тем не менее, данная служба не обеспечивает контроль доступа или авторизацию сайта. Сервер .NET Passport может лишь подтверждать тот факт, что веб-потребитель, представляющий себя в качестве лица, имеющего профиль на сервере .NET Passport, успешно прошел аутентификацию как лицо, представленное имеющимся профилем.

Система .NET Passport является бесплатной для регистрации и использования. Пользователи интернета входят и выходят из системы на сервере Passport и направляются на нужный веб-сайт после успешного прохождения процедуры аутентификации. Страницы входа и выхода могут иметь дизайн, соответствующий веб-сайту, вход на который осуществляют пользователи.

Паспорт обеспечивает удобную систему аутентификации для всех пользователей, вовлеченных в работу с интернетом, поскольку предоставляет простую процедуру входа на любой веб-сайт, аутентификация на котором осуществляется при помощи .NET Passport. Преимуществом этого подхода является тот факт, что стороне, обеспечивающей работу сайта, не требуется создавать и поддерживать работу своей системы или своего сервера аутентификации, однако за пользование услугами Microsoft .NET Passport ей придется платить определенную сумму. После создания учетной записи в службе .NET Passport нужно создать веб-страницу на сервере, содержащем сайт, обеспечивающую аутентификацию пользователей. Для этого придется затратить не больше усилий, чем для любого "казенного" механизма регистрации и аутентификации, работа которого не зависит от расположения аутентификационных данных зарегистрированных пользователей. Но в данном случае взаимодействие осуществляется только с аутентифицированными пользователями.

Недостаток системы .NET Passport заключается в том, что многие пользователи нерешительно настроены на использования данного способа аутентификации. Сообщество пользователей интернет с опасением относится к предоставлению личных данных службе .NET Passport. Существующие в интернете электронные магазины и порталы без особого энтузиазма воспринимают .NET Passport, поскольку уже имеют собственные системы аутентификации. Преимущества единой системы аутентификации в интернете сводятся к нулю, когда веб-потребителю приходится проходить аутентификацию на других подконтрольных ему сайтах. Без широкого одобрения системы .NET Passport ее применение лишено смысла, так как веб-потребителю невыгодно использовать единую систему аутентификации.

Настройка службы .NET Passport

Перед использованием службы .NET Passport необходимо подготовить соответствующий сайт. Ниже приведена последовательность действий для настройки на работу с сервером .NET Passport.

1. Зарегистрируйтесь на веб-сайте посредством службы .NET Passport. Для начала перейдите по адресу http://www.microsoft.com/net/services/passport/developer.asp. На этой странице вы заполните ряд форм и завершите работу мастера .NET Passport Wizard, предоставив ему информацию о себе и о веб-сайте. В таблице 7.1 приводится необходимая информация.
2. После успешной регистрации сайту присваивается идентификатор и статус разработки. Microsoft пробует скопировать сайт на свой сервер и проверить его.
3. Создайте соответствующий веб-сайт. Microsoft предоставляет пакет разработки .NET Passport для помощи в создании веб-сайта .NET Passport. SDK доступен для бесплатной загрузки с сайта Microsoft по адресу http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp.
4. Запросите проверку веб-сайта на соответствие службой .NET Passport. Если сайт соответствует установленным стандартам, вам придется ознакомиться с соглашением о предоставлении услуг службой .NET Passport.
5. Запустите сайт. Получите ключи шифрования для сайта и разберитесь с кодом, необходимым для обеспечения интеграции с .NET Passport.

Процесс регистрации (шаг 1) является достаточно трудоемким. Потребуется выполнение мастера .NET Passport Wizard. По завершении работы мастера отобразятся веб-страницы, запрашивающие различную информацию (заполнение некоторых является обязательным для завершения процесса). Информация, запрашиваемая в процессе регистрации, приведена в табл. 7.1.

Настройка сайта на работу с системой .NET Passport

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

Для реализации на сайте IIS аутентификации .NET Passport выполните следующие шаги.

1. Откройте оснастку IIS MMC и разверните узел Web Sites (Веб-узлы) в левой части консоли.
2. Щелкните правой кнопкой мыши на соответствующем веб-сайте или виртуальном каталоге, для которого необходимо реализовать аутентификацию .NET Passport. Выберите Properties (Свойства).
3. В окне Properties откройте вкладку Directory Security (Безопасность каталога).
4. Нажмите на кнопку Edit (Изменить), расположенную в области Authentication And Access Control (Аутентификация и контроль доступа). Откроется окно Authentication Methods (Методы аутентификации).
5. В области Authenticated Access (Аутентифицируемый доступ) включите опцию .NET Passport Authentication (Аутентификация .NET Passport). После выбора той опции все остальные методы аутентификации будут недоступны. Тем не менее, вы по-прежнему сможете выбрать анонимный доступ.
6. При необходимости введите имя домена в текстовом поле Default Domain (Домен по умолчанию). Это домен, которому будут принадлежать имена пользователей на главном сервере после прохождения ими аутентификации .NET Passport. Для определения организации или домена при взаимодействии с системой, разработанной другой компанией (не Microsoft) можно задать Realm (Область).
7. Нажмите на кнопку OK для закрытия окна Authentication Methods (Методы аутентификации). Затем нажмите на кнопку OK для закрытия окна Properties (Свойства).

Если служба .NET Passport настроена правильно, то пользователям отобразится запрос .NET Passport (см. рис. 7.2), за тем исключением, что в нем будут указаны настройки, из таблицы 7.1, а не значения по умолчанию, показанные на рисунке 7.2.

Использование нескольких методов аутентификации

При использовании нескольких методов аутентификации, IIS и браузер клиента предпочитают одни схемы аутентификации другим. Применение схем аутентификации осуществляется в следующем порядке.

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

Выполняется интегрированная аутентификация Windows, если она включена и совместима с браузером.

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

Наконец, если не удалось применить ни один из указанных выше методов аутентификации, используется базовая аутентификация.

Обратите внимание, что в данном списке отсутствует аутентификация .NET Passport. Дело в том, что это особый тип аутентификации. Если метод аутентификации .NET Passport включен, то все остальные способы аутентификации недоступны (хотя по-прежнему можно использовать анонимный доступ).