Аутентификация через RADIUS: ошибка MSCHAPv2 691

Я работаю над настройкой аутентификации в Acme Packet Net-Net 3820 (SBC) через RADIUS. Бухгалтерская сторона дела работает нормально, без проблем. Другое дело - аутентификация. Я могу видеть из захвата пакета, что сообщения запроса доступа на самом деле попадают на сервер RADIUS, в этот момент сервер RADIUS начинает взаимодействовать с контроллерами домена. Затем я вижу, как цепочка связи возвращается к RADIUS, а затем, наконец, обратно к SBC. Проблема в том, что ответ, который я получаю, всегда представляет собой сообщение об отказе в доступе с кодом причины 16 (аутентификация не удалась из-за несоответствия учетных данных пользователя. Либо указанное имя пользователя не соответствует существующей учетной записи, либо пароль был неверным). Это подтверждается просмотром журналов событий безопасности, где я вижу события 4625 и 6273. См. События ниже (Примечание: имена и IP-адреса были изменены для защиты невиновных):

Код события: 6273

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
    Security ID:            NULL SID
    Account Name:           real_username
    Account Domain:         real_domain
    Fully Qualified Account Name:   real_domain\real_username

Client Machine:
    Security ID:            NULL SID
    Account Name:           -
    Fully Qualified Account Name:   -
    OS-Version:         -
    Called Station Identifier:      -
    Calling Station Identifier:     -

NAS:
    NAS IPv4 Address:       10.0.0.10
    NAS IPv6 Address:       -
    NAS Identifier:         radius1.real_domain
    NAS Port-Type:          -
    NAS Port:           101451540

RADIUS Client:
    Client Friendly Name:       sbc1mgmt
    Client IP Address:          10.0.0.10

Authentication Details:
    Connection Request Policy Name: SBC Authentication
    Network Policy Name:        -
    Authentication Provider:        Windows
    Authentication Server:      RADIUS1.real_domain
    Authentication Type:        MS-CHAPv2
    EAP Type:           -
    Account Session Identifier:     -
    Logging Results:            Accounting information was written to the SQL data store and the local log file.
    Reason Code:            16
    Reason:             Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

Код события: 4625

An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:       RADIUS1$
    Account Domain:     REAL_DOMAIN
    Logon ID:       0x3E7

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       real_username
    Account Domain:     REAL_DOMAIN

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xC000006D
    Sub Status:     0xC000006A

Process Information:
    Caller Process ID:  0x2cc
    Caller Process Name:    C:\Windows\System32\svchost.exe

Network Information:
    Workstation Name:   
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      IAS
    Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Таким образом, на первый взгляд может показаться, что проблема заключается только в неверном имени пользователя или несоответствующем пароле. Это дополнительно подтверждается в захвате пакета, где я вижу, что ответ MSCHAPv2 имеет код ошибки 691 (доступ запрещен, потому что имя пользователя или пароль, или и то, и другое, недействительны в домене). Дело в том, что я знаю, что использую действительное имя пользователя, и я перепробовал множество имен пользователей, включая новые, которые я создал только для устранения неполадок. Я не знаю, сколько раз я сбрасывал пароль, пытаясь убедиться, что это не несоответствующий пароль. Я даже позаботился о том, чтобы пароли были достаточно короткими и содержали только буквы, чтобы гарантировать отсутствие проблем с кодировкой терминала (мы подключаемся к SBC через клиентов SSH). Я также проделал то же самое с общим секретом, используемым во время связи между SBC и сервером RADIUS. Я пробовал ставить перед именем пользователя имя домена при входе в систему (хотя я не думаю, что это необходимо). Я также пробовал использовать полное имя участника-пользователя для входа в систему. Я пробовал несколько клиентов тестирования RADIUS (NTRadPing, RadiusTest и т. Д.), Но они либо не поддерживают MSCHAPv2, либо поддерживают только EAP-MSCHAPv2. Я даже создал свой собственный клиент, используя модуль PHP PECL RADIUS. Тем не менее, при аутентификации MSCHAPv2 всегда возникает сбой с кодом ошибки 691. Есть ли у кого-нибудь идеи относительно того, почему я всегда получаю неверное имя пользователя или ответ с неверным паролем, когда я сделал все возможное, чтобы убедиться, что это не так?

Вот спецификации для нашей конфигурации RADIUS:

