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

Иллюстрированный самоучитель по развертыванию виртуальных частных сетей

Протоколы проверки подлинности

Windows 2000 поддерживает множество протоколов для проверки подлинности пользователей, пытающихся установить PPP-подключение, включающие в себя:

  • Протокол PAP (Password Authentication Protocol – Незашифрованный пароль)
  • Протокол CHAP (Challenge-Handshake Authentication Protocol – Шифрованная проверка подлинности)
  • Протокол MS-CHAP (Microsoft Challenge Handshake Authentication Protocol – Шифрованная проверка подлинности Microsoft)
  • Протокол MS-CHAP v2 (Шифрованная проверка подлинности Microsoft, версия 2)
  • Протокол EAP-MD5 (Extensible Authentication Protocol-Message Digest 5 – Протокол расширенной проверки подлинности по методу MD5-Challenge)
  • Протокол EAP-TLS (Extensible Authentication Protocol-Transport Level Protocol – Расширенный протокол проверки подлинности на основе сертификата)

Для PPTP-подключений Вы должны использовать протоколы MS-CHAP, MS-CHAP v2 или EAP-TLS. Только эти три протокола проверки подлинности предоставляют механизм создания одинаковых ключей шифрования как на VPN-клиенте, так и на VPN-сервере. Шифрование MPPE использует этот ключ для шифрования всех данных, передаваемых по протоколу PPTP через VPN-подключение. Протоколы MS-CHAP и MS-CHAP v2 являются протоколами проверки подлинности с использованием паролей.

При отсутствии сертификатов пользователя или смарт-карт настоятельно рекомендуется использовать протокол MS-CHAP v2, поскольку он обеспечивает лучшую безопасность по сравнению с протоколом MS-CHAP, а также обеспечивает взаимную проверку подлинности (VPN-сервер выполняет проверку подлинности VPN-клиента и наоборот).

Примечание
Если Вы используете протокол проверки подлинности на основе пароля, настройте использование в Вашей сети только надежных паролей. Надежными являются длинные (более 8 знаков) пароли, содержащие случайный набор символов в верхнем и нижнем регистрах, цифр и спецсимволов. Пример надежного пароля: «f3L*q02

>xR3w#4o». При наличии домена Active Directory примените параметры групповой политики, чтобы задать обязательное использование стойких паролей

.

Протокол EAP-TLS разработан для использования совместно с инфраструктурой сертификата, сертификатами пользователя или смарт-картами. При использовании протокола EAP-TLS для проверки подлинности VPN-клиент отправляет свой сертификат пользователя, а VPN-сервер – сертификат компьютера. Это наиболее надежный метод проверки подлинности, поскольку он не использует пароли.

Примечание
Вы можете использовать сторонние центры сертификации до тех пор, пока в сертификат, находящийся в хранилище компьютера сервера проверки подлинности в Интернете (Internet Authentication Service, IAS), содержит цель (также известную как Enhanced Key Usage, EKU – использование расширенного ключа или политика выдачи сертификатов (certificate issuance policy)) «Проверка подлинности сервера». Цель сертификата определяется идентификатором объекта (object identifier, OID). OID для сертификата, используемого для проверки подлинности сервера имеет значение «1.3.6.1.5.5.7.3.1». В дополнение к этому условию сертификат пользователя, установленный на клиент удаленного доступа Windows 2000, должен содержать цель «Проверка подлинности клиента» (OID «1.3.6.1.5.5.7.3.2»)
.

Для L2TP/IPSec-подключений может использоваться любой протокол проверки подлинности, потому что проверка подлинности происходит после создания защищенного канала между VPN-клиентом и VPN-сервером известное также, как сопоставление безопасности IPSec (IPSec security association, SA). Тем не менее, рекомендуется использовать протоколы MS-CHAP v2 или EAP-TLS, как предоставляющие наиболее надежную проверку подлинности пользователей.

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

При выборе протокола проверки подлинности для VPN-подключений обратите внимание на следующие моменты:

  • При использовании смарт-карт или наличии инфраструктуры сертификатов, выдающей сертификаты пользователей, используйте протокол проверки подлинности EAP-TLS как для PPTP-, так и для L2TP-подключений. EAP-TLS поддерживается только клиентами ОС Windows XP и Windows 2000.
  • Если необходимо использовать протокол проверки подлинности на основе паролей, используйте MS-CHAP v2 и задайте обязательное использование надежных паролей при помощи групповой политики. MS-CHAP v2 поддерживается компьютерами, работающими под управлением Windows XP, Windows 2000, Windows NT 4.0 с установленным пакетом обновлений 4 (SP4) или более поздним, Windows ME, Windows 98, и Windows 95 с установленным Windows обновлением Dial-Up Networking 1.3 или более поздними обновлениями производительности и безопасности.

