Аутентификация EAP / MSCHAPv2 завершается неудачей (только) на Windows с пользовательским аутентификатором.

Вопрос или проблема

У меня есть проект, который включает в себя настройку пользовательской аутентификации клиентов для реализации сервера StrongSwan IKEv2 на Linux.

Я использую: StrongSwan 5.4.0 с плагином eap-radius

В настоящее время мы используем FreeRadius для общения по протоколу EAP-MSCHAPv2 с различными клиентскими платформами (Windows, Mac, Linux). Из-за некоторых ограничений нам необходимо реализовать собственный сервер RADIUS “speaking” + EAP-MSCHAPv2 для замены FreeRadius. Я не буду вдаваться в детали, почему это необходимо (но скажу, что это требуется), но я столкнулся с проблемой, которую не могу понять.

Следуя спецификациям RFC для протокола RADIUS, а также протоколов EAP и MSCHAPv2, я создал сервер POC, который аутентифицирует клиентов. Реализация работает для всех клиентов Mac OSX, клиентов Android (с использованием приложения strongswan) и клиентов Linux.

Проблемы начинаются с клиентов Windows (тестировались Windows 10 + 7). По какой-то причине клиент Windows выдает ошибку 691, которая является общей ошибкой, подразумевающей неправильное имя пользователя/пароль или неправильный протокол аутентификации.

Я несколькими способами подтвердил, что моя реализация EAP-MSCHAPv2 соответствует спецификациям RFC:

MSCHAPv2 RFC: https://www.rfc-editor.org/rfc/rfc2759

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

ВВОД:
AuthenticatorChallenge = 5B5D7C7D7B3F2F3E3C2C602132262628
PeerChallenge = 21402324255E262A28295F2B3A337C7E
username = "User"
password = "clientPass"

ВЫВОД:
8-байтовый Challenge: = D02E4386BCE91226
24-байтовый NT-Response:: 82309ECD8D708B5EA08FAA3981CD83544233114A3D85D6DF
42-байтовый AuthenticatorResponse: S=407A5589115FD0D6209F510FE9C04566932CDA56

Это подтверждает, что моя реализация соответствует спецификации RFC для данных, которые должны быть рассчитаны в течение частей MSCHAPv2 EAP-разговора. Это также подтверждается тем фактом, что клиенты Mac, Android и Linux успешно аутентифицируются.

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

