Integrated windows authentication это

Обновлено: 06.07.2024

Интегрированная проверка подлинности Windows ( IWA ) [1] - это термин, связанный спродуктами 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 ) [7], это означает, что лежащие в основе механизмы безопасности должны использоваться в приоритетном порядке. Если провайдер Kerberos функционирует и билет Kerberos может быть получен для цели, и любые связанные параметры разрешают проверку подлинности Kerberos (например, параметры сайтов интрасети в Internet Explorer ), будет предпринята попытка протокола Kerberos 5. В противном случае NTLMSSPвыполняется попытка аутентификации. Точно так же, если попытка проверки подлинности Kerberos не удалась, выполняется попытка NTLMSSP. IWA использует SPNEGO, чтобы позволить инициаторам и получателям согласовывать Kerberos или NTLMSSP. Сторонние утилиты расширили парадигму интегрированной аутентификации Windows на системы UNIX, Linux и Mac.

Некоторые технологии, программные интерфейсы, протоколы и спецификации произведённые в недрах Microsoft.

Это не всё, конечно, даже из этой программистской категории. А есть ещё различные аббревиатуры и названия просто для разных частей Windows и т. п., но то не так интересно.

OLE — технология связывания и внедрения объектов в другие документы и объекты.
OLE Automation — механизм межпроцесорного вхаимодействия, основанный на COM; для использования в скриптовых языках.
aka Automation
ActiveX — ребрэндинг OLE
COM (Component Object Model) — обеспечивает межпроцессорное взаимодействие между объектами написанными на разных языках
COM+ — улучшена поддержка потоков, etc
DCOM — позволяет COM-компонентам взаимодействовать друг с другом по сети
VBX (Visual Basic Extension) — стали ненужны благодаря…
OCX (OLE custom controls) — элементы интерфейса на основе OLE

Ещё пятьсот → CDO (Collaboration Data Objects) — доступ к Global Address List и другим объектам на сервере, в дополнение к содержимому письменных ящиков и папок.
aka OLE Messaging
aka Active Messaging

IWA (Integrated Windows Authentication)
aka NT Authentication
aka NTLM Authentication
aka Domain authentication
aka Windows Integrated Authentication
aka Windows NT Challenge/Response authentication
aka Windows Authentication
NTLM (NT LAN Manager) — протокол сетевой аутентификации
SSPI (Security Support Provider Interface) — API используемый Windows'ами для выполнения разных секурных операций, таких как аутентификация.

Windows Sockets API
LSP (Layered Service Provider, англ. многоуровневый поставщик услуг) — технология Windows sockets версии 2.0, позволяющая пользователю подключать собственные DLL-библиотеки для обработки вызовов Winsock API.
SPI (Service Provider Interface)

AD (Active Directory)
aka NTDS (NT Directory Service)
FSMO (Flexible single master operation) — какая-то фича Active Directory
ADAM (Active Directory Application Mode) — простая имплементация AD
aka AD LDS (Lightweight Directory Services)

Мультимедиа

GDI — работаем с графикой
GDI+ — продолжение
WIC (Windows Imaging Component) — API для работы с изоюражениями.
WCS (Windows Color System) — подсистема и API в Vista для работы с цветом
CITE (Color Infrastructure and Translation Engine)

MF (Media Foundation) — замена для DirectShow, Windows Media SDK, DirectX Media Objects (DMOs) и всех других мультимедийных APIs таких как Audio Compression Manager (ACM) и Video for Windows (VfW).

ASF (Advanced Systems Format) — потоковый аудио- и видео-формат
aka Advanced Streaming Format
aka Active Streaming Format

Active Scripting
ActiveX Scripting
WSH (Windows Script Host) — автоматизация жития в Windows

WDM (Windows Driver Model) — API для написания драйверов
VxD (virtual xxx driver) — предшественник
WDF (Windows Driver Foundation) — API для создания драйверов начиная с Windows 2000
KMDF (Kernel-Mode Driver Framework) — API для создания драйверов в режиме ядра
UMDF (User-Mode Driver Framework) — создаём драйверы для Vista+
WDDM (Windows Display Driver Model) — архитектура для драйверов видеокарт начиная с Vista
aka WVDDM

DLL (Dynamic Link Library)
DDI

FAT
NTFS

MSRPC (Microsoft Remote Procedure Call)

Windows DNA (Windows Distributed interNet Applications Architecture) — общее название для набора технологий, таких как ActiveX, Dynamic HTML (DHTML) и COM. Уже не используется.

MFC — ОО-прослойка над WINAPI
aka AFX (Application Framework Extensions)
WTL (Windows Template Library) — альтернатива MFC из недр Microsoft'а же!
ATL (Active Template Library) — упрощает создание COM-объектов; в некотором роде — более легковесная альтернатива MFC.

