使用 Realm 的 FreeRadius MSCHAP 身份验证失败

使用 Realm 的 FreeRadius MSCHAP 身份验证失败

我有 FreeRadius 2.0 服务器,以 AD 作为用户存储。使用 EAP-PEAP-MSCHAP2 进行身份验证。本地领域在 proxy.conf 中定义。身份验证工作正常,无需将领域添加到用户名中。只要我使用带有领域的用户名进行身份验证,即[电子邮件保护],身份验证失败。失败的原因很明显,失败是因为 radius 服务器 mschap 模块使用包含域的用户名创建质询哈希。我需要 radius mschap 模块从剥离的用户名(即不包含域的用户名)创建哈希。有什么想法吗?请参阅下面的 radius 调试日志:

rad_recv: Access-Request packet from host 192.168.1.254 port 55769, id=138, length=376
    Service-Type = Framed-User
    Framed-MTU = 1400
    User-Name = "[email protected]"
    State = 0x3ce95d9d3fed44ec4019661d07f2a324
    NAS-Port-Id = "wlan1"
    NAS-Port-Type = Wireless-802.11
    Calling-Station-Id = "5C-3C-27-29-AE-0B"
    Called-Station-Id = "D4-CA-6D-A6-53-7B:eduroam test"
    EAP-Message = 0x020400d01980000000c61603010086100000820080791cc56766422be7f48414f5942dda519afd607aea2fae890f9236e8af61cf71c66f4f80a5d427672d7f949a3fa163b959f0f1957f382f533a3f9c23d576dafcb5d36ca04dc7d0002203513a23b9394b75cf98f241a6c585583593f6622829a39a736160f0f83b567fa7bbc253558191630071d1889827f6118f366040f69d8814030100010116030100307173492977a9f772a302c0ecb7d2612700f9433dce8e08ff0e74b84dbc62de5fe5a95921f364f8c68dd38484550022ae
    Message-Authenticator = 0x9a61469cb26792ebd980f294bd9a64c9
    NAS-Identifier = "MikroTik"
    NAS-IP-Address = 192.168.1.254
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
[auth_log]  expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.1.254/auth-detail-20140313
[auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.1.254/auth-detail-20140313
[auth_log]  expand: %t -> Thu Mar 13 16:17:17 2014
++[auth_log] returns ok
++[mschap] returns noop
[suffix] Looking up realm "contoso.local" for User-Name = "[email protected]"
[suffix] Found realm "contoso.local"
[suffix] Adding Stripped-User-Name = "user5"
[suffix] Adding Realm = "contoso.local"
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
[eap] EAP packet type response id 4 length 208
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
  TLS Length 198
[peap] Length Included
[peap] eaptls_verify returned 11 
[peap] <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange  
[peap]     TLS_accept: SSLv3 read client key exchange A
[peap] <<< TLS 1.0 ChangeCipherSpec [length 0001]  
[peap] <<< TLS 1.0 Handshake [length 0010], Finished  
[peap]     TLS_accept: SSLv3 read finished A
[peap] >>> TLS 1.0 ChangeCipherSpec [length 0001]  
[peap]     TLS_accept: SSLv3 write change cipher spec A
[peap] >>> TLS 1.0 Handshake [length 0010], Finished  
[peap]     TLS_accept: SSLv3 write finished A
[peap]     TLS_accept: SSLv3 flush data
[peap]     (other): SSL negotiation finished successfully
SSL Connection Established 
[peap] eaptls_process returned 13 
[peap] EAPTLS_HANDLED

答案1

问题在于内部隧道虚拟服务器没有剥离领域。为了解决这个问题,我在内部隧道中指定了后缀命令,如下所示:

server inner-tunnel {
   authorize {
     ...
     suffix
     ...
   }
}

相关内容