Problem with using inner User-Name in outgoing Access-Accept packet
Hi, I’m having a bit of trouble with getting the inner-tunnel username to appear in the outgoing Access-Accept packet. Background info FR 3.0.19 Collaboration with York City council to provide eduroam in city centre. As auth and traffic comes via us we need then to send appropriate accounting info back to us hence the need to pass back a valid username in the access-accept instead of just an anonymous one Am using sesion-state to pass inner User-Name back to the outer reply I’ve selectively enabled debugging at both the inner and outer level just for auth requests that have an outer anonymous user-name of @york.ac.uk. and an inner User-Name of <fred>@york.ac.uk. For those people that haven’t configured their clients properly and have outer=inner=userid@york.ac.uk … stuff works :-( Long and short of it is I can either have the anonymous outer realm in the access-accept user-name or have both the outer and inner user-names in the access accept packet which is illegal. What am I doing wrong? Rgds Alex Outer processing as shown below ////////////////////// # Post-Authentication # Once we KNOW that the user has been authenticated, there are # additional steps we can take. post-auth { # # We might have to debug some traffic # if ( ("%{client:shortname}" == "yorkcc") && (User-Name == "@ york.ac.uk") ) { update control { Tmp-String-2 := "%{debug:1}" } } # # If you need to have a State attribute, you can # add it here. e.g. for later CoA-Request with # State, and Service-Type = Authorize-Only. # # if (!&reply:State) { # update reply { # State := "0x%{randstr:16h}" # } # } # # For EAP-TTLS and PEAP, add the cached attributes to the reply. # The "session-state" attributes are automatically cached when # an Access-Challenge is sent, and automatically retrieved # when an Access-Request is received. # # The session-state attributes are automatically deleted after # an Access-Reject or Access-Accept is sent. # # If both session-state and reply contain a User-Name attribute, remove # the one in the reply if it is just a copy of the one in the request, so # we don't end up with two User-Name attributes. if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name) ) { update reply { User-Name !* ANY } } # Just to make really sure update reply { User-Name !* ANY } # if ( session-state:User-Name !="@york.ac.uk" && session-state:User-Name =~ /york.ac.uk$/i) { # update reply { # User-Name := session-state:User-Name # } # } # # So this should put the inner User-name into the reply ... but it doesn't # update { &reply: += &session-state: } # Get an address from the IP Pool. # main_pool # Create the CUI value and add the attribute to Access-Accept. # Uncomment the line below if *returning* the CUI. cui # Create empty accounting session to make simultaneous check # more robust. See the accounting queries configuration in # raddb/mods-config/sql/main/*/queries.conf for details. # # The "sql_session_start" policy is defined in # raddb/policy.d/accounting. See that file for more details. # sql_session_start # # If you want to have a log of authentication replies, # un-comment the following line, and enable the # 'detail reply_log' module. # reply_log # # After authenticating the user, do another SQL query. # # See "Authentication Logging Queries" in mods-available/sql # # Instead of sending the query to the SQL server, # write it into a log file. # # sql_log # # Un-comment the following if you want to modify the user's object # in LDAP after a successful login. # # ldap # For Exec-Program and Exec-Program-Wait exec # # Calculate the various WiMAX keys. In order for this to work, # you will need to define the WiMAX NAI, usually via # # update request { # WiMAX-MN-NAI = "%{User-Name}" # } # # If you want various keys to be calculated, you will need to # update the reply with "template" values. The module will see # this, and replace the template values with the correct ones # taken from the cryptographic calculations. e.g. # # update reply { # WiMAX-FA-RK-Key = 0x00 # WiMAX-MSK = "%{EAP-MSK}" # } # # You may want to delete the MS-MPPE-*-Keys from the reply, # as some WiMAX clients behave badly when those attributes # are included. See "raddb/modules/wimax", configuration # entry "delete_mppe_keys" for more information. # # wimax # If there is a client certificate (EAP-TLS, sometimes PEAP # and TTLS), then some attributes are filled out after the # certificate verification has been performed. These fields # MAY be available during the authentication, or they may be # available only in the "post-auth" section. # # The first set of attributes contains information about the # issuing certificate which is being used. The second # contains information about the client certificate (if # available). # # update reply { # Reply-Message += "%{TLS-Cert-Serial}" # Reply-Message += "%{TLS-Cert-Expiration}" # Reply-Message += "%{TLS-Cert-Subject}" # Reply-Message += "%{TLS-Cert-Issuer}" # Reply-Message += "%{TLS-Cert-Common-Name}" # Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}" # # Reply-Message += "%{TLS-Client-Cert-Serial}" # Reply-Message += "%{TLS-Client-Cert-Expiration}" # Reply-Message += "%{TLS-Client-Cert-Subject}" # Reply-Message += "%{TLS-Client-Cert-Issuer}" # Reply-Message += "%{TLS-Client-Cert-Common-Name}" # Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}" # } # Insert class attribute (with unique value) into response, # aids matching auth and acct records, and protects against duplicate # Acct-Session-Id. Note: Only works if the NAS has implemented # RFC 2865 behaviour for the class attribute, AND if the NAS # supports long Class attributes. Many older or cheap NASes # only support 16-octet Class attributes. insert_acct_class # MacSEC requires the use of EAP-Key-Name. However, we don't # want to send it for all EAP sessions. Therefore, the EAP # modules put required data into the EAP-Session-Id attribute. # This attribute is never put into a request or reply packet. # # Uncomment the next few lines to copy the required data into # the EAP-Key-Name attribute # if (&reply:EAP-Session-Id) { # update reply { # EAP-Key-Name := &reply:EAP-Session-Id # } # } # Remove reply message if the response contains an EAP-Message remove_reply_message_if_eap # # Access-Reject packets are sent through the REJECT sub-section of the # post-auth section. # # Add the ldap module name (or instance) if you have set # 'edir_account_policy_check = yes' in the ldap module configuration # # The "session-state" attributes are not available here. # Post-Auth-Type REJECT { # log failed authentications in SQL, too. if (User-Name != "cisco-probe") { detail-filebeat -sql } attr_filter.access_reject # Insert EAP-Failure message if the request was # rejected by policy instead of because of an # authentication failure eap # Remove reply message if the response contains an EAP-Message remove_reply_message_if_eap } # # Filter access challenges. # Post-Auth-Type Challenge { # remove_reply_message_if_eap # attr_filter.access_challenge.post-auth } } ///////////////////// The debugging inn radius log shows an ear auth request with an access-accepts packet with a User-Name of @york.ac.uk see below. If I enabled auth_log I’d see the same thing Wed Jul 3 15:43:17 2019 : Debug: (924582) Virtual server inner-tunnel received request Wed Jul 3 15:43:17 2019 : Debug: (924582) EAP-Message = 0x020a00061a03 Wed Jul 3 15:43:17 2019 : Debug: (924582) FreeRADIUS-Proxied-To = 127.0.0.1 Wed Jul 3 15:43:17 2019 : Debug: (924582) User-Name = "em878@york.ac.uk" Wed Jul 3 15:43:17 2019 : Debug: (924582) State = 0xdcc2c059ddc8da2ddc351a9518782ae0 Wed Jul 3 15:43:17 2019 : Debug: (924582) server inner-tunnel { Wed Jul 3 15:43:17 2019 : Debug: (924582) # Executing section authorize from file /etc/freeradius/sites-enabled/inner-tunnel Wed Jul 3 15:43:17 2019 : Debug: (924582) # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel Wed Jul 3 15:43:17 2019 : Debug: (924582) eap: Expiring EAP session with state 0xcce8732ccce16987 Wed Jul 3 15:43:17 2019 : Debug: (924582) eap: Finished EAP session with state 0xdcc2c059ddc8da2d Wed Jul 3 15:43:17 2019 : Debug: (924582) eap: Previous EAP request found for state 0xdcc2c059ddc8da2d, released from the list Wed Jul 3 15:43:17 2019 : Debug: (924582) # Executing section post-auth from file /etc/freeradius/sites-enabled/inner-tunnel Wed Jul 3 15:43:17 2019 : Debug: (924582) sql: SQL query returned: success Wed Jul 3 15:43:17 2019 : Debug: (924582) sql: 1 record(s) updated Wed Jul 3 15:43:17 2019 : Auth: (924582) Login OK: [em878@york.ac.uk] (from client yorkcc port 0 via TLS tunnel) Wed Jul 3 15:43:17 2019 : Debug: (924582) } # server inner-tunnel Wed Jul 3 15:43:17 2019 : Debug: (924582) Virtual server sending reply Wed Jul 3 15:43:17 2019 : Debug: (924582) Chargeable-User-Identity := 0x65323133646431353864366238373633383037396534656632373539383264386439363136623863 Wed Jul 3 15:43:17 2019 : Debug: (924582) eap: EAP session adding &reply:State = 0x6782f4146d89edcd Wed Jul 3 15:43:17 2019 : Debug: (924582) # Executing group from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 15:43:17 2019 : Debug: (924582) TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384" Wed Jul 3 15:43:17 2019 : Debug: (924582) TLS-Session-Version = "TLS 1.2" Wed Jul 3 15:43:17 2019 : Debug: (924582) User-Name := "em878@york.ac.uk" Wed Jul 3 15:43:17 2019 : Debug: (924582) Chargeable-User-Identity += 0x65323133646431353864366238373633383037396534656632373539383264386439363136623863 Wed Jul 3 15:43:17 2019 : Debug: (924582) Sent Access-Challenge Id 77 from 144.32.129.2:1812 to 10.237.0.3:40803 length 0 Wed Jul 3 15:43:17 2019 : Debug: (924582) EAP-Message = 0x010b002e1900170303002353ff18d19f60e380f99ac2de9f86b64211108cd7e8ba6fdf64afc0fb7c6e1638ad466f Wed Jul 3 15:43:17 2019 : Debug: (924582) Message-Authenticator = 0x00000000000000000000000000000000 Wed Jul 3 15:43:17 2019 : Debug: (924582) State = 0x6782f4146d89edcd473492427f93e0e2 Wed Jul 3 15:43:17 2019 : Debug: (924583) # Executing group from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 15:43:17 2019 : Debug: (924583) eap: Expiring EAP session with state 0xcce8732ccce16987 Wed Jul 3 15:43:17 2019 : Debug: (924583) eap: Finished EAP session with state 0x6782f4146d89edcd Wed Jul 3 15:43:17 2019 : Debug: (924583) eap: Previous EAP request found for state 0x6782f4146d89edcd, released from the list Wed Jul 3 15:43:17 2019 : Debug: (924583) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 15:43:17 2019 : Debug: (924583) cuisql: SQL query returned: success Wed Jul 3 15:43:17 2019 : Debug: (924583) cuisql: 0 record(s) updated Wed Jul 3 15:43:17 2019 : Debug: (924583) cuisql: No additional queries configured Wed Jul 3 15:43:17 2019 : Debug: (924583) sql: SQL query returned: success Wed Jul 3 15:43:17 2019 : Debug: (924583) sql: 1 record(s) updated Wed Jul 3 15:43:17 2019 : Auth: (924583) Login OK: [@york.ac.uk] (from client yorkcc port 32 cli A8-5C-2C-51-B6-93) Wed Jul 3 15:43:17 2019 : Debug: (924583) Sent Access-Accept Id 78 from 144.32.129.2:1812 to 10.237.0.3:40803 length 0 Wed Jul 3 15:43:17 2019 : Debug: (924583) MS-MPPE-Recv-Key = 0xdd0b78bdc3d590ab0f52b72a6249c0cb737d5be7ceab405265a8f60d6a9ce835 Wed Jul 3 15:43:17 2019 : Debug: (924583) MS-MPPE-Send-Key = 0xa84727723cbe1877c2d43913627ccb09c3d960e4729ec04fec6f127bec384b70 Wed Jul 3 15:43:17 2019 : Debug: (924583) EAP-Message = 0x030b0004 Wed Jul 3 15:43:17 2019 : Debug: (924583) Message-Authenticator = 0x00000000000000000000000000000000 Wed Jul 3 15:43:17 2019 : Debug: (924583) User-Name := "@york.ac.uk" Wed Jul 3 15:43:17 2019 : Debug: (924583) Chargeable-User-Identity += 0x65323133646431353864366238373633383037396534656632373539383264386439363136623863 Wed Jul 3 15:43:17 2019 : Debug: (924583) Class = 0x656475726f616d312e796f726b2e61632e756b61693a3564333131653730306537613431663661643362343666323863646236313239 /////////// If I explicitly add the session-state User-Name value to the reply packet by uncommenting the # if ( session-state:User-Name !="@york.ac.uk" && session-state:User-Name =~ /york.ac.uk$/i) { # update reply { # User-Name := session-state:User-Name # } # } Then what I get are two User-Names in the Access -Accept packet.. both the outer and the inner … see below Wed Jul 3 16:13:26 2019 : Auth: (9706) Login OK: [kp951@york.ac.uk] (from client yorkcc port 0 via TLS tunnel) Wed Jul 3 16:13:26 2019 : Debug: (9706) } # server inner-tunnel Wed Jul 3 16:13:26 2019 : Debug: (9706) Virtual server sending reply Wed Jul 3 16:13:26 2019 : Debug: (9706) Chargeable-User-Identity := 0x33386639326231363161646238323162336336646461313566373563316230326233323163643263 Wed Jul 3 16:13:26 2019 : Debug: (9706) eap: EAP session adding &reply:State = 0x4d9c1fde47970696 Wed Jul 3 16:13:26 2019 : Debug: (9706) # Executing group from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 16:13:26 2019 : Debug: (9706) TLS-Session-Cipher-Suite = "ECDHE-RSA-AES128-GCM-SHA256" Wed Jul 3 16:13:26 2019 : Debug: (9706) TLS-Session-Version = "TLS 1.2" Wed Jul 3 16:13:26 2019 : Debug: (9706) User-Name := "kp951@york.ac.uk" Wed Jul 3 16:13:26 2019 : Debug: (9706) Chargeable-User-Identity += 0x33386639326231363161646238323162336336646461313566373563316230326233323163643263 Wed Jul 3 16:13:26 2019 : Debug: (9706) Sent Access-Challenge Id 105 from 144.32.129.2:1812 to 10.237.0.3:35838 length 0 Wed Jul 3 16:13:26 2019 : Debug: (9706) EAP-Message = 0x010b002e19001703030023ebc680c47273a6f5925d906f94c12e86f19d43045b2b2a030efd6968dc6e715679ca85 Wed Jul 3 16:13:26 2019 : Debug: (9706) Message-Authenticator = 0x00000000000000000000000000000000 Wed Jul 3 16:13:26 2019 : Debug: (9706) State = 0x4d9c1fde47970696b6b09be82cc57d97 Wed Jul 3 16:13:26 2019 : Debug: (9708) # Executing group from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 16:13:26 2019 : Debug: (9708) eap: Expiring EAP session with state 0x2ce89ba92ce98291 Wed Jul 3 16:13:26 2019 : Debug: (9708) eap: Finished EAP session with state 0x4d9c1fde47970696 Wed Jul 3 16:13:26 2019 : Debug: (9708) eap: Previous EAP request found for state 0x4d9c1fde47970696, released from the list Wed Jul 3 16:13:26 2019 : Debug: (9708) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam Wed Jul 3 16:13:26 2019 : Debug: (9708) cuisql: SQL query returned: success Wed Jul 3 16:13:26 2019 : Debug: (9708) cuisql: 0 record(s) updated Wed Jul 3 16:13:26 2019 : Debug: (9708) cuisql: No additional queries configured Wed Jul 3 16:13:26 2019 : Debug: (9708) sql: SQL query returned: success Wed Jul 3 16:13:26 2019 : Debug: (9708) sql: 1 record(s) updated Wed Jul 3 16:13:26 2019 : Auth: (9708) Login OK: [@york.ac.uk] (from client yorkcc port 88 cli 24-18-1D-38-15-06) Wed Jul 3 16:13:26 2019 : Debug: (9708) Sent Access-Accept Id 106 from 144.32.129.2:1812 to 10.237.0.3:35838 length 0 Wed Jul 3 16:13:26 2019 : Debug: (9708) MS-MPPE-Recv-Key = 0xa2d4dd7ba73b43f9caa398ee2aec52ef4acb5568c70099a88582dd5a7ce79611 Wed Jul 3 16:13:26 2019 : Debug: (9708) MS-MPPE-Send-Key = 0x60347e94d1057b1ad051aff95b77af98fa4b1d56088e3b73ce307e7ae9b0ffe6 Wed Jul 3 16:13:26 2019 : Debug: (9708) EAP-Message = 0x030b0004 Wed Jul 3 16:13:26 2019 : Debug: (9708) Message-Authenticator = 0x00000000000000000000000000000000 Wed Jul 3 16:13:26 2019 : Debug: (9708) User-Name := "@york.ac.uk" Wed Jul 3 16:13:26 2019 : Debug: (9708) User-Name += "kp951@york.ac.uk" Wed Jul 3 16:13:26 2019 : Debug: (9708) Chargeable-User-Identity += 0x33386639326231363161646238323162336336646461313566373563316230326233323163643263 Wed Jul 3 16:13:26 2019 : Debug: (9708) Class = 0x656475726f616d312e796f726b2e61632e756b61693a3839616465343166376130313464353535356464663466313739306565663432
On Jul 3, 2019, at 5:45 PM, Alex Sharaz via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I’m having a bit of trouble with getting the inner-tunnel username to appear in the outgoing Access-Accept packet.
It should mostly happen automatically in the default configuration.
Am using sesion-state to pass inner User-Name back to the outer reply
That should work.
I’ve selectively enabled debugging at both the inner and outer level just for auth requests that have an outer anonymous user-name of @york.ac.uk. and an inner User-Name of <fred>@york.ac.uk. For those people that haven’t configured their clients properly and have outer=inner=userid@york.ac.uk … stuff works :-(
Not good.
if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name) ) {
update reply {
User-Name !* ANY
}
}
# Just to make really sure
update reply {
User-Name !* ANY
}
That shouldn't be needed. The default configuration in v3 sends the User-Name back in the Access-Accept. See the comments in sites-available/default, in the "post-auth" section.
If I explicitly add the session-state User-Name value to the reply packet by uncommenting the
# if ( session-state:User-Name !="@york.ac.uk" && session-state:User-Name =~ /york.ac.uk$/i) {
# update reply {
# User-Name := session-state:User-Name
# }
# }
Then what I get are two User-Names in the Access -Accept packet.. both the outer and the inner … see below
Yes, the default configuration has explanations for this. It describes when this happens, and why the default configuration does what it does. Look at the default config. It works. Alan DeKok.
Sigh! And actually it was doing the right thing. If you look at the cut policy it says …. cui.post-auth { if (!&control:Proxy-To-Realm && &Chargeable-User-Identity && !&reply:Chargeable-User-Identity && \ (&Operator-Name || ('${policy.cui_require_operator_name}' != 'yes')) ) { update reply { &Chargeable-User-Identity = "%{sha1:${policy.cui_hash_key}%{tolower:%{User-Name}%{%{Operator-Name}:-}}}" } } # # The section below will store a CUI for the User in the DB and remove the # User-Name attribute from the reply if a CUI is present. # # You need to configure the cuisql module and your database for this to work. # If your NAS can do CUI based accounting themselves or you do not care about # accounting, comment out the 'cuisql' line below. # if (&reply:Chargeable-User-Identity) { # Force User-Name to be the User-Name from the request update { &reply:User-Name := &request:User-Name } cuisql } } ….. the key bit being if (&reply:Chargeable-User-Identity) { ….. So as I was generating a CUI in the inner-tunnel and pushing it up to the outer, the reply name was being set to @york.ac.uk,
On 3 Jul 2019, at 18:24, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 3, 2019, at 5:45 PM, Alex Sharaz via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I’m having a bit of trouble with getting the inner-tunnel username to appear in the outgoing Access-Accept packet.
It should mostly happen automatically in the default configuration.
Am using sesion-state to pass inner User-Name back to the outer reply
That should work.
I’ve selectively enabled debugging at both the inner and outer level just for auth requests that have an outer anonymous user-name of @york.ac.uk. and an inner User-Name of <fred>@york.ac.uk. For those people that haven’t configured their clients properly and have outer=inner=userid@york.ac.uk … stuff works :-(
Not good.
if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name) ) {
update reply {
User-Name !* ANY
}
}
# Just to make really sure
update reply {
User-Name !* ANY
}
That shouldn't be needed.
The default configuration in v3 sends the User-Name back in the Access-Accept. See the comments in sites-available/default, in the "post-auth" section.
If I explicitly add the session-state User-Name value to the reply packet by uncommenting the
# if ( session-state:User-Name !="@york.ac.uk" && session-state:User-Name =~ /york.ac.uk$/i) {
# update reply {
# User-Name := session-state:User-Name
# }
# }
Then what I get are two User-Names in the Access -Accept packet.. both the outer and the inner … see below
Yes, the default configuration has explanations for this. It describes when this happens, and why the default configuration does what it does.
Look at the default config. It works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Alex Sharaz