VLAN assignment to HP Switch with 802.1x client

[Phil Mayers]

On 08/08/13 16:16, Shaw, Colin M. wrote:
> Thanks for the reply Phil.
>
>>> difference. Lastly, for testing purposes, if I insert the required
>>> attributes into the default post-auth then it all works and the wired
>>> client is assigned the correct vlan, so again the switch side must be
>>> ok and I also therefore presume all the dictionary entries are there
>>> as required. But I shouldn't need (or want) to do this.
>>
>> Yes you should. You should always aim to set these attributes in post-auth;
>> otherwise you'll see what you are seeing, the attributes getting set in access-
>> challenge. This is a function of how EAP is processed by the server.
>
> Ok, but the attribute values are going to be different for different clients (as matched & specified in the users file). Can I deal with that in post-auth?

Sure. Exactly how is a very open question - "it depends". However, 
that's not *exactly* your problem - see below.

>
> Ok. Below is an example of the output from the switch debug and radiusd -x (

The *specific* reason this isn't working for you is that you have a 
config like this (and I'll grant you - this is not obvious unless you 
know what to look for):

authorize {
   ...
   eap {
     ok = return
   }
   files
   ...
}

...and because EAP returns "ok" on every pass other than the first, your 
"files" module isn't getting called in the final pass, so the attributes 
are absent from the Access-Accept.

First packet:

[eap] EAP packet type response id 1 length 24
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry DEFAULT at line 20
++[files] returns ok
++[expiration] returns noop

...and all other packets:

[eap] EAP packet type response id 2 length 137
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP

The "ok = return" bit of EAP is designed to let people avoid running 
costly modules, like SQL and LDAP, on every pass through the server 
during EAP session setup, but it's catching you out here.

You could move "files" above "eap" but IMO it's better (cleaner, more 
obvious) to run this in post-auth like so:

authorize {
   ...
   eap {
     ok = return
   }
   ...
}
post-auth {
   ...
   files
   ...
}

Note that you'll need to set the "postauth_usersfile" on your "files" 
instance. Alternatively, you can cheat and call the "authorize" section 
of the module:

post-auth {
   ...
   files.authorize
   ...
}

...which is a handy trick for things like SQL and LDAP.

I should add that you're also setting these attributes in the outer 
tunnel, so your setting of "use_tunneled_reply" is not relevant. 
However, people typically set these in the inner tunnel virtual server. 
The reason is that the outer tunnel may see an empty/anonymous username 
(if your config allows that, which is good practice for privacy). The 
inner tunnel OTOH has the real auth username.