跟现场确认，现场认证的账号是从通用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[2017011@fjtcm.edu.cn,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获取明文密码；