Следующее – успешный EAP разговор Windows с FreeRadius:

  1. EAP Identity + Challenge Response
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1> отправка RADIUS Access-Request на сервер '127.0.0.1'
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1> => 168 байт @ 0x7f55f00014b0
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>    0: 01 F6 00 A8 73 40 3E 5D A8 2A 50 21 53 8E FE 52  ....s@>].*P!S..R
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   16: 0F 14 D1 8E 01 12 72 34 32 6D 33 6E 63 76 2D 65  ......r42m3ncv-e
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   32: 38 77 66 70 67 33 3D 06 00 00 00 05 06 06 00 00  8wfpg3=.........
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   48: 00 02 05 06 00 00 00 01 57 10 69 6B 65 76 32 2D  ........W.ikev2-
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   64: 6D 73 63 68 61 70 76 32 04 06 C4 34 2E 23 1E 0E  mschapv2...4.#..
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   80: 31 39 36 2E 35 32 2E 34 36 2E 33 35 1F 10 36 36  196.52.46.35..66
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>   96: 2E 32 30 37 2E 32 30 38 2E 32 32 36 4F 17 02 00  .207.208.226O...
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>  112: 00 15 01 72 34 32 6D 33 6E 63 76 2D 65 38 77 66  ...r42m3ncv-e8wf
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>  128: 70 67 33 20 13 63 61 2D 30 30 31 5F 73 74 72 6F  pg3 .ca-001_stro
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>  144: 6E 67 73 77 61 6E 50 12 E1 CD BD 37 42 F0 6C BE  ngswanP....7B.l.
30 июля 01:02:38 87[CFG] <ikev2-mschapv2|1>  160: 64 AB BD F6 19 B6 9A A6                          d.......
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1> получен RADIUS Access-Challenge от сервера '127.0.0.1'
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1> => 112 байт @ 0x7f55f0000de0
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>    0: 0B F6 00 70 ED 7D 83 2C AF 6E 81 05 ED E7 73 43  ...p.}.,.n....sC
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   16: 60 19 76 B7 1A 0C 00 00 01 37 1C 06 0A FF FF 03  `.v......7......
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   32: 4F 2C 01 01 00 2A 1A 01 01 00 25 10 FC 80 3D 84  O,...*....%...=.
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   48: 7A A0 ED DC FF E3 CB 7C C3 07 62 FC 72 34 32 6D  z......|..b.r42m
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   64: 33 6E 63 76 2D 65 38 77 66 70 67 33 50 12 63 4F  3ncv-e8wfpg3P.cO
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   80: 24 0B F0 D1 B3 09 7B 74 40 5C DF FC FB CC 18 12  $.....{t@\......
30 июля 01:02:39 87[CFG] <ikev2-mschapv2|1>   96: 01 A0 90 AE 01 A1 8A DA 3E A1 21 17 0E 05 88 2C  ........>.!....,
30 июля 01:02:39 87[IKE] <ikev2-mschapv2|1> EAP_MSCHAPV2 загрузка => 42 байта @ 0x7f55f0000ee0
30 июля 01:02:39 87[IKE] <ikev2-mschapv2|1>    0: 01 01 00 2A 1A 01 01 00 25 10 FC 80 3D 84 7A A0  ...*....%...=.z.
30 июля 01:02:39 87[IKE] <ikev2-mschapv2|1>   16: ED DC FF E3 CB 7C C3 07 62 FC 72 34 32 6D 33 6E  .....|..b.r42m3n
30 июля 01:02:39 87[IKE] <ikev2-mschapv2|1>   32: 63 76 2D 65 38 77 66 70 67 33                    cv-e8wfpg3
30 июля 01:02:39 87[IKE] <ikev2-mschapv2|1> инициирование метода EAP_MSCHAPV2 (id 0x01)
  1. Пакет запроса EAP + ответ на Success Packet (Access-Challenge):
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1> отправка RADIUS Access-Request на сервер '127.0.0.1'
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1> => 240 байт @ 0x7f5618001570
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>    0: 01 F7 00 F0 8A 5D 27 E3 01 D1 65 4C 07 7B CC 4A  .....]'...eL.{.J
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   16: 41 12 87 95 01 12 72 34 32 6D 33 6E 63 76 2D 65  A.....r42m3ncv-e
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   32: 38 77 66 70 67 33 3D 06 00 00 00 05 06 06 00 00  8wfpg3=.........
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   48: 00 02 05 06 00 00 00 01 57 10 69 6B 65 76 32 2D  ........W.ikev2-
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   64: 6D 73 63 68 61 70 76 32 04 06 C4 34 2E 23 1E 0E  mschapv2...4.#..
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   80: 31 39 36 2E 35 32 2E 34 36 2E 33 35 1F 10 36 36  196.52.46.35..66
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   96: 2E 32 30 37 2E 32 30 38 2E 32 32 36 4F 4D 02 01  .207.208.226OM..
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  112: 00 4B 1A 02 01 00 46 31 7F D3 69 D7 24 FB 6A 9E  .K....F1..i.$.j.
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  128: 22 39 C7 3F B0 43 94 3C 00 00 00 00 00 00 00 00  "9.?.C.<........
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  144: 76 E7 D7 C3 6B 69 85 B0 1F 7E EF 8D 11 C6 78 28  v...ki...~....x(
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  160: D3 F4 78 04 40 BD BD 39 00 72 34 32 6D 33 6E 63  [email protected]
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  176: 76 2D 65 38 77 66 70 67 33 20 13 63 61 2D 30 30  v-e8wfpg3 .ca-00
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  192: 31 5F 73 74 72 6F 6E 67 73 77 61 6E 18 12 01 A0  1_strongswan....
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  208: 90 AE 01 A1 8A DA 3E A1 21 17 0E 05 88 2C 50 12  ......>.!....,P.
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  224: 73 4F EF F8 F6 08 B9 31 DA FC 35 25 0F CF 00 30  sO.....1..5%...0
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1> получен RADIUS Access-Challenge от сервера '127.0.0.1'
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1> => 121 байт @ 0x7f5618001160
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>    0: 0B F7 00 79 F6 E1 7C CC C5 C7 FA 31 F7 9A 68 45  ...y..|....1..hE
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   16: 71 6A D6 A9 1A 0C 00 00 01 37 1C 06 0A FF FF 03  qj.......7......
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   32: 4F 35 01 02 00 33 1A 03 01 00 2E 53 3D 32 30 46  O5...3.....S=20F
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   48: 46 45 45 38 39 43 31 31 41 39 37 36 44 45 43 34  FEE89C11A976DEC4
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   64: 38 46 42 46 44 34 44 44 31 33 32 46 43 31 36 33  8FBFD4DD132FC163
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   80: 36 39 33 35 31 50 12 D1 D9 D9 CB 8D C1 9A F8 EE  69351P..........
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>   96: 40 12 C5 13 F5 CD 40 18 12 01 A0 90 AE 00 A2 8A  @.....@.........
30 июля 01:02:39 48[CFG] <ikev2-mschapv2|1>  112: DA 3E A1 21 17 0E 05 88 2C                       .>.!....,
30 июля 01:02:39 48[IKE] <ikev2-mschapv2|1> EAP_MSCHAPV2 загрузка => 51 байт @ 0x7f56180012c0
30 июля 01:02:39 48[IKE] <ikev2-mschapv2|1>    0: 01 02 00 33 1A 03 01 00 2E 53 3D 32 30 46 46 45  ...3.....S=20FFE
30 июля 01:02:39 48[IKE] <ikev2-mschapv2|1>   16: 45 38 39 43 31 31 41 39 37 36 44 45 43 34 38 46  E89C11A976DEC48F
30 июля 01:02:39 48[IKE] <ikev2-mschapv2|1>   32: 42 46 44 34 44 44 31 33 32 46 43 31 36 33 36 39  BFD4DD132FC16369
30 июля 01:02:39 48[IKE] <ikev2-mschapv2|1>   48: 33 35 31                                         351
30 июля 01:02:39 48[ENC] <ikev2-mschapv2|1> добавлен тип нагрузки EAP к сообщению
  1. EAP Success -> Success (Access-Accept) Response:
30 июля 01:02:39 124[ENC] <ikev2-mschapv2|1> разобран запрос IKE_AUTH 4 [ EAP/RES/MSCHAPV2 ]
30 июля 01:02:39 124[IKE] <ikev2-mschapv2|1> EAP_MSCHAPV2 загрузка => 6 байт @ 0x7f55d80012f0
30 июля 01:02:39 124[IKE] <ikev2-mschapv2|1>    0: 02 02 00 06 1A 03                                ......
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1> отправка RADIUS Access-Request на сервер '127.0.0.1'
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1> => 171 байт @ 0x7f55d8000980
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>    0: 01 A8 00 AB CA 0B A5 7E 53 26 BB 1F 7B F5 BC 66  .......~S&..{..f
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   16: BD 7B 9D 87 01 12 72 34 32 6D 33 6E 63 76 2D 65  .{....r42m3ncv-e
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   32: 38 77 66 70 67 33 3D 06 00 00 00 05 06 06 00 00  8wfpg3=.........
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   48: 00 02 05 06 00 00 00 01 57 10 69 6B 65 76 32 2D  ........W.ikev2-
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   64: 6D 73 63 68 61 70 76 32 04 06 C4 34 2E 23 1E 0E  mschapv2...4.#..
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   80: 31 39 36 2E 35 32 2E 34 36 2E 33 35 1F 10 36 36  196.52.46.35..66
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   96: 2E 32 30 37 2E 32 30 38 2E 32 32 36 4F 08 02 02  .207.208.226O...
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  112: 00 06 1A 03 20 13 63 61 2D 30 30 31 5F 73 74 72  .... .ca-001_str
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  128: 6F 6E 67 73 77 61 6E 18 12 01 A0 90 AE 00 A2 8A  ongswan.........
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  144: DA 3E A1 21 17 0E 05 88 2C 50 12 AA 6E 35 90 03  .>.!....,P..n5..
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  160: 74 77 80 4A 2E BD FD A7 B2 C5 5B                 tw.J......[
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1> получен RADIUS Access-Accept от сервера '127.0.0.1'
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1> => 182 байта @ 0x7f55d8001750
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>    0: 02 A8 00 B6 61 C5 9A 92 51 CB DD 0B DF 37 3A 0F  ....a...Q....7:.
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   16: 83 40 AB F2 1A 0C 00 00 01 37 1C 06 0A FF FF 03  [email protected]......
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   32: 1A 0C 00 00 01 37 07 06 00 00 00 01 1A 0C 00 00  .....7..........
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   48: 01 37 08 06 00 00 00 06 1A 2A 00 00 01 37 10 24  .7.......*...7.$
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   64: E6 DC E1 89 5C 76 E8 8A BA 58 F7 7B B6 5E 62 4C  ....\v...X.{.^bL
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   80: 7F EB BB C2 45 5A 6B F7 0E 01 F3 9E 0F AD 0E AE  ....EZk.........
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>   96: A3 92 1A 2A 00 00 01 37 11 24 ED F6 C9 A5 D7 3A  ...*...7.$.....:
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  112: 0D C4 4D 93 4F 99 6E 81 28 AC B1 CE 30 DA A0 AF  ..M.O.n.(...0...
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  128: 4F 28 71 60 12 E5 35 39 04 27 A6 68 4F 06 03 02  O(q`..59.'.hO...
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  144: 00 04 50 12 C3 89 53 1A 29 FD 07 DD 11 FB 65 82  ..P...S.).....e.
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  160: 73 93 0C B2 01 12 72 34 32 6D 33 6E 63 76 2D 65  s.....r42m3ncv-e
30 июля 01:02:39 124[CFG] <ikev2-mschapv2|1>  176: 38 77 66 70 67 33                                8wfpg3

