windows-authentication – 通过RADIUS进行身份验证：MSCHAPv2错

我正在通过RADIUS设置身份验证到Acme Packet Net-Net 3820(SBC).会计方面的工作正常,没有问题.事情的认证方面是另一回事.我可以从数据包捕获中看到,访问请求消息实际上已经到达RADIUS服务器,此时RADIUS服务器开始与域控制器通信.然后我看到通信链回到RADIUS,然后最终回到SBC.问题是我得到的响应始终是访问拒绝消息,原因代码为16(由于用户凭据不匹配,身份验证失败.提供的用户名与现有用户帐户不匹配或密码不正确).通过查看我可以看到事件4625和6273的安全事件日志来确认这一点.请参阅下面的事件(注意：名称和IP已更改以保护无辜者)：

事件ID：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_domainreal_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.

事件ID：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:WindowsSystem32svchost.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(访问被拒绝,因为用户名或密码,或两者都在域上无效).问题是我知道我使用的是有效的用户名,我尝试了很多用户名,包括我为故障排除而创建的新用户名.我不知道有多少次我重置密码以确保密码不是不匹配.我甚至确保使用相当短的密码并且只包含字母以确保没有终端编码问题(我们通过SSH客户端连接到SBC).我在SBC和RADIUS服务器之间的通信期间使用的共享密钥也做了同样的事情.我曾尝试在登录时使用域名前缀用户名(虽然我认为不应该这样做).我也尝试使用用户的完整UPN登录.我尝试了几个RADIUS测试客户端(NTRadPing,RadiusTest等),但它们要么不支持MSCHAPv2,要么只支持EAP-MSCHAPv2.我甚至使用PHP的PECL RADIUS模块创建了自己的客户端.仍然总是似乎失败的MSCHAPv2身份验证错误代码为691.有没有人有任何想法,为什么我总是得到一个无效的用户名或错误的密码响应,当我已尽一切可能确保不是这样的情况？

以下是我们的RADIUS配置的规范：

> Windows Server 2012 R2
>用于记帐的SQL Server 2012后端数据库.
>服务器已在域上获得授权,并且是“RAS和IAS服务器”组的成员.该组可以访问我们正在测试的帐户.
>我们正在测试的帐户确实在“拨入”属性选项卡下选中了“通过NPS网络策略控制访问”选项.
> RADIUS客户端配置为简单匹配IP地址,您可以从上面的事件中看到它正在应用客户端友好名称.
>连接请求策略：如上所示,正在应用“SBC身份验证”策略.唯一的条件是正则表达式成功匹配友好名称.
>网络政策：如上面的事件所示,没有一个被应用.出于故障排除的目的,我创建了一个网络策略,对于处理订单设置为“1”,其唯一条件是当前设置为任何时间,任何一天的日期和时间限制.
>身份验证方法仅设置为MSCHAPv2或MSCHAPv2(用户可以在密码过期后更改密码).我已经尝试将此添加到网络策略中,我也尝试将其添加到连接请求策略并将其设置为覆盖网络策略的身份验证方法.
>我们的域中有其他RADIUS服务器使用PEAP来验证无线客户端,它们都可以正常工作.但是,我们需要它才能与MSCHAPv2一起使用(无EAP).
>所有其他配置都设置为默认值.

需要注意的唯一其他事项是,在上面的事件中,您可以看到安全ID是“NULL SID”.现在我知道这在失败的登录中很常见,但鉴于此问题是说明用户名或密码错误,在这种情况下可能很重要.此外,此服务器已使用Active Directory中的同一计算机帐户重建.我不知道在重建之前它是否会起作用.基本上我们构建了这个服务器,只有在将服务器授权到域并在我们决定将SQL角色分离到另一个服务器时添加SQL.我们只是重建了机器,而不是卸载SQL.但是,在重新安装Windows之前,我确实在计算机帐户上进行了重置.我不认为这应该重要,但我想如果有一些奇怪的怪癖,重复使用先前授权的NPS服务器的相同SID会导致问题,我会指出它.

总而言之,这是一个相当基本的设置,希望我已经为某人提供了足够的信息来了解可能发生的事情.抱歉,如果我对此的理解似乎有点基础,毕竟,当谈到RADIUS服务器时,我想你可以说我是这里的新人.

编辑1：

为了进一步解决此问题,我尝试使用其他服务器进行测试.以下是我执行的其他测试.

多个域

