Hi, I've looked at the debug output and can see that the Stripped-User-Name is being cached from the first authentication, 9) Found Auth-Type = eap (9) # Executing group from file /etc/raddb/sites-enabled/default (9) authenticate { (9) eap: Expiring EAP session with state 0x42a9f52b4aa0ecd4 (9) eap: Finished EAP session with state 0x42a9f52b4aa0ecd4 (9) eap: Previous EAP request found for state 0x42a9f52b4aa0ecd4, 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: Success (9) eap_peap: caching Stripped-User-Name = "xxxxxx" (9) eap_peap: Failed to find 'persist_dir' in TLS configuration. Session will not be cached on disk. (9) eap: Sending EAP Success (code 3) ID 9 length 4 (9) eap: Freeing handler (9) [eap] = ok (9) } # authenticate = ok (9) # Executing section post-auth from file /etc/raddb/sites-enabled/default (9) post-auth { (9) update { (9) &reply::Stripped-User-Name += &session-state:Stripped-User-Name[*] -> 'xxxxxx' (9) } # update = noop (9) [exec] = noop (9) policy remove_reply_message_if_eap { (9) if (&reply:EAP-Message && &reply:Reply-Message) { (9) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (9) else { (9) [noop] = noop (9) } # else = noop (9) } # policy remove_reply_message_if_eap = noop (9) } # post-auth = noop (9) Sent Access-Accept Id 9 from 127.0.0.1:1812 to 127.0.0.1:46784 length 0 (9) MS-MPPE-Recv-Key = 0x8177f0129e6382a40366474afcbf0ce1aecbfc27dfae28446e9818664682c13e (9) MS-MPPE-Send-Key = 0x84de4618d9d1bd713ed21ac4f65c10aa1929f907307f5ffa5e09bccbe4096786 (9) EAP-Message = 0x03090004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) Finished request Am I correct in think that a subsequent authentication from the same client should result in the server looking in the cache for a SSL session id. If it finds a match the server should skip phase2 for that authentication? There's no indication in the debug output that the server checks the cache. Thanks, Chris
On 1 Feb 2017, at 08:37, Chris Howley <c.p.howley@LEEDS.AC.UK> wrote:
(9) eap_peap: Failed to find 'persist_dir' in TLS configuration. Session will not be cached on disk.
You've broken the configuration again - it's never going to find a cached session because you've deleted the line that tells it where to save them. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
participants (2)
-
Adam Bishop -
Chris Howley