On 11 Feb 2014, at 08:36, Stefan Winter <stefan.winter@restena.lu> wrote:
Hello,
so, now that session resumption works, there seems to be an error in the calculation of Chargeable-User-Identity in the *reauth* of tunneled methods (tried PEAP).
Here is a full -Xxx debug log to show the xlat parser sequence:
The input in both the auth and re-auth is an Access-Request with Operator-Name = "1restena.lu" Chargeable-User-Identity=\0 User-Name (outer) = "availability-test@education.lu"
In phase 2 during auth, the actual inner User-Name is then "test.eduroam@education.lu". This is correctly memorised by the session cache logic.
At first auth:
The (default) salt "changeme", the inner User-Name and the Operator-Name value trigger the calculation and returning of CUI. The calculated value is
Chargeable-User-Identity = '5a91e08fc9760dca96a311ccb333e2b8737ad600'
which I think is correct.
During re-auth, I see the line:
eap_peap : Adding cached attributes for session 8443da65e46717de420e76b52167eced7712da034f9cee7bef1cffb899a7209d: User-Name = 'test.eduroam@education.lu'
so during reauth time, the username to be used is known prior to the calculation of the reauth CUI.
And yet:
expand: "%{sha1:changeme%{tolower:%{User-Name}}%{%{Operator-Name}:-}}" -> 'ad40aca101096cde0ce27b387939e4c76d8234ca'
This is not what one needs.
I suspect that this construct uses the request:User-Name (availability-test@education.lu) instead of the retrieved session's (test.eduroam@education.lu).
I wonder how to correctly reference the "inner" User-Name. Since there is no phase 2 (but a fake attribute list for that phase 2) would inner.User-Name work? Or use reply:User-Name explicitly?
One of those two should fix the situation if writing
"%{sha1:changeme%{tolower:%{%{reply:User-Name}:-%{User-Name}}}%{%{Operator-Name}:-}}"
The reply (or maybe inner) part of it would work for the retrieved fake phase2 id, and for methods with no tunnel at all (say EAP-TLS) it would get expanded to the normal User-Name as before.
Is my argumentation sound? And the fix reasonable?
I don’t recalculate the CUI for cached sessions, instead I store the CUI in the cache: In the outer post-auth: if ( reply:Cached-Session-Policy ) { # # retrieve CUI for cached session (else to cache) # if ( reply:Cached-Session-Policy =~ /cui=(.+)/ ) { update reply { Reply-Message += "Cached policy: %{reply:Cached-Session-Policy}" Chargeable-User-Identity := "%{1}" } } elsif (reply:Chargeable-User-Identity) { update reply { Cached-Session-Policy := "cui=%{reply:Chargeable-User-Identity}" } } # # retrieve VLAN attribute for a resumed EAP Session # if ( reply:Cached-Session-Policy =~ /vlan=(.+)/ ) { update reply { Reply-Message += "Cached policy: %{reply:Cached-Session-Policy}" Tunnel-Private-Group-ID := "%{1}" Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Session-Timeout = 28800 Termination-Action = RADIUS-Request } } } In the inner the Cached-session-policy is always created when the VLAN is assigned (by a perl script): ##################### # RETURN ATTRIBUTES # ##################### $RAD_REPLY{'Tunnel-Medium-Type'} = "IEEE-802"; $RAD_REPLY{'Tunnel-Type'} = "VLAN"; $RAD_REPLY{'Tunnel-Private-Group-Id'} = "$returnVlan"; # return vlan $RAD_REPLY{'Session-Timeout'} = "28800"; # 8 hours $RAD_REPLY{'Termination-Action'} = "RADIUS-Request"; # store return vlan in eap cache for # session resumption $RAD_REPLY{'Cached-Session-Policy'} = "vlan=$returnVlan"; return RLM_MODULE_UPDATED; Regards Scott