Настройка sso windows server 2019

Обновлено: 07.07.2024

На сервере приложений должны быть установлены Oracle Java 1.8 , T omcat 8 и сконфигурированы в соответствии в типовой инструкции настройки внешних приложений и компонент Руководства администратора СМ 4.6

Где cts 4. intrtrust . ru - это хост сервера приложений Tomcat

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

Должно вернуть записи вида

1. НЕ включать URIEncoding="UTF-8" для protocol="AJP/1.3". отваливаются справочники "Тематика" и "Вид документа" (ВнД РКК)

2. для Tomcat 8.0.0 … до 8.0.20 - стандартные настройки коннектора AJP/1.3 заменить на

4. Установка библиотек для поддержки русских имен пользователей (в поле user name)

Распаковать из cmjrest.war файла или извлечь из папки <tomcat>/ WEB - INF / lib в <tomcat>/endorsed

файлы с именем :
icu4j-50.1.1-RELEASE.jar
icu4j-charset-50.1.1-RELEASE.jar

ВАЖНО. Если библиотеки уже присутствуют по пути <tomcat>/endorsed, необходимо проверить, что бы размер данных библиотек, совпадал с размером библиотек в архиве cmjrest.war (cmjrest- VERSION \WEB-INF\lib), если размер не совпадает, необходимо очистить каталог <tomcat>/endorsed и вложить туда библиотеки заново. В противном случае аутентификация пользователя с русским именем проходить не будет.

Настройка файла cmj . properties

В настройках cmj . properties добавить секцию

Подробное описание параметров аутентификации в cmj.properties:

формат записи данных

имя заголовка, в котором размещается имя пользователя

вывод более подробной информации о процессе соединения

url-адрес, где находится Domino/Ldap-сервис (резерв.)

"база" для поиска в LDAP. может быть пустой

Distinguished-имя (логин), под которым tomcat-будет устанавливать соединение с Domino

пароль для userDn

использовать пул соединений. повышает производительность

Настройка задачи LDAP

1. В документе "Configuration Settings" для всех серверов (*) на вкладке LDAP включить настройку

DN Required on Bind?

(отвечает за формат привязки к LDAP, разрешает использование формата cn=username)

2. Проверить с помощью команды ldapsearch поиск из LDAP Domino. Поиск должен возвращать все учетные записи пользователей Domino:
C:\Lotus\Notes>ldapsearch.exe -h 169.254.52.1 -D "cn=ldapuser,o=intertrust" -w "password456" -b "o=Intertrust" "(cn=*)"

1. Отключить настройку в док-те сервера load configuration from internet sites

3. Создать конфигурацию SSO для сервер-док-та аналогично скриншоту

Configuration Name: произвольно

Organization: не заполнять

DNS Domain: .abc.local

Domino Server Names: CMT01/ABC

Windows single sign-on integration : Enabled

$C:\bad37905d522370ef22fe7c403fb4176$

4. Создать ключи SSO для созданной конфигурации: нажать кнопку «Create WebSSO keys»

5. Настроить вкладку Domino Web Engine аналогично рис. (Session Authentication: Multiple Servers)

6. Выбрать полученный документ LTPA Token в п Web SSO Configuration

7. (Проверить, создалась ли настройка LTPA Token можно в АК Domino, вид $WebSSOConfig)

$C:\a57e224607f418870bb94a6ce58a3442$

8. В АК Domino, в персоне пользователей на вкладке administration, в параметре Active Directory (Kerberos) logon name: указывается доменное имя пользователя системе в формате user@DOMAIN, где «DOMAIN» - NetBIOS domain name и именно прописными

Установка IIS

1. IIS – встроен в Windows, для его установки необходимо перейти в Панель управления -- Включение или отключение компонентов Windows

2. В Мастере добавления ролей и компонентов, на вкладке "роли", добавляем Роль "Веб-сервер( IIS )" и компонент . NET 4.5

3. На вкладке "Роль веб сервера IIS "--"Службы ролей"