На этом этапе дальнейшее общение со стороны клиента не наблюдается. Со стороны клиента отображается ошибка 691. Это подразумевает, что клиент не смог проверить Access-Challenge, отправленный моим POC. Что может быть вызвано неправильным форматом пакета или неправильным значением успешного пакета.

Я взял проверки peer и authenticator из успешного лога и пропустил их через мой код, чтобы увидеть, смогу ли я получить тот же выход в успешном пакете, и действительно генерируется то же значение.

Изучая формат пакета байт за байтом, я не вижу никаких различий ни в формате, ни в значении, но Windows отклоняет этот ответ и завершает EAP разговор.

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

Вот еще несколько ссылок на реализованные RFC:

Дополнительные заметки:

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

Может ли быть что-то в протоколе/пакетах RADIUS, что может повлиять на действительность или принятие сообщений EAP клиентом?

Кроме того, ошибка возникает на этапе “Success Packet” Access-Challenge в разговоре EAP, но могут ли более ранние этапы затихать и вызывать эту ошибку на более позднем этапе? Я не нашел ничего в вышеперечисленных RFC, что бы это предполагало, но на данный момент я никого не исключаю, так как занимаюсь этим уже почти 2 недели.

Наконец, я попытался получить больше отладочной информации от Windows, чтобы увидеть точные данные, которые Windows использует для определения действительности сообщения, но все, что мне удалось получить из “Диагностического отчета удаленного доступа”, это:

