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

4 Jul 2019

      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