Ошибка 691 и код события 13 при подключении VPN

Ошибка 691 и код события 13 при подключении VPN

Добрый день уважаемые читатели и гости блога, продолжаем наше с вами изучение сетевых технологий на базе операционной системы Windows Server 2012 R2, сегодня я хочу пополнить нашу с вами копилку знаний относительно всевозможных ошибок подключения к VPN серверу, и сегодня вы узнаете причины появления ошибки 691 и код события 13 в журнале NPS. Давайте смотреть как все это дело решается и диагностируется.

Что означает ошибка 691

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

Причины ошибки

Давайте рассмотрим основные причины появления данной проблемы:

  • Если мы говорим про подключение к интернет провайдеру, чтобы через это подключение, то убедитесь, что у вас нет за должности по счету
  • Правильность вводимых данных
  • Не правильные настройки в VPN соединении
  • Блокировка со стороны антивирусного продукта или на вашем фаэрволе (роутере)
  • Ошибки на стороне сервера

Давайте разберем теперь все поподробнее по каждой из причин.

Как исправить ошибку 691

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

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

  1. Адрес сервера
  2. Протокол подключения
  3. Метод аутентификации
  4. Порты

Затем зайдите в свойства своего сетевого подключения, для этого нажмите Win+r и в окне выполнить напишите ncpa.cpl

В итоге у вас откроется окно «Панель управленияВсе элементы панели управленияЦентр управления сетями и общим доступом» тут вы и сможете обнаружить все ваши vpn подключения. Переходим в пункт «Изменение параметров адаптера»

В итоге тут вам необходимо найти свое VPN подключение.

Убедитесь, что вы используете правильный протокол соединения, из-за него мы уже ловили ошибку 806. Заходим в свойства подключения, через правый клик и переходим на вкладку «Общие» и проверяем правильность адреса сервера.

Очень часто я видел сбой подключения с ошибкой 691 в windows 7 именно из-за неправильного типа протокола на вкладке «Безопасность» и удостоверьтесь в правильности метода проверки подлинности.

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

  • Теперь рассмотрим ошибки со стороны самого VPN сервера. У меня был именно этот случай. Опишу схему. Есть виртуальная машина с microtik и она работает в качестве шлюза и VPN сервера, который для проверки подлинности обращается к radius серверу у которого есть база Active Directory, по которой он видит, кто к нему пришел. И как раз в этой связке были проблемы, на сервере я видел вот такую ошибку;

По сути сервер NPS откидывал пользователя при попытке к нему подключиться и выдавал ему ошибку 691. Причин тут несколько и почти все они на стороне микротика были. Что на нем нужно проверить:

  1. Общий секретный ключ
  2. Протокол подключения
  3. Порты

На стороне сервера NPS и настроек у radius проверьте, что произведена регистрация NPS в Active Directory, если нет то сделайте это.

У вас выскочит окно с подтверждением вашей операции.

Так же на сервере политики сети убедитесь, что в свойствах radius подключения вы можете проверить dns имя или Ip адрес, сервера VPN

У вас не должно быть, что при проверке выдастся сообщение «Этот хост неизвестен» именно из-за этого у вас появляется ошибка «RADIUS-сообщение было получено от недопустимого клиентского IP-адреса»

  • И еще удостоверьтесь, чтобы у вас не блокировались порты ,как со стороны сервера, так и со стороны клиента, примером может быть роутеры, которые режут GRE пакеты или антивирус касперского, если у вас установлен NPS, то его порты можно посмотреть в свойствах сервера. У меня это 1812, 1645 это порты проверки подлинности, 1813, 1646 это порты для учетных данных.

Надеюсь эта небольшая заметка поможет вам решить ошибку подключения 691.

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

В следующей таблице перечислены протоколы проверки подлинности удаленного доступа, поддерживаемые службой удаленного доступа в этой версии Windows. Протоколы перечислены в порядке уменьшения уровня безопасности. Рекомендуется применять протоколы EAP и MS-CHAPv2. Следует избегать применения протоколов CHAP и PAP.

Протокол Описание Уровень безопасности

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