[3004] 30.07 11:38:21:863: EapBegin(fServer=0)
[3004] 30.07 11:38:21:863: EapBegin: EapTypeToBeUsed=26, EapAuthType=2
[3004] 30.07 11:38:21:863: EapBegin: ThisIsARenegotiation=0, SaveCredsToCredMan=0, UseWinlogonCredentials=0.
[3004] 30.07 11:38:21:864: EapBegin: Номер подключения: 1835008
[3004] 30.07 11:38:21:864: EapBegin: EAP пользовательский объект не передан, поэтому используются учетные данные.
[3004] 30.07 11:38:21:864: fRetry = 0.
[3004] 30.07 11:38:21:865: Размер данных пользователя EAP: 1021.
[3004] 30.07 11:38:21:865: EapBegin завершен
[3004] 30.07 11:38:21:865: EapMakeMessage,RBuf=4b78910
[3004] 30.07 11:38:21:865: MakeAuthenticateeMessage...
[3004] 30.07 11:38:21:865: EAPSTATE_Initial
[3004] 30.07 11:38:21:865: EapMethodBegin(Flags=0x10, Осталось попыток=3)
[3004] 30.07 11:38:21:866: EAPSTATE_Working
[3004] 30.07 11:38:21:866: HandleEapResponse -- Вход.
[3004] 30.07 11:38:21:866: EapHost вернул действие = EapHostPeerResponseSend. Обработка отправки пакета...
[3004] 30.07 11:38:21:866: RasProcessEapHostSendPacket -- Вход.
[3004] 30.07 11:38:21:866: Получено имя: r42m3ncv-e8wfpg3.
[3004] 30.07 11:38:21:866: RasProcessEapHostSendPacket: Отправка пакета.
[3004] 30.07 11:38:21:866: RasProcessEapHostSendPacket -- Выход: 0x0.
[3004] 30.07 11:38:21:866: HandleEapResponse -- Выход: 0x0.
[3004] 30.07 11:38:21:869: EapMakeMessage,RBuf=4b78910
[3004] 30.07 11:38:21:869: MakeAuthenticateeMessage...
[3004] 30.07 11:38:21:869: EAPSTATE_Working
[3004] 30.07 11:38:21:870: HandleEapResponse -- Вход.
[3004] 30.07 11:38:21:870: EapHost вернул действие = EapHostPeerResponseSend. Обработка отправки пакета...
[3004] 30.07 11:38:21:870: RasProcessEapHostSendPacket -- Вход.
[3004] 30.07 11:38:21:870: RasProcessEapHostSendPacket: Отправка пакета.
[3004] 30.07 11:38:21:870: RasProcessEapHostSendPacket -- Выход: 0x0.
[3004] 30.07 11:38:21:870: HandleEapResponse -- Выход: 0x0.
[3004] 30.07 11:38:21:873: EapMakeMessage,RBuf=4b78910
[3004] 30.07 11:38:21:873: MakeAuthenticateeMessage...
[3004] 30.07 11:38:21:873: EAPSTATE_Working
[3004] 30.07 11:38:21:873: HandleEapResponse -- Вход.
[3004] 30.07 11:38:21:873: EapHost вернул действие = EapHostPeerResponseResult. Получение результата...
[3004] 30.07 11:38:21:873: RasGetEapHostAuthResult -- Вход.
[3004] 30.07 11:38:21:873: RasSetQuarantineStatus -- Вход.
[3004] 30.07 11:38:21:873: ISOLATION_STATE_UNKNOWN
[3004] 30.07 11:38:21:873: RasSetQuarantineStatus -- Выход: 0x0.
[3004] 30.07 11:38:21:873: Аутентификация EAP завершилась с ошибкой: Внутренняя = 0x2b3, Внешняя = 0x80420112.
[3004] 30.07 11:38:21:873: RasGetEapHostAuthResult -- Выход: 0x0.
[3004] 30.07 11:38:21:873: HandleEapResponse -- Выход: 0x0.
[960] 30.07 11:38:21:881: EapEnd
[960] 30.07 11:38:21:881: EapMethodEnd вызван для EAP Index 26

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

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