MSXML (Microsoft XML Core Services) — создаём родные XML-based Windows-приложения с VBScript, etc

WMI (Windows Management Instrumentation)
WIA (Windows Image Acquisition) — API для работы с периферией
WPD (Windows Portable Devices)

WPF (Windows Presentation Foundation)
aka Avalon
XAML (Extensible Application Markup Language) — язык для описания структуры в WPF
WF (Windows Workflow Foundation) — технология для определения, выполнения и управления рабочими процессами.
WinFX —?

MAPI (Messaging API)
RAPI (Remote Application Programming Interface)
SAPI (Speech Application Programming Interface)
TAPI (Telephony Application Programming Interface)

Базы данных

OLE DB — набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа.

ADOMD (ADO Multi-Dimensional) is to be used with multidimensional data providers such as Microsoft OLAP Provider, also known as Microsoft Analysis Services Provider.
ADOX (ADO Extensions for DDL and Security) enable the creation and modification of definitions of a database, table, index, or stored procedure.
SQLOLEDB (Microsoft OLE DB Provider for SQL Server) supports access to Microsoft SQL Server.
SQLODBC (Microsoft SQL Server ODBC Driver) enables access to Microsoft SQL Server.
MSDASQL (The Microsoft OLE DB Provider for ODBC) is a technology that allows applications that are built on OLEDB and ADO (which uses OLEDB internally) to access data sources through an ODBC driver.
MSDADS (Microsoft OLE DB Provider for Data Shaping) — you can create hierarchical relationships between keys, fields, or rowsets in an application.
JRO (Jet Replication Objects) — used within ADO with Jet (*.mdb) databases to create and compress Jet Databases (.mdb’s) and perform Jet Replication Management.

RDS (Remote Data Services) — technology used in conjunction with ActiveX Data Objects (ADO) that allowed the retrieval of a set of data from a database server, which the client then altered in some way and then sent back to the server for further processing.
aka ADC (Advanced Data Connector)

ESE (Extensible Storage Engine) — реализация ISAM (Индексно-Последовательный Метода Доступа, способ хранения данных для быстрого доступа к ним, by IBM)
aka JET Blue
JET Red
JET (Joint Engine Technology)
aka Microsoft JET Engine
Microsoft Jet Database Engine — database engine on which several Microsoft products were built.

MSDE (Microsoft SQL Server Desktop Engine) — система управления реляционными БД. Урезанная версия Microsoft SQL Server 7.0.
aka Microsoft Data Engine
aka Microsoft Desktop Engine

Изменения для поддержки расширенной защиты будут доступны только для приложений в Windows 7 и Windows Server 2008 R2. Функции расширенной защиты недоступны в более ранних версиях Windows.

Обзор

Механизм расширенной защиты представляет собой улучшение протоколов проверки подлинности, предназначенное для исключения атак на ретрансляторы проверки подлинности. Это улучшение связано с концепцией каналов и сведениями о привязке службы.

Общие цели улучшения таковы.

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

Обновленные серверы, которые правильно настроены, могут проверять сведения о привязке для канала и службы, если эти сведения содержатся в маркере проверки подлинности клиента, и отклонять попытки проверки подлинности, если привязки каналов не совпадают. В зависимости от сценария развертывания серверы могут проверять привязку канала, привязку службы или обе привязки.

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

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

Маркер привязки канала.

Сведения о привязке службы в виде имени субъекта-службы.

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

Значение имени субъекта-службы должно быть доступно на сервере, выполняющем проверку подлинности клиента, в виде открытого текста.

Значение имени субъекта-службы является открытым.

Имя субъекта-службы должно быть криптографически защищено во время передачи, чтобы его было невозможно вставить, удалить или изменить с помощью атаки "человек посередине".

Маркер привязки канала — это свойство внешнего безопасного канала (например, TLS), которое используется для привязки этого канала к обмену данными во внутреннем канале, проверку подлинности которого выполнил клиент. Маркер привязки канала должен иметь следующие свойства (эти свойства также определяются в стандарте RFC 5056, принятом IETF):

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

Злоумышленник не должен иметь возможность повлиять на значение маркера привязки канала.

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

Целостность маркера привязки канала должна быть криптографически защищена во время передачи, чтобы его значение было невозможно вставить, удалить или изменить с помощью атаки "человек посередине".

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

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

Расширенная защита поддерживается в Windows 7. Предоставляется механизм, с помощью которого приложение может определить, поддерживает ли операционная система расширенную защиту.

Изменения для поддержки расширенной защиты

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

