LDAP服务器不支持chap认证,终端使用EIA进行PEAP-GTC认证失败的原因分析
跟现场确认，现场认证的账号是从通用LDAP服务器同步过来的，配置的是PEAP-GTC认证。让现场反馈认证时的UAM调试日志和抓包；首先分析UAM调试日志如下：
%% 2017-12-05 16:04:30.091 ; [LDBG] ; [11196] ; LAN ; 2017011@****.cn ; 1 ; 1593b1277566447c9b5a93c04581609c ; Received message from 10.252.11.84:
CODE = 1.///认证请求报文
ID = 168.
ATTRIBUTES:
User-Name(1) = "2017011@****.cn".
Service-Type(6) = 2.
Framed-Protocol(7) = 1.
NAS-Identifier(32) = "AC".
NAS-Port(5) = 33.
NAS-Port-Type(61) = 19.
NAS-Port-Id(87) = "VLANID=33;".
Calling-Station-Id(31) = "80-19-34-27-F8-1C".
Called-Station-Id(30) = "AC-74-09-67-**-**:eduroam".
Acct-Session-Id(44) = "00000004201712051603160000009016100482".
HW_NEW_USER_ATTRIBUTE_NAME(133) = "".
EAP-Message(79) = "02020019013230313730313140666a74636d2e6564752e636e".///01表示上传用户名
服务器随后根据服务器侧配置的接入策略名查询，发现该用户需要进行PEAP认证，并回应终端认证challenge。
%% 2017-12-05 16:04:30.092 ; [LDBG] ; [11164] ; EAP ; EapProc.handlr: outer fndEapType[[email protected],80:19:34:27:F8:1C,eduroam], eaptype:25, adaptmode:3.///25表示PEAP；
随后终端发起PEAP证书认证，并开始创建TLS隧道
%% 2017-12-05 16:04:30.097 ; [LDBG] ; [11196] ; LAN ; 2017011@****.cn ; 1 ; 94ebab3c17f14fb985df5662eabc9689 ; 917817df]......= ; Received message from 10.252.11.84:
CODE = 1.
ID = 169.
ATTRIBUTES:
User-Name(1) = "2017011@****.cn".
Service-Type(6) = 2.
Framed-Protocol(7) = 1.
NAS-Identifier(32) = "AC".
NAS-IP-Address(4) = 184290132.
NAS-Port(5) = 33.
NAS-Port-Type(61) = 19.
NAS-Port-Id(87) = "VLANID=33;".
Calling-Station-Id(31) = "80-19-34-27-F8-1C".
Called-Station-Id(30) = "AC-74-09-67-**-**:eduroam".
Acct-Session-Id(44) = "00000004201712051603160000009016100482".
HW_NEW_USER_ATTRIBUTE_NAME(133) = "".
EAP-Message(79) = "0203006d198000000063160301005e0100005a03015a26530e88ffb6082c3a7b198d6713a8838cf5c9f4fb24607bd5a57b37d0286e000018c014c0130035002fc///19表示PEAP认证
经过一系列报文交互，两端成功建立隧道。
%% 2017-12-05 16:04:30.161 ; [LDBG] ; [11180] ; EAP ; EapTlsAuth.procEapTls: end with OK - Received tunneled data after successful handshake.
两端隧道建立完成后接下来需要在隧道内协商第二阶段的认证类型，服务器侧根据配置查询到用户需要进行GTC认证，具体如下
%% 2017-12-05 16:04:30.161 ; [LDBG] ; [11180] ; EAP ; EapProc.handlr: inner fndEapType[2017011@****.cn,80:19:34:27:F8:1C,eduroam,tunnel:1], eaptype:25-[6].///6表示第二阶段采用GTC认证；
随后开始GTC的认证过程
%% 2017-12-05 16:04:30.161 ; [LDBG] ; [11180] ; EAP ; gtc.StartEap: Begin.
%% 2017-12-05 16:04:30.161 ; [LDBG] ; [11180] ; EAP ; gtc.StartEap: EAP-type [25-1].
%% 2017-12-05 16:04:30.161 ; [LDBG] ; [11180] ; EAP ; EapAuth.creatChalenge: Begin.
但是在随后的协商过程中，EIA将用户的认证类型由6切换成26,26表示走MSchapv2认证。原因是终端在认证过程中不同意服务器侧指定的GTC认证，于是返回了NAK(3)，并指定了新的认证类型MSchapv2(26)，具体如下面的日志。
%% 2017-12-05 16:04:30.165 ; [LDBG] ; [11160] ; EAP ; EapProc.handlr: eap-type 3, vendor-id 25506, login-name .///3表示不同意走GTC认证，随后选择了MSchapv2认证
%% 2017-12-05 16:04:30.165 ; [LDBG] ; [11160] ; EAP ; EapProc.handlr: no username in radius.
%% 2017-12-05 16:04:30.165 ; [LDBG] ; [11160] ; EAP ; EapProc.typeSelect: Begin.
%% 2017-12-05 16:04:30.165 ; [LDBG] ; [11160] ; EAP ; EapProc.typeSelect: EAP type shifted from 6 to 26.///26表示MSchapv2认证。
EIA将认证类型由6切换成26的原因是PC自带客户端不支持GTC认证，而服务器侧配置的EAP自协商又是启用状态，导致两端最后协商出来的类型是MSchapv2.
MSchapv2认证的情况下，EIA侧发现用户密码错误，随后拒绝用户认证，并提示密码错误。
%% 2017-12-05 16:04:30.180 ; [HINT] ; [11176] ; EAP ; MsChapV2.doMSChap: not getting through.
%% 2017-12-05 16:04:30.180 ; [ERR] ; [11176] ; EAP ; mschapv2.authn: MS-CHAP2-Response is incorrect, maybe due to wrong password.
终端切换到MSchapv2认证以后，由于此时密码加密不再可逆，此时就需要EIA可以从open ldap侧同步到明文密码，然后按照MSchapv2的加密方式加密后比对密文，但是现场通过抓包发现EIA成从open ldap服务器同步到的密码是经过SSHA加密的，此时EIA从终端和openldap服务器侧分别取到了两种经过不同加密方式加密的密文，自然无法比对密码，导致用户认证失败。手机端用该账号之所以可以上线是因为手机支持GTC认证，而GTC加密属于可逆加密，对于这种可逆加密的情况，EIA是可以成功比对密码的。同理本地账号可以通过认证也是因为EIA可以取到本地账号的明文密码。
最终可以得出结论：
PC端认证失败的原因是因为PC端不支持GTC认证且EIA无法从openldap获取明文密码；