- в разделе Общие функции HTTP выставляем все галки кроме "Перенаправление WebDAV "

- в разделе Исправность и Диагностика выставляем галки "Ведение журнала HTTP ", "Монитор запросов", "Средства ведения журнала"

- в разделе Производительность выставляем галку "Сжатие статического содержимого"

- в разделе Безопасность выставляем галки "Фильтрация запросов", "Дайджест-проверка подлинности", "Обычная проверка подлинности", "Проверка подлинности Windows "

- в разделе Разработка приложений выставляем галки " фильтрация .net 3.5", " фильтрация .net 4.5", "asp", "asp.net 3.5", "asp.net 4.5", " Расширения ISAPI", " Фильтры ISAPI"

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

4. Выполнить W indows U pdate установив все критичные и важные исправления

Настройка Tomcat ISAPI redirector for Microsoft IIS

1. Создаем на диске C сервера IIS папку IIS-site2

2. Распаковываем приложенный к инструкции архив

3. Переносим содержимое папки site2 в созданный каталог C:\IIS-site2

4. Для хранения настроек используется isapi_redirect.properties файл раположенный в каталоге isapi-redirector. Необходимо открыть его и проверить соответвие путей к указанным в нем файлам настроек.

5. Редирект приложений из tomcat в cmj сделан для случаев, если приложения называются «/examples», «/cmjrest», «/cmj-web». Настраиваются в uriworkermap.properties. Дефолтный конфигурационный файл не меняется

Настройка IIS

Переход в диспетчер служб IIS

1. Открываем диспетчер Серверов

2. В навигации слева переходим в раздел IIS

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

Корневая настройка IIS

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

2. В корневой настройке открываем раздел "Делегирование Компонента" и все настройки делегирования компонентов приводим в соответствие с указанными на скриншоте

3. В корневой настройке, переходим в раздел Ограничения ISAPI и CGI. Добавляем описание, кликаем правой кнопкой мыши. Название - Tomcat , путь указываем до isapi_redirect.dll, ставим галку "разрешить выполнение пути расширения"

4. Если работа с приложением будет вестись по https , необходимо сформировать с помощью OpenSSL или получить от заказчика выпущенный их центром сертификации сертификат для хоста сервера IIS в формате pfx и импортировать его в IIS . Для этого в корневой настройке, переходим Сертификаты сервера, кликаем правой кнопкой в разделе, нажимаем "импортировать". В появившемся окне указываем путь до сертификата в формате pfx , при необходимости пароль сертификата. Хранилище сертификата - Размещение веб-служб

Создание Сайта IIS

1. Создаем новый виртуальный сайт. В оснастке кликаем правой кнопкой по папке с сайтами, нажимаем добавить веб-сайт

2. Заполняем настройки сайта.

- имя сайта - по названию хоста IIS

- физический путь - C:\IIS-site2

3. Настраиваем аутентификацию сайта. Открываем настройки "Проверка подлинности" и выставляем следующие настройки

- Анонимная проверка подлинности - выключить

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

- Проверка подлинности Windows - включить

4. Включаем ISAPI - dll . Переходим в настройку Сопоставления обработчиков, нажимаем правой кнопкой по обработчику ISAPI - dll - изменить разрешение функций. Ставим чекбокс "Выполнение"

6. Создаем виртуальный каталог сайта. Правой кнопкой кликаем по нашему сайту, нажимаем "добавить виртуальный каталог".

Псевдоним указываем - jakarta

Физический путь - путь до каталога хранения isapi_redirect.dll

7 . Создаем фильтр ISAPI . Переходим в настройку Фильтры ISAPI . правой кнопкой мыши создаем настройку (Добавить).

имя фильтра - tomcat

исполняемый файл - isapi_redirect.dll

8 . Перезапускаем IIS

Проверка работоспособности

1. В tomcat установить jsp-приложение info.jsp (из приложенного архива), для этого необходимо info.jsp перенести по пути CATALINA _ HOME \ webapps \ examples \ jsp \.

2. Перезапускаем Tomcat

