Вопрос совместимости MS-CHAPv2 и ldap базой?

Question

[Денис Сечин]

Имеется связка клиент(MacOS)<->aruba(iap207)<->freeradius(2.2.5)<->ldap(slapd). Radius и Ldap физически разные машины. Ldap хранит пользовательские пароли в ssha1(+соль). На aruba(iap207) включен функционал которые позволяет терминировать eap-туннель прямо на точке доступа, а контроллер уже передает радиусу чистый RADIUS-пакет инкапсулированый в udp.

User-Name = "noc.noc"
1) NAS-IP-Address = 172.16.98.9
2) NAS-Port = 0
3) NAS-Port-Type = Wireless-802.11
4) Calling-Station-Id = "0088653dc372"
5) Called-Station-Id = "24f27fcef196"
6) Service-Type = Framed-User
7) Aruba-Essid-Name = "NOC"
8) Aruba-Location-Id = "leo-lv10-ap09-sw0168"
9) Aruba-AP-Group = "leo-lv10-cluster-aps"
10) MS-CHAP-Challenge = 0x7f3f68430d3da8d4c0c4af**********************
11) MS-CHAP2-Response = 0x0e4de87a4eced1541ebb4e7224b50fda0000000000000000eb81498b02475cb58********
12) Message-Authenticator = 0x81ae3c61e25ed97fb37caf82c448cb29

Это взято из логов радиус-сервера. Строки 11-12 как раз указывают на то, что терминация произошла на точке, а контроллер уже отдал challenge и responce на Radius. Вот тут загвоздка. На этом ресурсе тыц говорят. что mschap и ssha1 никак не совместить. Но моя связка вполне себе работоспособна (до тех пор пока eap терминация работает на точке доступа). Как я понял, Radius, исходя из полученных challenge/responce может сделать decrypt и формат пароля в ssha1 чтобы передать его на ldap и сравнить с исходным? Либо же объясните, каким чудом эта связка работает? Спасибо

Answer 1

[Владимир Дубровин]

MS-CHAPv2 использует пароль в NT-шифровании (MD4 от пароля в Unicode-16), соответственно "дешифровать" или как-то еще использовать пароль SHA-1 она не может. Что происходит зависит от конфигурации LDAP и RADIUS-сервера. Примерные возможные варианты:
1. Таки пароль лежит в открытом тексте или в NT-шифровании без соли, а не в SHA-1 с солью (возможно, дополнительно к паролю SHA-1 с солью отдельным аттрибутом) - наиболее вероятно.
2. LDAP поддерживает NTLM-аутентификацию и по факту RADIUS проксирует NTLM-аутентификацию в LDAP, а не использует пароль, лежащий в LDAP
3. Пароль берется не из LDAP - тоже весьма вероятно
4. RADIUS настроен авторизовать независимо от результатов проверки (но для MS-CHAPv2 это работать не должно, т.к. там авторизация взаимная)
5. Используется не MS-CHAPv2, а что-то другое

Comments

[Денис Сечин]

Используется PEAP-mschapv2. Если терминация происходит на точке доступа, аутентификация проходит. Точка отправляет клиенту пакет access-request (содержимое в теме есть) там атрибуты MS-CHAP-Challenge и MS-CHAP2-Response вероятно как-то из них radius извлекает NT-hash (но как он понимает, что нужен именно NT-hash)? и почему радиус не может извлечь тот-же nt-hash в момент, когда терминация eap происходит непосредствеено на нем?