Убедитесь, что dh-group соответствует ожиданиям, и похоже, что есть разница в формате пароля, возможно, это связано с Win auth и хешем NTLM? И, как я заметил, пакеты, похоже, отличаются по размеру для вашего POC и Windows, что может быть связано с хешем, dh-group или используемым сертификатом (это описано ниже).

В любых связанных проектах ниже вы сможете повторно использовать библиотеки или проверить свою реализацию или это может помочь: https://github.com/enaess/ppp-eap-mschapv2

https://forums.freebsd.org/threads/howto-set-up-a-l2tp-ipsec-vpn-dial-in-server-part-i-to-iii.26755/

Включает аутентификацию по базе данных паролей системы. Этот
параметр можно использовать только с PAP и MS-CHAP, но не с CHAP-MD5.
Если вы собираетесь использовать это с MS-CHAP, тогда пароли в
master.passwd должны быть NT-Hashes. Вы можете включить это, добавив
:passwd_format=nth: в ваш /etc/login.conf, но вам нужно как минимум
FreeBSD 5.2.

Похоже, что есть и некоторые необычные поведения:
https://github.com/FreeRADIUS/freeradius-server/issues/679

Невозможно подключиться к коммерческому VPN Windows Server 2008:
https://wiki.strongswan.org/issues/1252

https://wiki.strongswan.org/issues/2352

Это связано с тем, что mschapv2 требует реализации алгоритма MD4,
который реализован в плагине md4, и вы его не загружаете.

некоторые части также упоминаются в комментариях для каждого значения
https://wiki.strongswan.org/projects/strongswan/wiki/Win7EapMultipleConfig

rightsendcert=never
Поскольку клиенты аутентифицируют себя с использованием EAP-MSCHAPv2, шлюз не будет
отправлять запросы на сертификаты. Однако, если strongSwan обслуживает других клиентов с использованием сертификатной
аутентификации, никогда не следует использовать, так как ответчик обычно не может применить этот
параметр для отдельных соединений.

eap_identity=%any
Шлюз strongSwan использует протокол EAP Identity для запроса EAP-идентификатора, отличного от
IKEv2-идентификатора пира.

auto=add
Соединение win7 анализируется и загружается демоном IKEv2 charon, но VPN-шлюз будет
действовать как ответчик и пассивно ждать, пока клиент Windows 7 не начнет согласование IKE.

