Problem with using inner User-Name in outgoing Access-Accept packet

[Alex Sharaz]

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 at deployingradius.com> wrote:
> 
> On Jul 3, 2019, at 5:45 PM, Alex Sharaz via Freeradius-Users <freeradius-users at 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 at 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