Issues with Cached-Session-Policy in versions of FR after 3.0.8.

[Brian Julin]

J.D.F. [j.d.f.palmer at swansea.ac.uk] wrote:
> This works in V3.0.8, Tmp-String-1 is set to the stripped username from the saved session, but not in versions after  this.

> Is there a better/another way to recover the username for use within site-enabled/default during fast re-auth / session resumption?

There's a new generic session state cache mechanism that interacts in fun ways with the TLS session state
caching.  Our setup is a bit more complicated probably than yours, and I can't share the whole thing without a
massive edit, but hopefully these are enough clues to give you something to work with:

  authorize {
    preprocess
    # eap will set Auth-Type
    update {
      # These are all the attributes SSL session resumption supports.
      # That might eventually move to use the generic state mechanism
      # but for now they have to be moved to the request to be cached
      # via TLS session ID, and we have to do this before the we hit
      # eap in the next authorize section, which does not go into the
      # inner server on the last packet.
      #
      # 1) &reply:User-Name stashed after mschap
      &reply:User-Name                  := &session-state:User-Name
      # 2) &request:Stripped-User-Name
      &request:Stripped-User-Name       := &session-state:Stripped-User-Name
      # 3) &request:Stripped-User-Domain we do not use
      # &request:Stripped-User-Domain   := &session-state:Stripped-User-Domain
      # 4) &reply:Chargeable-User-Identity we do not use on this SSID
      # &reply:Chargeable-User-Identity := &session-state:Chargeable-User-Identity
      # 5) &reply:Cached-Session-Policy also stashed earlier; we put stuff
      #    for other attributes in here.
      &reply:Cached-Session-Policy      := &session-state:Cached-Session-Policy
    }

...
  post-auth {
    Post-Auth-Type WIFI-OUTER {
      if (&reply:Cached-Session-Policy =~ /POLICY=([^;]+);UNAME=([^;]*);/) {
        # This section gets entered for new connects, not just TLS fast-reauths.
        # (We just pre-load this variable and then treat them all the same.)
        #
        # We need to pull two things from the TLS session cache because
        # the NAS has no way to get them without a full authentication.
        #
        # 1) What VLAN or policy to send the user to
        # 2) The username we originally sent when we accepted them
        # 3) The original AD username
        #
        # #3 is pulled out automatically for us, and we want to log it.
        # #2 should not be logged because it has dorm addresses in it,
        # but it is the one we want to send it back as the User-Name
        # so it matches what the NAC and NAS have on file.
        update {
          &reply:Tunnel-Private-Group-Id !* ANY
          &reply:Tunnel-Private-Group-Id := "%{1}"
          &control:User-Name := "%{2}"
        }
        do_track_log
        update reply {
          &User-Name !* ANY
          &User-Name := &control:User-Name
        }
       else {
         # This should actually not ever happen
...

    Post-Auth-Type Challenge {
      # In the case of a fast reauthentication, the TLS cached
      # attributes are in the reply, but not saved in the general
      # purpose session-state cache yet, because we never ran the
      # inner tunnel.  Fix that up by saving those attributes here
      # when we detect this situation.
      if (!session-state:Stripped-User-Name) {
        update {
          &session-state: += &reply:
          &session-state:Stripped-User-Name += &request:Stripped-User-Name
        }
        update session-state {
          &MS-MPPE-Encryption-Policy !* ANY
          &MS-MPPE-Encryption-Types !* ANY
          &MS-MPPE-Send-Key !* ANY
          &MS-MPPE-Recv-Key !* ANY
          &Message-Authenticator !* ANY
          &EAP-Message !* ANY
          &Proxy-State !* ANY
          &State !* ANY
        }
      }
      # And this deletes practically everything from the reply
      # since we don't want to send any actual attributes until
      # we are sending an Accept.
      access_challenge_filter
}

server inner {

    Autz-Type WIFI-INNER {
      update control {
        &Post-Auth-Type := WIFI-INNER
      }
      # eap will set Auth-Type before LDAP does, first-come-first-serve.
      eap {
        # We can skip the user access check on the first packet by
        # returning immediately when EAP returns "ok".  The other
        # two times it will return "updated".  This will skip all of
        # this rest of the "authorize" section.
        ok = return
      }
      # This has to be in the authorize section, it behaves differently
      # here and wil check if the user is flagged as WiFi eligible in
      # LDAP as configured in the module settings.  However, it will
      # get run needlessly on the second packet.  So, we cram an arbitrary
      # attribute into the state.  We cannot use the inner tunnel State
      # entry, because that will only get written to cache in post-auth,
      # which we are going to skip, so we put it in the outer session state,
      # which will be writen in server "backend"'s post-proxy section
      # because this will be an Access-Challenge and that's a special case.
      #
      # (Yes you have to read the code to know this stuff.)
      #
      # The first packet never gets here, the second packet we have not
      # put anything in the state yet, so it is empty, and after that
      # (which should only be once) we check LDAP for permission to use WiFi.
      if (&outer.session-state:XXX-LDAPType) {
          ldap_ds_wifi
      }
      update {
          &outer.session-state:XXX-LDAPType := "pleasedoldapnexttime"
      }
...

     post-auth {
      update reply {
        &Cached-Session-Policy := "POLICY=%{reply:Tunnel-Private-Group-Id};UNAME=XXX;
      }
      # Copy all the reply attributes from inner to outer, plus one
      # of the TLS fast reconnect items that come from the request
      # rather than the reply.
      update {
        &outer.session-state: += &reply:
        &outer.session-state:Stripped-User-Name += &request:Stripped-User-Name
      }
      # Clean the state of some important variables that internal code
      # is about to write to.  We don't want to have stacks of these.
      update outer.session-state {
        &MS-MPPE-Encryption-Policy !* ANY
        &MS-MPPE-Encryption-Types !* ANY
        &MS-MPPE-Send-Key !* ANY
        &MS-MPPE-Recv-Key !* ANY
        &Message-Authenticator !* ANY
        &EAP-Message !* ANY
        &Proxy-State !* ANY
        &State !* ANY
      }
     }


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html