4. Должна появиться форма

5. При переходе по всем из 3х ссылок не должно возвращаться ошибок запросов, примеры возвращаемых данных, при переходе по ссылкам

must be shown "asp checked"

asp-f2.aspx. F2. show user identity and headers

F3. show headers in tomcat examples/jsp/info.jsp

Here are the request headers and their data:
connection:
Keep-Alive

accept:
application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Encoding:
gzip, deflate

decode param 'X-Remote-User'

Настройка браузеров Internet Explorer, Google Chrome

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

1. Cервис/свойства обозревателя/безопасность/"местная интрасеть"

3. Нажать другой: проверка подлинности пользователя/вход выбрать "автоматический вход в сеть только в зоне интрасети"

site-2.24jul2017.rar - Архив с необходимыми для установки и настройки конфигурационными файлами и библиотеками

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

В связи с этим, для упрощения работы с удаленным рабочим столом в Windows Server 2008 появилась возможность использования технологии прозрачной авторизации Single Sign-on (SSO). Благодаря ей пользователь при входе на терминальный сервер может использовать учетные данные, введенные им при логине на свой локальный компьютер, с которого происходит запуск клиента удаленного рабочего стола.

В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей. Также освещен ряд практических вопросов связанных с прозрачной авторизацией для служб удаленных рабочих столов.

Теоретическая информация

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

Впервые механизмы прозрачной авторизации появились в Windows Server 2008 и Windows Vista. благодаря новому поставщику услуг безопасности CredSSP. С его помощью кэшированные учетные данные передавались через безопасный канал (используя Transport Layer Security (TLS)). Впоследствии Microsoft выпустила соответствующие обновления для Windows XP SP3.

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

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

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

Процесс аутентификации происходит по следующему алгоритму:

Клиент инициирует установку безопасного канал с сервером, используя TLS. Сервер передает ему свой сертификат, содержащий имя, удостоверяющий центр и публичный ключ. Сертификат сервера может быть самоподписанным.
Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).
Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.
Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Добавить значение tspkg к ключу Security Packages (остальные значения этого ключа следует оставить неизменными).

3. Перейти в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.

4. Добавить значение credssp.dll к ключу SecurityProviders (остальные значения этого ключа следует оставить неизменными).

После того как CredSSP включен, необходимо настроить его использование с помощью групповых политик или соответствующих им ключей реестра. Для настройки SSO на клиентских компьютерах используются групповые политики из раздела:

Computer Configuration\Administrative Templates\System\Credentials Delegation.

В русскоязычных версиях операционных систем это выглядит следующим образом (рис. 1).

Рис. 1. Управление передачей учетных данных при помощи групповых политик

Для использования SSO следует включить политику:

Разрешить передачу учетных данных, установленных по умолчанию.

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

В окне редактирования политики (рис. 2) нажать кнопку «Показать»

Рис. 2. Окно редактирования групповой политики

Добавить список терминальных серверов (рис. 3).

Рис. 3. Добавление терминального сервера для прозрачной авторизации

Строка добавления сервера имеет следующий формат:

TERMSRV/имя_сервера.

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