Это частично описывается в документах MS

“Типичной причиной этой ошибки является то, что NPS указал условие
аутентификации, которое клиент не может выполнить. Например, NPS может указывать на использование
сертификата для обеспечения соединения PEAP, но клиент пытается использовать EAP-MSCHAPv2.”

Убедитесь, что вы выполняете все требования, часто это просто неправильная группа или шифр:
https://support.microsoft.com/en-us/help/2744850/implementing-peap-ms-chap-v2-authentication-for-microsoft-pptp-vpns

Это не ответ, скорее направление. Надеюсь, это поможет.

Ну, я понял проблему. Поле идентификатора EAP для успешного пакета нужно было увеличить.

30 июля 00:33:24 100[IKE] <ikev2-mschapv2|1>    0: 01 01 00 33 1A 03 01 00 2E 53 3D 33 39 39 45 33

Второй октет должен был быть увеличен до 02. Я не нашел никаких упоминаний об этом в RFC, и я все еще озадачен, почему это сработало на всех платформах, кроме Windows.

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Код       |   Идентификатор  |            Длина             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |   OpCode        |  MS-CHAPv2-ID |  MS-Length...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   MS-Length   |                    Сообщение...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MS-CHAPv2-ID
   Поле MS-CHAPv2-ID имеет один октет и помогает в сопоставлении ответов MSCHAP-v2 
   с запросами. Обычно поле MS-CHAPv2-ID совпадает с полем идентификатора.

Это работает, когда вы НЕ устанавливаете его в то же значение, что и идентификатор EAP.

Я скоро опубликую свои выводы + пример здесь: https://github.com/Windscribe/radius

Насколько мне известно, это единственная работающая реализация RADIUS/EAP-MSCHAPv2, кроме FreeRadius.

Ответ или решение

Проблема аутентификации EAP/MSCHAPv2 на Windows с кастомным аутентификатором

Аутентификация клиентов через EAP-MSCHAPv2 на платформе Windows с использованием собственного сервера RADIUS может быть затруднена из-за различных нюансов, связанных как с протоколами, так и с форматом пакетов. Давайте подробно рассмотрим основные аспекты данной проблемы и предложим возможные решения.

Контекст проблемы

При реализации протокола EAP-MSCHAPv2 для аутентификации клиентов на сервере StrongSwan 5.4.0 с плагином eap-radius оказалось, что клиенты на Windows (7 и 10) получали ошибку 691, что свидетельствовало о возможных проблемах с несуществующим пользователем или неправильном протоколе аутентификации. В то время как клиенты на Mac OS, Android и Linux проходили аутентификацию без нарушений, анонимные журналы показали дело об отсутствии именных идентификаторов.

Соответствие спецификациям

Ваша реализация MSCHAPv2, судя по всему, соответствует спецификациям RFC, и вы проверили правильность вычислений. Основные пункты, которые нужно проверить:

  1. Формат пакетов. Windows может быть более чувствительна к структуре пакетов, чем другие платформы. Убедитесь, что в ваших ответах строго соблюдается порядок байтов. Например, наличие или отсутствие ненужных полей может стать причиной отказа в аутентификации.

  2. Идентификатор EAP и MS-CHAPv2-ID. Как было установлено в недавнем исследовании, идентификатор EAP в Success Packet должен быть инкрементирован (т.е., вместо идентификатора 1, использовать 2). Это происходит потому, что Windows использует эти поля для сопоставления запросов и ответов:

    EAP Identifier: 0x01 -> должен стать 0x02 для Success Packet
  3. Поддержка MD4. EAP-MSCHAPv2 требует алгоритма MD4 для некоторых вычислений. Убедитесь, что ваш сервер StrongSwan загружает необходимый плагин MD4 для работы.

Варианты решения

  • Проверьте формат пакетов. Тщательно изучите расшифровку пакетов, чтобы удостовериться, что на всех уровнях (RADIUS, EAP, MSCHAPv2) используются точно соответствующие спецификации.

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

  • Перепроверьте настройки клиентов. Убедитесь, что настройки на стороне клиента означают правильное использование EAP-MSCHAPv2 и что нет никаких скрытых требований, таких как необходимость использования сертификатов.

  • Сравните параметры шифрования.Windows может требовать особых криптографических параметров, которые могут отличаться от других платформ (например, использование определенных групп DH).

  • Тестирование. Запустите различные конфигурации и тесты клиентов, чтобы проверить, какое именно изменение параметров может устранить проблему.

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...