Пространство имен System.Security.Authentication.ExtendedProtection обеспечивает поддержку проверки подлинности для приложений с использованием расширенной защиты. Класс ChannelBinding в этом пространстве имен представляет привязку каналов. Класс ExtendedProtectionPolicy в этом пространстве имен представляет политику расширенной защиты, используемую сервером для проверки входящих клиентских подключений. Другие члены класса используются с расширенной защитой.

Для серверных приложений к таким классам относятся следующие:

Класс ExtendedProtectionPolicy, содержащий следующие элементы:

Свойство OSSupportsExtendedProtection, которое указывает, поддерживает ли операционная система встроенную проверку подлинности Windows с расширенной защитой.

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

Значение ProtectionScenario, которое указывает сценарий развертывания. Это влияет на проверку расширенной защиты.

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

Необязательный объект ChannelBinding, содержащий пользовательскую привязку канала, используемую при проверке. Этот сценарий не является наиболее распространенным.

Пространство имен System.Security.Authentication.ExtendedProtection.Configuration обеспечивает поддержку настройки проверки подлинности для приложений с использованием расширенной защиты.

Свойство TargetName в классе SmtpClient, которое представляет имя участника-службы, используемое для проверки подлинности при использовании расширенной защиты для клиентских приложений SMTP.

В класс NegotiateStream добавлены новые перегрузки методов BeginAuthenticateAsClient и AuthenticateAsClient, которые позволяют передавать маркер привязки канала для поддержки расширенной защиты клиентских приложений.

В класс NegotiateStream добавлены новые перегрузки методов BeginAuthenticateAsServer и AuthenticateAsServer, которые позволяют передавать ExtendedProtectionPolicy для поддержки расширенной защиты серверных приложений.

Новое свойство TransportContext в классе SslStream для поддержки расширенной защиты клиентских и серверных приложений.

Расширенная защита для клиентских приложений

Свойство TargetName можно использовать для установки пользовательского имени субъекта-службы, которое будет использоваться во встроенной проверке подлинности Windows для соединения SMTP.

Расширенная защита для серверных приложений

В этой конфигурации при выполнении запроса к серверу с помощью внешнего безопасного канала у внешнего канала запрашивается привязка канала. Эта привязка канала передается вызовам проверки подлинности SSPI, которые проверяют соответствие переданной привязки и привязки канала в BLOB-объекте проверки подлинности. Существует три возможных результата:

Клиент указывает правильную привязку канала или получает возможность подключиться без указания привязки канала, так как политика расширенной защиты на сервере настроена со свойством WhenSupported. Запрос возвращается приложению для обработки. Имена служб не проверяются автоматически. Приложение может выполнить собственную проверку имени службы с помощью свойства ServiceName, но в таких обстоятельствах это действие является избыточным.

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

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

Эти функции расширенной защиты также могут использоваться серверными приложениями для проверки подлинности с другими типами запросов, а также при использовании доверенного прокси.

Интегрированная проверка подлинности 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.

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

После установки роли Client Access в Exchange Server 2010 доступ к Outlook Web App по умолчанию не настроен на прохождение встроенной аутентификации Windows. Если сервера Client Access используются для доступа к OWA внутри локальной сети, то для пользователей будет более удобно использовать SSO вход в свой почтовый ящик через OWA. Что бы штатно включить механизм встроенной проверки аутентификации Windows в консоли Exchange Management Console перейдём в раздел Server Configuration > Client Access, выбираем сервер и в открывшейся закладке Outlook Web App откроем настройки OWA:

На закладке Authentication выберем соответствующий метод аутентификации – Integrated Windows authentication:

При сохранении изменённых настроек мы получим логичное предупреждение о том, что нам так же необходимо изменить способ аутентификации на аналогичный и в настройках Exchange Control Panel (ECP)

Это связано с тем, что при использовании ссылки «Параметры» в веб-интерфейсе OWA присутствуют ссылки на виртуальный каталог ECP. Поэтому в настройках ECP нам нужно выбрать тот же метод аутентификации, что и для OWA – Integrated Windows authentication:

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

В некоторых случаях попытка перезапуска IIS на сервере Client Access может приводить к ошибке:

В данном случае проблема может заключаться в том, что службе не хватает времени, отведённого системой на ответ от службы о том, что она выполнила остановку или запуск (по умолчанию это значение составляет 30 секунд). Для решения этой проблемы предлагается увеличить значение, установленное по умолчанию как минимум вдвое:

В системном реестре находим ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl , создаем в ней параметр DWORD с именем ServicesPipeTimeout и значением 60000 (Десятичное значение)

Обратите внимание на то, что значение параметра указывается в миллисекундах и влияет на запуск всех служб в ОС. Дополнительную информацию по этому вопросу можно найти в статье KB824344 How to debug Windows services

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

Если Client Access сервер входит в массив Client Access Array, то соответствующие изменения потребуется выполнить для всех остальных серверов, являющихся членами этого же массива.

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