TERMSRV/*.имя_домена.

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

Windows Registry Editor Version 5.00

«Security Packages»=hex (7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

«SecurityProviders»="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

Для использования технологии Single Sign-On на терминальном сервере необходимо выполнить следующие действия.

Открыть консоль настройки служб терминалов (tsconfig.msc).
В разделе подключения перейти в свойства RDP-Tcp.
На вкладке «Общие» установить уровень безопасности «Согласование» или «SSL (TLS 1.0)» (рис. 4).

Рис. 4. Настройка уровня безопасности на терминальном сервере

На этом настройку клиентской и серверной части можно считать законченной.

Практическая информация

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

Технология Single Sign-On работает только при соединении с компьютеров под управлением операционной системы не Windows XP SP3 и более старших версий. В качестве терминального сервера могут быть использованы компьютеры с операционной системой Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2.
Если терминальный сервер, к которому устанавливается соединение, не может быть аутентифицирован через Kerberos или SSL-сертификат, SSO работать не будет. Это ограничение можно обойти с помощью политики:
Разрешить делегирование учетных данных, установленных по умолчанию с проверкой подлинности сервера «толькоNTLM».
Алгоритм включения и настройки данной групповой политики аналогичен представленному выше. Файл реестра, соответствующей данной настройке имеет следующий вид.

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

Если для какого-либо сервера сохранены учетные данные в настройках терминального клиента, то они имеют более высокий приоритет, чем текущие учетные данные.
Single Sign-On работает только при использовании доменных аккаунтов.
Если подключение к терминальному серверу идет через TS Gateway, в некоторых случаях возможен приоритет настроек сервера TS Gateway над настройками SSO терминального клиента.
Если терминальный сервер настроен каждый раз запрашивать учетные данные пользователей, SSO работать не будет.
Технология прозрачной авторизации работает только с паролями. В случае использования смарт-карт, она работать не будет.

В некоторых случаях возможна ситуация когда на одном и том же терминальном клиенте технология прозрачной авторизации может работать или не работать в зависимости от профиля подключающегося пользователя. Проблема решается пересозданием профиля пользователя. Если это является слишком трудоемкой задачей можно попробовать воспользоваться советами из обсуждения: «RemoteApp Single Sign On (SSO) from a Windows 7 client» форумов Microsoft Technet. В частности, рекомендуется сбросить настройки Internet Explorer или одобрить соответствующую надстройку для него.

Еще одним серьезным ограничением технологии SSO является то, что она не работает при запуске опубликованных приложений через TS Web Access. При этом пользователь вынужден дважды вводить учетные данные: при входе на веб-интерфейс и при авторизации на терминальном сервере.

В Windows Server 2008 R2 ситуация изменилась в лучшую сторону. Более подробную информацию об этом можно получить в статье: «Introducing Web Single Sign-On for RemoteApp and Desktop Connections"».

Заключение

В статье рассмотрена технология прозрачной авторизации на терминальных серверах Single Sign-On. Её использование позволяет сократить время, затрачиваемое пользователем для входа на терминальный сервер и запуск удаленных приложений. Кроме того, с её помощью достаточно единожды вводить учетные данные при входе на локальный компьютер и затем использовать их при соединении с терминальными серверами домена. Механизм передачи учетных данных достаточно безопасен, а настройка серверной и клиентской части предельно проста.

В этой статье разъясняются требования к Sign-On единого доступа (SSO) к локальному домену через Wi-Fi или VPN-соединения. Обычно используются следующие сценарии:

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

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

Учетные данные, используемые для проверки подлинности подключения, помещаются в Диспетчер учетных данных в качестве учетных данных по умолчанию для сеанса logon. Диспетчер учетных данных хранит учетные данные, которые можно использовать для определенных ресурсов домена. Они основаны на целевом имени ресурса:

Для VPN стек VPN сохраняет учетные данные как по умолчанию сеанса.
Для Wi-Fi поддерживается extensible Authentication Protocol (EAP).

Учетные данные размещаются в диспетчере учетных данных в качестве учетных данных "*Session". Учетные данные "*Session" предполагают, что он действителен для текущего сеанса пользователя. Учетные данные также очищаются при отключении подключения к Wi-Fi или VPN.

Например, если Microsoft Edge пытается получить доступ к ресурсу домена, Microsoft Edge имеет право Enterprise проверки подлинности. Это позволяет WinInet освободить учетные данные, которые он получает от диспетчера учетных данных к запрашиваемой службе SSP. Дополнительные сведения о возможностях Enterprise проверки подлинности см. в декларациях о возможностях приложения.

Местный орган безопасности будет смотреть на приложение устройства, чтобы определить, имеет ли оно нужные возможности. Это включает такие элементы, как универсальное приложение Windows платформы (UWP). Если приложение не является UWP, это не имеет значения. Но если приложение является приложением UWP, оно будет оцениваться по возможностям устройства для Enterprise проверки подлинности. Если у него есть такие возможности и если ресурс, к который вы пытаетесь получить доступ, находится в зоне Интрасети в Internet Options (ZoneMap), то учетные данные будут освобождены. Это поведение помогает предотвратить неправильное использование учетных данных сторонними лицами.

Зона Интрасети

Настройка ZoneMap

Политика MDM

./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-27 81/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/ /* в качестве значения 1 для каждого из доменов, которые вы хотите в SSO с вашего <domain name> устройства. Это добавляет указанные домены в зону Интрасети Microsoft Edge браузера.

Требования к учетным данным

Для VPN после проверки подлинности в диспетчер учетных данных будут добавлены следующие типы учетных данных:

Имя пользователя и пароль

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

Сертификат поставщика служба хранилища ключа TPM
Сертификаты поставщика служба хранилища программного обеспечения (KSP)
Сертификат смарт-карты
Windows Hello для сертификата бизнеса

Имя пользователя также должно включать домен, который можно получить по подключению (VPN или WiFi).

Шаблоны сертификатов пользователей

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

Элемент Template	Конфигурация
SubjectName	Отличительное имя пользователя (DN), в котором компоненты домена отличимого имени отражают внутреннее пространство имен DNS, когда SubjectAlternativeName не имеет полностью квалифицированного upN, необходимого для поиска контроллера домена. Это требование актуально в многолесных средах, так как обеспечивает местонахождение контроллера домена.
SubjectAlternativeName	Полностью квалифицированный upN пользователя, в котором компонент доменного имени пользователя upN совпадает с пространством имен DNS внутреннего домена организаций. Это требование актуально в многолесных средах, так как гарантирует, что контроллер домена может быть расположен, если в SubjectName не требуется DN для поиска контроллера домена.
Поставщик служба хранилища ключей (KSP)	Если устройство присоединяется к Azure AD, используется дискретный сертификат SSO.
EnhancedKeyUsage	Требуется один или несколько следующих EKUs: - Проверка подлинности клиента (для VPN) - EAP Filtering OID (для Windows Hello для бизнеса) - SmartCardLogon (для устройств, присоединив Azure AD) Если контроллерам домена требуется EKU смарт-карты: - SmartCardLogon - id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) В противном случае: - Проверка подлинности клиентов TLS/SSL (1.3.6.1.5.5.7.3.2)

Конфигурация сервера NDES

Сервер NDES необходимо настроить таким образом, чтобы входящие запросы SCEP можно было сопопооставить с нужным шаблоном, который будет использоваться. Дополнительные сведения см. в справке Настройка инфраструктуры сертификатов для SCEP.

Требования Active Directory

Необходимо подключение IP к DNS-серверу и контроллеру домена через сетевой интерфейс, чтобы проверка подлинности также была успешной.

Контроллеры домена должны иметь соответствующие сертификаты KDC, чтобы клиент доверял им в качестве контроллеров домена. Так как телефоны не соединены с доменом, корневой ЦС сертификата KDC должен быть в сторонней корневой ЦС или магазине доверенных корневых корней смарт-карт.

Контроллеры домена должны использовать сертификаты на основе обновленного шаблона сертификата KDC Kerberos Authentication. Это требует, чтобы все контроллеры проверки подлинности домена Windows Server 2016, или вам необходимо включить строгую проверку KDC на контроллерах домена, которые запускают предыдущие версии Windows Server.

Дополнительные сведения см. в дополнительных сведениях о включаемой строгой проверке KDC в Windows Kerberos.

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

Однако данный способ имеет несколько существенных недостатков.

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

Теоретическая информация

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

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

для SSO, сохраняя учетные данные пользователя и передавая их на терминальный.

Процесс аутентификации происходит по следующему алгоритму.

Клиент инициирует установку безопасного канал с сервером, используя TLS. Сервер передает ему свой сертификат, содержащий имя, удостоверяющий центр и публичный ключ. Сертификат сервера может быть самоподписанным.
Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).
Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.
Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 ». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

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