EAP-TLV

[Vieri]

________________________________
From: Alan DeKok <aland at 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