• Windows Server 2012 R2
• Серверная база данных SQL Server 2012 для бухгалтерского учета.
• Сервер авторизован в домене и входит в группу «Серверы RAS и IAS». Для которой эта группа имеет доступ к учетным записям, с которыми мы тестируем.
• У учетных записей, с которыми мы тестируем, есть опция «Контроль доступа с помощью сетевой политики NPS», отмеченная на вкладке свойств «Dial-in».
• Клиенты RADIUS настроены на простое совпадение по IP-адресу, который, как вы можете видеть из событий выше, применяет понятное имя клиента.
• Политика запроса подключения: применяется политика «SBC Authenication», как показано выше. Единственное условие - это выражение регулярного выражения, которое успешно соответствует понятному имени.
• Сетевая политика: как видно из событий выше, ни одна из них не применяется. В целях устранения неполадок я создал сетевую политику, которая установлена ​​на «1» для порядка обработки, и ее единственным условием является ограничение дня и времени, установленное в настоящее время на любое время, в любой день.
• Метод аутентификации установлен только на MSCHAPv2 или MSCHAPv2 (пользователь может изменить пароль по истечении срока его действия). Я попытался добавить это только в сетевую политику, а также попытался добавить это в политику запросов на подключение и настроить его так, чтобы переопределить метод аутентификации сетевой политики.
• У нас есть другие серверы RADIUS в нашем домене, которые используют PEAP для аутентификации беспроводных клиентов, и все они работают нормально. Однако нам это нужно для работы только с MSCHAPv2 (без EAP).
• Для всех остальных конфигураций установлены значения по умолчанию.

Единственное, на что следует обратить внимание, это тот факт, что в событиях выше вы можете видеть, что идентификатор безопасности равен «NULL SID». Теперь я знаю, что это часто встречается, особенно среди неудачных входов в систему, но, учитывая, что эта проблема связана с неверным именем пользователя или неправильным паролем, возможно, в данном случае это имеет значение. Кроме того, этот сервер был перестроен с использованием той же учетной записи компьютера в Active Directory. Не знаю, сработало бы до пересборки. По сути, мы построили этот сервер и дошли до авторизации сервера в домене и добавления SQL только тогда, когда решили выделить роль SQL на другой сервер. Вместо того, чтобы удалять SQL, мы просто перестроили машину. Однако перед переустановкой Windows я сделал сброс учетной записи компьютера. Я не думаю, что это должно иметь значение, но подумал, что укажу на это, если есть какая-то странная причуда, когда повторное использование того же SID ранее авторизованного сервера NPS может вызвать проблему.

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

Изменить 1:

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

Несколько доменов

Теперь я пробовал это в 3 разных изолированных доменах. И тестовый, и рабочий домены, а также мой частный домашний домен, в котором очень мало настроек, кроме изменений, сделанных для Exchange и ConfigMgr. Все имеют одинаковые результаты, описанные выше.

VPN сервис

Используя Windows Server 2012 R2, мы создали отдельный сервер для стандартной настройки VPN. Намерение состояло в том, чтобы посмотреть, можем ли мы использовать аутентификацию RADIUS с VPN, и если бы это сработало, мы бы знали, что проблема связана с SBC. Однако, прежде чем мы смогли даже настроить его для использования RADIUS, мы просто попытались убедиться, что он работает со стандартной аутентификацией Windows на локальном сервере VPN. Интересно, что он тоже не работает с теми же событиями, которые регистрируются на серверах RADIUS. Клиентская машина является рабочей станцией Windows 8.1. Я снова указываю, что у нас есть рабочие серверы RADIUS, которые используются специально для нашей беспроводной среды. Единственная разница между этими серверами RADIUS и теми, с которыми у меня возникли проблемы, заключается в том, что работающие беспроводные серверы используют PEAP вместо MSCHAPv2.

FreeRADIUS

Сейчас я не гуру Linux, но считаю, что он у меня уже есть. Я могу использовать ntlm_auth для аутентификации пользователей при входе в консоль. Однако, когда служба radiusd пытается использовать ntlm_auth, чтобы сделать то же самое, она терпит неудачу и возвращает то же сообщение, которое я получал с сервером Windows (E = 691). У меня служба radiusd работает в режиме отладки, поэтому я могу больше видеть, что происходит. Я могу опубликовать полученную отладочную информацию, если потребуется. Однако особенно интересны следующие строки:

(1) ERROR: mschap : Program returned code (1) and output 'Logon failure (0xc000006d)'
(1) mschap : External script failed.
(1) ERROR: mschap : External script says: Logon Failure (0xc000006d)
(1) ERROR: mschap : MS-CHAP2-Response is incorrect

Здесь следует отметить, что хотя мы, по сути, все еще получаем сообщение «неправильный пароль», фактический код состояния (0xc000006d) немного отличается от того, что я получал на серверах Windows, который был (0xc000006a). Из этого документа вы можете увидеть, что означают эти коды: Ценности NTSTATUS . В этом сервере FreeRADIUS хорошо то, что я могу видеть все ответы на запросы, когда он находится в режиме отладки. Так что, если я могу понять, как вычисляется ответ MSCHAPv2, я могу сравнить его, чтобы увидеть, является ли это просто неправильно вычисленным ответом на вызов. Обновить Просто заметил, что код 6a - это просто код субстатуса для кода 6d. Так что ничем не отличается от серверов Windows, мне все еще интересно, есть ли ошибка вычислений с ответами на запросы.

В настоящее время я работаю над созданием экземпляра Windows Server 2008 R2 сервера RADIUS, чтобы посмотреть, помогает ли это вообще. Однако я был бы удивлен, если бы что-то с сервисом сломалось между W2K8 R2 и W2K12 R2, чего до сих пор никто не заметил. Если это не сработает, мне, возможно, придется открыть дело в Microsoft. Обновить: Те же результаты с W2K8 R2.

Обновление 2

Я открыл дело с Microsoft, и они работали над ним пару недель. Первую неделю я потратил свое время, просто пытаясь заставить их понять, что это не имеет ничего общего с беспроводной связью и что устройство, к которому мы пытаемся подключиться, не поддерживает аутентификацию на сервере RADIUS с использованием любой формы EAP. Как только они наконец поняли, что мы пытаемся настроить метод аутентификации только для MSCHAPv2, его первая реакция была просто «вы не можете этого сделать». Он сказал, что независимо от того, что вам всегда нужно, какая-то форма настройки EAP или PEAP в верхнем поле (даже для PAP и других «менее безопасных методов» в этом окне метода аутентификации). Мне это показалось маловероятным, поэтому я попросил документацию, подтверждающую это, для чего он затем сменил тему и никогда не предоставил никакой документации. Стало ясно, что я ничего не добился в Microsoft, когда они сказали мне, что проблема, похоже, связана с именем пользователя и паролем. Таким образом, им потребовалось 2 недели, чтобы прийти к такому выводу, когда в строке темы моего билета на премьеру был указан код ошибки E691, что означает несоответствие имени пользователя и пароля, и, несмотря на очень длинный абзац, в котором я объяснял, что я сделал все возможное, чтобы это гарантировать неплохой логин и пароль.

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

Я отмечу, что до того, как мне сказали отказаться от проекта, я заставил сервер FreeRADIUS работать только с использованием MSCHAPv2, но смог сделать это только с учетными записями, локальными для сервера FreeRADIUS. Это пароли в виде простого текста, хранящиеся где-то в конфигурационном файле FreeRADIUS. Очевидно, это не решение, но, по крайней мере, показывает, что SBC правильно взаимодействует с сервером RADIUS через MSCHAPv2. Это и другие вещи, о которых я упомянул выше, наводят меня на мысль, что проблема заключается между сервером RADIUS и контроллерами домена. Хотя проверка подлинности NTLM отлично работает на серверах Windows RADIUS и FreeRADIUS при локальном входе на серверы (можно войти в Windows RADIUS через тестовую учетную запись и получить успешную проверку подлинности на сервере FreeRADIUS при использовании команды ntlm_auth только с именем пользователя и паролем) , ни один из серверов RADIUS не проходит аутентификацию через пользователей при входе в качестве запроса доступа RADIUS (FreeRADIUS использует ту же команду ntlm_auth, которую я использую при локальном входе в систему, но вместо того, чтобы указывать имя пользователя и пароль для команды, он предоставляет имя пользователя и ответ на запрос).

Итак, я завершу эту ветку здесь, но я буду следить за этим, и он сообщит мне, если кто-то что-то опубликует. Если кто-то опубликует решение или оставит комментарии, я отвечу.