Протокол EAP обеспечивает самый высокий уровень безопасности, предоставляя наибольшую гибкость при выборе вариантов проверки подлинности. Дополнительные сведения см. на странице
Протокол EAP (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?link >

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

Протокол MS-CHAP v2 обеспечивает более высокий уровень безопасности по сравнению с протоколом CHAP. Дополнительные сведения см. на странице
Протокол MS-CHAP v2 (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?link >

Для шифрования ответа используется схема хэширования выборки сообщений MD5.

Преимущество протокола CHAP по сравнению с PAP заключается в том, что пароль не пересылается по PPP-соединению. Для проверки ответа на запрос в протоколе CHAP используется версия пароля в виде обычного текста. Протокол CHAP не обеспечивает защиту от олицетворения удаленного сервера. Дополнительные сведения см. на странице
Протокол CHAP (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?link >

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

Протоколы проверки подлинности

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

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

В двухпроходном протоколе добавлен ответ Боба. Протокол устанавливает, что именно Боб, а не какой-то самозванец, посылает ответ. Он также обеспечивает безопасность обеих передач и защищает от вскрытия повтором.

Читайте так же:  Меры обеспечения иска в гражданском процессе

И в однопроходных, и в двухпроходных алгоритмах используются метки времени. В трехпроходном протоколе добавляется еще одно сообщение Алисы Бобу и позволяет избежать меток времени (и, следовательно, правильного единого времени).

1. Алиса генерирует случайное число RA.

2. Алиса создает сообщение, M = (TA, RA, IB, d), где TA — метка времени Алисы, IB — идентификатор Боба, d — произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Боба EB.

3. Алиса посылает Бобу (CA, DA(M)). (CA — это сертификат Алисы, DA — это общий узел дерева сертификации.)

4. Боб проверяет CA и получает EA. Он проверяет, что срок действия этих ключей еще не истек. (EA — это открытый ключ Алисы.)

5. Боб использует EA для дешифрирования DA(M). Этим действием он проверяет и подпись Алисы, и целостность подписанной информации.

6. Боб для точности проверяет IB в M.

7. Боб проверяет TA в M и убеждается, что сообщение является текущим.

8. Дополнительно Боб может проверить RA в M по базе данных старых номеров, чтобы убедиться, что сообщение не является повторяемым старым сообщением.

Двухпроходный протокол состоит из однопроходного протокола и последующего аналогичного однопроходного протокола от Боба к Алисе. После выполнения этапов (1)-(8) однопроходного протокола двухпроходный протокол продолжается следующим образом:

9. Боб генерирует случайное число RB.

10. Боб создает сообщение M’ = (TB, RB, IA, RA, d), где TB — метка времени Боба, IA — идентификатор Алисы, а d — произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Алисы EА. RA — случайное число Алисы, созданное на этапе (1).

11. Боб посылает Алисе DВ(M’).

Видео (кликните для воспроизведения).

12. Алиса использует EB, чтобы расшифровать DВ(M’). Таким образом, одновременно проверяются подпись Боба и целостность подписанной информации.

13. Алиса для точности проверяет IA в M’.

14. Алиса проверяет TВ в M’ и убеждается, что сообщение является текущим.

15. Дополнительно Алиса может проверить RВ в M’, чтобы убедиться, что сообщение не является повторяемым старым сообщением.

Трехпроходный протокол решает ту же самую задачу, но без меток времени. Этапы (1) — (15) такие же, как в двухпроходном алгоритме, но TA = TВ = 0.

16. Алиса сверяет полученную версию RA с RA, которое было отправлено Бобу на этапе (3).

18. Боб использует EА, чтобы расшифровать DА(RВ). Таким образом одновременно проверяются подпись Алисы и целостность подписанной информации.

19. Алиса сверяет полученную версию RВ с RВ, которое было отправлено Алисе на этапе (10).

| следующая лекция ==>
Сертификаты | Депонирование ключей

Дата добавления: 2014-01-04 ; Просмотров: 378 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Произошла ошибка проверки подлинности. Указанная функция не поддерживается

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:

Произошла ошибка проверки подлинности.

Указанная функция не поддерживается.
Удаленный компьютер: computername

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

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

В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:

The function requested is not supported.

Remote computer: computername

Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.

Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.

Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?

  1. Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
  2. Временный способ 1 . Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
  3. Временный способ 2 . Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда REG ADD
    HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 ) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).
Читайте так же:  Должностная инструкция кассира ресторана

Отключение NLA для протокола RDP в Windows

Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).

В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».

Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

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

Список часто встречающихся ошибок и способ их устранения.

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