我现在在3个不同的孤立域中尝试过这个.我们的测试和生产域以及我的私有主域都除了对Exchange和ConfigMgr所做的修改之外几乎没有自定义的方式.所有都具有上述相同的结果.

VPN服务

使用Windows Server 2012 R2,我们启动了一个单独的服务器来运行标准VPN设置.目的是看看我们是否可以在VPN上使用RADIUS身份验证,如果可行,我们就会知道问题在于SBC.但是,在我们甚至可以将其配置为使用RADIUS之前,我们只是尝试确保它在本地VPN服务器上使用标准Windows身份验证.有趣的是,它也失败了,同样的事件被记录为RADIUS服务器.客户端计算机是Windows 8.1工作站.我再次指出,我们有专门用于无线环境的RADIUS服务器.这些RADIUS服务器与我遇到的问题之间的唯一区别是工作的无线服务器使用的是PEAP而不是MSCHAPv2.

FreeRADIUS的

现在我不是Linux大师,但我相信我已经开始运行了.登录控制台时,我可以使用ntlm_auth对用户进行身份验证.但是,当radiusd服务尝试使用ntlm_auth执行基本相同的操作时,它会失败并返回我在Windows服务器上获得的相同消息(E = 691).我有半径服务在调试模式下运行,所以我可以看到更多正在发生的事情.如果需要,我可以发布调试信息.我看到特别感兴趣的界限如下：

(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 values.这个FreeRADIUS服务器的好处是,当它处于调试模式时,我可以看到所有挑战响应.因此,如果我可以围绕如何计算MSCHAPv2响应,我可以比较它,看看这是否只是一个错误计算的质询响应.更新只是注意到6a代码只是6d代码的子状态代码.因此,与Windows服务器没什么不同,我仍然想知道挑战响应是否存在计算错误.

目前,我正在开发一个RADIUS服务器的Windows Server 2008 R2实例,看看它是否有帮助.但是,如果W2K8 R2和W2K12 R2之间的服务突然间没有人注意到,那么我会感到惊讶.如果这不起作用,我可能需要向微软公开案例.更新：与W2K8 R2相同的结果.

更新2

我向微软公开了一个案例,他们已经开展了几个星期的工作.第一周,我花了一些时间试图让他们了解这与无线无关,我们尝试连接的设备不支持使用任何形式的EAP对RADIUS服务器进行身份验证.一旦他们终于明白我们正在尝试将身份验证方法设置为仅MSCHAPv2,他的初步反应就是“你不能那样做”.他说,无论你在顶盒中总是需要某种形式的EAP或PEAP设置(即使是PAP和其他“认证方法窗口中的”安全性较低的方法“).这对我来说似乎不太可能,所以我要求提供一些文件说明这一点,然后他改变主题,从未提供任何文件.很明显,当他们告诉我问题似乎是使用用户名和密码时,我无法与微软取得联系.因此,当我的首映票的主题行中包含E691错误代码,意味着用户名和密码不匹配时,花了2个星期才得出结论.尽管我的段落很长,但我解释说我已尽一切可能确保它用户名和密码不错.

不幸的是,我的项目负责人不想浪费任何更多的首要支持时间,所以我们关闭了案件.我们可能只是处理SBC本地共享登录并设置其他一些方式来强制执行问责制(我们只有4个人可以访问).

我将指出,在我被告知放弃项目之前,我确实让FreeRADIUS服务器只能使用MSCHAPv2工作,但只能使用FreeRADIUS服务器本地帐户执行此操作.这是存储在FreeRADIUS配置文件中的纯文本密码.所以显然不是解决方案,但它至少表明SBC通过MSCHAPv2正确地与RADIUS服务器通信.这和我上面提到的其他事情让我相信问题出在RADIUS服务器和域控制器之间.虽然在本地登录服务器时,NTLM身份验证在Windows RADIUS和FreeRADIUS服务器上都能正常工作(可以通过测试帐户登录到Windows RADIUS,并且在使用ntlm_auth命令时只需用户名和密码即可在FreeRADIUS服务器上成功进行身份验证),作为RADIUS访问请求进入时,RADIUS服务器似乎都不会通过用户进行身份验证(FreeRADIUS使用我在本地登录时使用的相同ntlm_auth命令,但不是为命令提供用户名和密码,而是提供用户名和质询响应).

所以我会在这里结束这个帖子,但我会留意这个,如果有人发帖,它会通知我.如果有人发布解决方案或有评论,我会回复.