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

Я работаю над установкой аутентификации в Пакет Высшей точки Окончательные 3820 (SBC) через RADIUS. Бухгалтерская сторона вещей работает просто великолепно без проблем. Сторона аутентификации вещей является другим вопросом. Я вижу от захвата пакетов, что сообщения запроса доступа на самом деле добираются до сервера RADIUS, в которой точке сервер RADIUS начинает связываться с контроллерами домена. Я затем вижу цепочку коммуникации, возвращающейся к RADIUS и затем наконец назад к SBC. Проблемой является ответ, который я возвращаю, всегда сообщение отклонения доступа с кодом причины 16 (Аутентификация перестала работать из-за несоответствия удостоверений пользователя. Или обеспеченное имя пользователя не соответствует существующей учетной записи пользователя или паролю, было неправильным). Это подтверждено путем рассмотрения журналов событий безопасности, где я вижу события 4625 и 6273. Посмотрите события ниже (Примечание: имена и дюйм/с были изменены для защиты невинного):

Идентификатор события: 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. Я попытался снабдить префиксом имя пользователя доменное имя при входе в систему (хотя я не думаю, что это должно быть необходимо). Я также попытался использовать полный UPN пользователя для входа в систему. Я судил несколько клиентов тестирования RADIUS (NTRadPing, RadiusTest, и т.д.), но они или не поддерживают MSCHAPv2 или только поддерживают EAP-MSCHAPv2. Я даже создал свой собственный клиент, использующий модуль RADIUS PHP PECL. Тем не менее это всегда, кажется, перестало работать с аутентификацией MSCHAPv2 с кодом ошибки 691. У кого-либо есть какие-либо идеи относительно того, почему я всегда получаю неверное имя пользователя или ответ неверного пароля, когда я сделал все возможное для обеспечения дело не в этом?

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

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

Единственными другими знаменитыми вещами рассмотреть является то, которое в событиях выше Вас видит, что Идентификатором безопасности является "ПУСТОЙ SID". Теперь я знаю, что это распространено особенно среди неудавшихся входов в систему, но, учитывая, что эта проблема указывает неверное имя пользователя или неверный пароль, возможно, это имеет значение в этом случае. Кроме того, этот сервер был восстановлен с помощью той же учетной записи компьютера в Active Directory. Я не знаю, работало ли это перед восстанавливанием. По существу мы создали этот сервер и только добрались до авторизации сервера к домену и добавлению SQL, когда мы решили выделить роль SQL на другой сервер. Вместо того, чтобы удалять SQL, мы просто восстановили машину. Однако прежде, чем переустановить Windows I действительно делало сброс на учетной записи компьютера. Я не думаю, что это должно иметь значение, но думало, что я укажу на это, если будет некоторая странная причуда, где многократное использование того же SID ранее авторизованного сервера NPS вызвало бы проблему.

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

Редактирование 1:

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

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

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

Сервис VPN

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

FreeRADIUS

Теперь я не гуру Linux, но я полагаю, что у меня есть он и выполнение. Я могу использовать ntlm_auth для аутентификации пользователей, когда зарегистрирован на консоли. Однако, когда radiusd сервис пытается использовать ntlm_auth, чтобы сделать по существу то же самое, он приводит к сбою и возвращает то же сообщение, которое я получал с Windows Server (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 Server, который был (0xc000006a). Из этого документа Вы видите то, что означают эти коды: значения NTSTATUS. Хорошая вещь об этом сервере FreeRADIUS состоит в том, что я вижу все ответы проблемы, когда это находится в режиме отладки. Таким образом, если я могу перенести голову, как ответ MSCHAPv2 вычисляется, я могу сравнить его, чтобы видеть, является ли это просто ответом проблемы miscomputed. Обновление просто замечало, что 6a код является просто кодом подстатуса для 6d код. Так ничто различное от Windows Server, я все еще задаюсь вопросом, существует ли ошибка вычисления с ответами проблемы все же.

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

Обновление 2

Я открыл случай с Microsoft, и они работали над нею в течение нескольких недель. Первая неделя я провел свое время, просто пытаясь заставить их понимать это, ничего не имеет к с беспроводной связью и что устройство, с которым мы пытаемся соединиться, не поддерживает аутентификацию против сервера RADIUS с помощью любой формы EAP. После того как они наконец поняли, что мы пытаемся установить метод аутентификации как просто MSCHAPv2 только, его первоначальная реакция была просто, "Вы не можете сделать этого". Он сказал, это независимо от того, что Вам всегда нужна некоторая форма EAP или установки PEAP в главном поле (даже для КАШИ и других "Менее безопасных методов" в том окне метода аутентификации). Это казалось очень маловероятным мне так, я попросил некоторую документацию, заявив это, для которого он затем сменяет тему и никогда не предоставлял документации. Стало ясно, что я нигде не добирался с 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, управляют, чтобы я использовал при локальном входе в систему, но вместо того, чтобы ввести имя пользователя и пароль к команде это вводит имя пользователя и ответ проблемы).

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