________________________________ From: Alan DeKok <aland@deployingradius.com>
See the debug output.
I checked the logs on the client (Microsoft-Windows-Wired-AutoConfig), and here's all I can get: Identity: DOMAIN\ User: adminpc Domain: DOMAIN ReasonCode: 0x50005 ReasonText: Explicit EAP error received. ErrorCode: 0x0 If I configure the client to only do TLV checking, but disable hiding the identity, etc. then the only item that changes in the log above is the identity: Identity: DOMAIN\adminpc The error is still the same. Doesn't ReasonText imply that the Radius server is actually sending back an EAP error? If I go back to the FreeRadius server log (after fixing the unrelated eap issue where 2 accepts were found) I cannot see FreeRadius rejecting anything. This part of the log was taken when the identity was anonymized: (9) Received Access-Request Id 0 from 10.215.147.140:49154 to 10.215.144.91:1812 length 147 (9) NAS-IP-Address = 10.215.147.140 (9) NAS-Port-Type = Ethernet (9) NAS-Port = 43 (9) User-Name = "DOMAIN\\" (9) State = 0xb9970e47b1841752fc0ab043de592bf3 (9) Calling-Station-Id = "DC-4A-3E-06-11-46" [...] (9) suffix: Checking for suffix after "@" (9) suffix: No '@' in User-Name = "DOMAIN\", looking up realm NULL (9) suffix: No such realm "NULL" (9) [suffix] = noop (9) ntdomain: Checking for prefix before "\" (9) ntdomain: Looking up realm "DOMAIN" for User-Name = "DOMAIN\" (9) ntdomain: No such realm "DOMAIN" (9) [ntdomain] = noop (9) [expiration] = noop (9) [logintime] = noop (9) } # authorize = updated (9) Found Auth-Type = eap (9) # Executing group from file /etc/raddb/sites-enabled/default (9) authenticate { (9) eap: Expiring EAP session with state 0xb9970e47b1841752 (9) eap: Finished EAP session with state 0xb9970e47b1841752 (9) eap: Previous EAP request found for state 0xb9970e47b1841752, released from the list (9) eap: Peer sent packet with method EAP PEAP (25) (9) eap: Calling submodule eap_peap to process data (9) eap_peap: Continuing EAP-TLS (9) eap_peap: [eaptls verify] = ok (9) eap_peap: Done initial handshake (9) eap_peap: [eaptls process] = ok (9) eap_peap: Session established. Decoding tunneled attributes (9) eap_peap: PEAP state send tlv success (9) eap_peap: Received EAP-TLV response (9) eap_peap: Client rejected our response. The password is probably incorrect (9) eap_peap: ERROR: We sent a success, but the client did not agree (9) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (9) eap: Sending EAP Failure (code 4) ID 19 length 4 (9) eap: Failed in EAP select (9) [eap] = invalid (9) } # authenticate = invalid (9) Failed to authenticate the user This part of another log was taken when the identity was not anonymized: (9) Received Access-Request Id 0 from 10.215.147.140:49154 to 10.215.144.91:1812 length 154 (9) NAS-IP-Address = 10.215.147.140 (9) NAS-Port-Type = Ethernet (9) NAS-Port = 43 (9) User-Name = "DOMAIN\\adminpc" (9) State = 0x943e2c5d9c3435d7647a443b67c2cb70 (9) Calling-Station-Id = "DC-4A-3E-06-11-46" [...] (9) suffix: Checking for suffix after "@" (9) suffix: No '@' in User-Name = "DOMAIN\adminpc", looking up realm NULL (9) suffix: No such realm "NULL" (9) [suffix] = noop (9) ntdomain: Checking for prefix before "\" (9) ntdomain: Looking up realm "DOMAIN" for User-Name = "DOMAIN\adminpc" (9) ntdomain: No such realm "DOMAIN" (9) [ntdomain] = noop (9) [expiration] = noop (9) [logintime] = noop (9) } # authorize = updated (9) Found Auth-Type = eap (9) # Executing group from file /etc/raddb/sites-enabled/default (9) authenticate { (9) eap: Expiring EAP session with state 0x943e2c5d9c3435d7 (9) eap: Finished EAP session with state 0x943e2c5d9c3435d7 (9) eap: Previous EAP request found for state 0x943e2c5d9c3435d7, released from the list (9) eap: Peer sent packet with method EAP PEAP (25) (9) eap: Calling submodule eap_peap to process data (9) eap_peap: Continuing EAP-TLS (9) eap_peap: [eaptls verify] = ok (9) eap_peap: Done initial handshake (9) eap_peap: [eaptls process] = ok (9) eap_peap: Session established. Decoding tunneled attributes (9) eap_peap: PEAP state send tlv success (9) eap_peap: Received EAP-TLV response (9) eap_peap: Client rejected our response. The password is probably incorrect (9) eap_peap: ERROR: We sent a success, but the client did not agree (9) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (9) eap: Sending EAP Failure (code 4) ID 10 length 4 (9) eap: Failed in EAP select (9) [eap] = invalid (9) } # authenticate = invalid (9) Failed to authenticate the user Correct me if I'm wrong, but it seems to me that both the client and the server are blaming each other. Vieri