Разрешить встроенную проверку подлинности windows

Обновлено: 06.07.2024

Интегрированная проверка подлинности Windows ( IWA ) - это термин, связанный с продуктами Microsoft, который относится к протоколам проверки подлинности SPNEGO , Kerberos и NTLMSSP в отношении функций SSPI, представленных в Microsoft Windows 2000 и включенных в более поздние операционные системы на базе Windows NT . Этот термин чаще используется для автоматически аутентифицируемых соединений между Microsoft Internet Information Services , Internet Explorer и другими приложениями, поддерживающими Active Directory .

СОДЕРЖАНИЕ

Обзор

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

Сама по себе встроенная проверка подлинности Windows не является стандартом или протоколом проверки подлинности. Когда IWA выбран в качестве опции программы (например, на вкладке « Безопасность каталога » диалогового окна свойств сайта IIS ), это означает, что лежащие в основе механизмы безопасности должны использоваться в приоритетном порядке. Если провайдер Kerberos работает и билет Kerberos может быть получен для цели, и любые связанные параметры разрешают проверку подлинности Kerberos (например, параметры сайтов интрасети в Internet Explorer ), будет предпринята попытка использования протокола Kerberos 5. В противном случае выполняется попытка проверки подлинности NTLMSSP . Точно так же, если попытка проверки подлинности Kerberos не удалась, выполняется попытка NTLMSSP. IWA использует SPNEGO, чтобы позволить инициаторам и получателям согласовывать Kerberos или NTLMSSP. Сторонние утилиты расширили парадигму интегрированной аутентификации Windows на системы UNIX, Linux и Mac.

Поддерживаемые веб-браузеры

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

Методы для WWW

Методы для FTP

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

Анонимная проверка подлинности

Анонимная проверка подлинности дает пользователям доступ к общим областям веб- или FTP-узлов без запроса имени пользователя или пароля. Когда пользователь пытается присоединиться к общему веб- или FTP-узлу, веб-сервер назначает пользователю учетную запись IUSR_ИмяКомпьютера, где ИмяКомпьютера — это имя сервера, на котором запущен IIS.

По умолчанию пользователь IUSR_ИмяКомпьютера включается Windows в группу пользователей Guests. Эта группа имеет ограничения по безопасности, налагаемые разрешениями NTFS, которые устанавливают уровень доступа и тип содержимого, доступные обычным пользователям.

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

IIS использует учетную запись IUSR_ИмяКомпьютера следующим образом:

Примечание

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

Учетная запись, используемая для анонимной проверки подлинности, может быть изменена в оснастке IIS на уровне служб веб-сервера или для отдельных виртуальных каталогов и файлов. Учетная запись анонимного пользователя должна давать пользователю права локального подключения. Если учетная запись не имеет разрешения «Локальный вход в систему», IIS не сможет обслуживать никакие анонимные запросы. При установке IIS учетная запись IUSR_ИмяКомпьютера получает разрешение «Локальный вход в систему». В контроллерах домена учетная запись IUSR_ИмяКомпьютера по умолчанию не включена в гостевые учетные записи. Она должна быть изменена (предоставлено разрешение «Локальный вход в систему»), чтобы разрешить анонимные подключения.

Примечание Требования к носителю права локального входа в систему могут быть изменены с помощью Active Directory Service Interfaces (ADSI). Для получения дополнительной информации см. раздел LogonMethod в руководстве по Active Server Pages.

Также можно изменить привилегии для учетной записи IUSR_ИмяКомпьютера в Windows с помощью оснастки-диспетчера групповой политики в MMC. Однако если учетная запись анонимного пользователя не дает права доступа к определенному файлу или ресурсу, веб-сервер не установит анонимное соединение с этим ресурсом. Дополнительные сведения см. в разделе Задание разрешений для веб-сервера.

Обычная проверка подлинности

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

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

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

Примечание Встроенная проверка подлинности имеет приоритет перед обычной проверкой подлинности. Обозреватель выберет встроенную проверку подлинности Windows и будет пытаться использовать текущую учетную информацию Windows перед тем, как запросить имя пользователя и пароль. В настоящий момент только Internet Explorer версии 2.0 и более поздней поддерживает встроенную проверку подлинности.

Краткая проверка подлинности

Краткая проверка подлинности проходит следующим образом:

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

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

Важно! Краткая проверка подлинности будет завершена, если только сервер домена, к которому был сделан запрос, имеет пароль пользователя в виде неформатированного текста. Поскольку контроллер домена имеет копии паролей в виде неформатированного текста, он должен быть защищен от физической и сетевой атак. Для получения более подробной информации о защите контроллера домена см. пакет Microsoft Windows 2000 Server Resource Kit.

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

Встроенная проверка подлинности

Встроенная проверка подлинности (раньше называвшаяся NTLM или проверка подлинности «запрос/ответ») является безопасной формой проверки подлинности, поскольку имя пользователя и пароль не передаются по сети. При включенной встроенной проверке подлинности обозреватель на компьютере пользователя доказывает знание пароля через криптографический обмен с веб-сервером, используя хэширование.