Возможные причины появления ошибки и способы её устранения:
1) Неправильно введен логин или пароль.
• Проверьте, правильно ли вы написали логин/пароль. Обратите внимание, что все написанные в пароле знаки необходимо вводить. Также соблюдайте верхний и нижний регистр при написании пароля.
• Проверьте, верно ли введен адрес VPN сервера в настройках
Требуется пересоздать vpn-подключение, если перенабор логинапароля не помог.

2) Логин уже авторизован на сервере.
Пробуйте подключиться через 5-10 минут. Если подключиться не получилось, обращайтесь в отдел поддержки пользователей.
! Ни в коем случае, не сообщайте никому свои реквизиты для подключения.

2. Удаленное подключение не установлено, так как не удалось разрешить имя сервера удаленного доступа. (Нет линка).

Возможные причины появления ошибки и способы её устранения:
1) Проверьте, включена ли сетевая карта на Вашем ПК.
Если состояния подключения по локальной сети отключено – включите двойным кликом левой кнопки мыши.

2) Подключение по локальной сети (Еthernet) зачеркнуто красным крестом и снизу подписано «Сетевой кабель не подключен».
Проверьте, подключен ли сетевой кабель к компьютеру, если нет, то его требуется переподключить. Если подключиться не получилось, обращайтесь в отдел поддержки пользователей.

3. Не удалось установить связь по сети между компьютером и VPN-сервером, так как удаленный сервер не отвечает. Возможная причина: одно из сетевых устройств между компьютером и удаленным сервером не настроено для разрешения VPN-подключений. Чтобы определить, какое устройство вызывает эту проблему, обратитесь к администратору или поставщику услуг. (Неверный адрес сервера).

Возможные причины появления ошибки и способы её устранения:
Проверьте настройки VPN.
Запустите значок с рабочего стола «K-Telecom» и в открывшемся окне нажмите правой кнопкой мышки по подключению. Выберете «Просмотр свойств подключения». Перейдите во вкладку «Общие», имя сервера должно быть 172.16.0.1 или L2.

4. Сетевая папка недоступна. За информацией о разрешении проблем в сети обратитесь к справочной системе Windows. (Не получен ip по dhcp).

Возможные причины появления ошибки и способы её устранения:
1) Проверьте, получает ли сетевая карта адрес сети.
Откройте: Панель управления – Сеть и интернет – Центр управления сетями и общим доступом – Изменение параметров адаптера. Нажмите правой кнопкой мыши по значку «Ethernet » и выберете «Состояние». Если ip адрес начинается на 169.254.xxx.xxx, то обращайтесь в отдел поддержки пользователей.

2) Блокирование антивирусной программой.
Убедитесь, что фаервол или антивирус со встроенным фаерволом не блокируют соединение.

5. Удаленное подключение не установлено, так как не удалось разрешить имя сервера удаленного доступа. (Нет связи до DNS серверов, DNS прописан вручную, отсутствует ip адрес по dhcp).


Возможные причины появления ошибки и способы её устранения:
1) Неправильные настройки локальной сети.
Проверьте настройки подключения по локальной сети. Инструкция по настройке локальной сети здесь.

2) Проверьте получает ли сетевая карта адрес сети.
Откройте: Панель управления – Сеть и интернет – Центр управления сетями и общим доступом – Изменение параметров адаптера. Нажмите правой кнопкой мыши по значку «Еthernet) » и выберете «Состояние». Если ip адрес начинается на 169.254.xxx.xxx, то обращайтесь в отдел поддержки пользователей.

Читайте так же:  Чем отличается подряд от оказания услуг

3) Блокирование антивирусной программой.
Убедитесь, что фаервол или антивирус со встроенным фаерволом не блокируют соединение.

Проверка подлинности kerberos в Active Directory

Проверка подлинности kerberos в Active Directory

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI — это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Пользовательский ключ — когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

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

Ключ службы (service key) — тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

  • Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

  • Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

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

Читайте так же:  Оплачивается ли административный отпуск

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

  • Человек видит поля ввода логина и пароля у себя на компьютере
  • Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

  • Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
  • Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

  • Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
  • Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
  • KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

  • Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
  • Теперь все это дело шифруется сессионным ключом и передается клиенту.

  • Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

  • Теперь клиент формирует штамп времени и шифрует его Kcs ключом, отправляет его вместе с билетом, TGS предназначенным для него.
Видео (кликните для воспроизведения).

  • Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
  • Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.
Что такое протокол проверки подлинности
Оценка 5 проголосовавших: 1

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here