Встроенная проверка подлинности может использовать протокол проверки подлинности Kerberos v5 или собственный протокол проверки подлинности «запрос/ответ». Если Служба Каталогов установлена на сервере, а обозреватель совместим с протоколом проверки подлинности Kerberos v5, используются и протокол Kerberos v5, и протокол «запрос/ответ». В противном случае используется протокол «запрос/ответ».

Протокол проверки подлинности Kerberos v5 является возможностью архитектуры Windows 2000 Distributed Services. Чтобы проверка подлинности по протоколу Kerberos v5 была успешной, компьютеры и клиента, и сервера должны иметь надежное соединение с Key Distribution Center (KDC) и быть совместимыми со Службой Каталогов. Для получения информации о протоколе см. документацию по Windows.

Встроенная проверка подлинности проходит следующим образом:

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

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

Следовательно, встроенная проверка подлинности Windows лучше всего подходит для внутренних сетей предприятия, в которых компьютеры пользователя и веб-сервера находятся в одном домене и администратор может проверить использование на каждом компьютере Microsoft Internet Explorer версии 2.0 или более поздней.

Проверка подлинности по сертификату

Для двух типов проверки подлинности можно также использовать возможности защиты по протоколу SSL (Secure Sockets Layer) для веб-сервера. Можно использовать сертификат сервера для выполнения пользователями проверки подлинности сервера до передачи персональной информации, например номера кредитной карты. Также можно использовать сертификаты клиентов для проверки подлинности пользователей, запрашивающих информацию с веб-узла. SSL проверяет подлинность по содержимому зашифрованного цифрового идентификатора, который отправляется веб-обозревателем пользователя в процессе входа в систему. (Пользователи получают сертификаты клиента от независимой организации, доверенной для обеих сторон.) Сертификаты сервера обычно содержат сведения о компании и об организации, выдавшей сертификат. Сертификаты клиентов обычно содержат подробные сведения о пользователе и об организации, выдавшей сертификат. Дополнительные сведения см. в разделе О сертификатах.

Сопоставление сертификатов клиента

Можно связать, или сопоставить, сертификаты клиента и учетные записи пользователя Windows на веб-сервере. После создания и включения сопоставления при каждом входе пользователя с клиентским сертификатом веб-сервер автоматически сопоставляет этого пользователя с соответствующей учетной записью Windows. Таким образом можно автоматически проверять подлинность пользователей, входящих в систему с сертификатами клиента, не требуя основной, краткой или встроенной проверки подлинности. Можно или сопоставить один сертификат клиента одной учетной записи пользователя Windows, или несколько сертификатов — одной учетной записи. Например, если на сервере присутствует несколько подразделений, каждое на своем веб-узле, можно использовать сопоставление «многие-к-одному» для установления соответствия сертификатов клиента каждого подразделения соответствующему веб-узлу. В этом случае каждый узел обеспечивает доступ только для своих клиентов. Дополнительные сведения см. в разделе Сопоставление клиентских сертификатов учетным записям пользователей.

Проверка подлинности для FTP

Анонимная проверка подлинности для FTP

Обычная проверка подлинности для FTP

22.01.2018

Active Directory, Разное

Комментариев пока нет

В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.

Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:

Настройка Kerberos аутентификации в Internet Explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Напомним, что с января 2016 года, единственная официально поддерживаемая версия Internet Explorer – это IE11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

Добавить сайты в эту зону можно с помощью групповой политики: Computer Configuration ->Administrative Templates ->Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment. Для каждого веб-сайта нужно добавить запись со значением 1. Пример смотри в статье об отключении предупреждения системы безопасности для загруженных из интернета файлов

Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).

Важно. Убедитесь, что веб сайты, для которых включена поддержка Kerberos аутентификации приустают только в зоне Местная интрасеть. Для сайтов, включенных в зону Надежные сайты (Trusted sites), токен Kerberos не отправляется на соответствующий веб-сервер.

Включаем Kerberos аутентификацию в Google Chrome

Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” --auth-server-whitelist="*.winitpro.ru" --auth-negotiate-delegate-whitelist="*.winitpro.ru"

Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLM\SOFTWARE\Policies\Google\Chrome).

Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).

Настройка Kerberos аутентификации в Mozilla Firefox

По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.

network.negotiate-auth.trusted-uris
network.automatic-ntlm-auth.trusted-uris

Для удобства, можно отключить обязательное указание FQDN адреса в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn

Проверить, что ваш браузер работает через аутентифицировался на сервере с помощью Kerberos можно с помощью Fiddler или команды klist tickets.

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

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

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

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: "Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя"

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 - именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

Заменить значение свойства "Пользователь" пользователя информационной базы согласно следующему формату "\\" + [Имя пользователя из свойства DstUserName2 без скобок].

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

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

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

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

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

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено "Доверять компьютеру делегирование любых служб (только Kerberos)"

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение "Доверять компьютеру делегирование любых служб (только Kerberos)" и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

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