Cisco Anyconnect 2FA

[Alan DeKok]

On Jan 10, 2017, at 4:25 PM, Stefan Schlesinger <sts at ono.at> wrote:
> 
> 
>> On 10 Jan 2017, at 16:17, Alan DeKok <aland at deployingradius.com> wrote:
>> In v3.0.12, cache the password in session-state.
> 
> 
> Is there a specific reason to use 3.0.12? The lastest available pre-build
> package I found is 3.0.11-1labs-1~jessie.

  It's trivial to build your own packages.  See the Wiki.

  And there are reasons to use 3.0.12.  Bug fixes, for one.

>> 	if (!&session-state:User-Password) {
>> 		update session-state {
>> 			User-Password := &request:User-Password
>> 		}
>> 	}
>> 	else {
>> 		# it's the second time around...
>> 	}
> 
> 
> This doesn’t work for me at the moment. Do I need to enable any other modules for
> session storage?

  No.

> How does Freeradius match the two requests in a single session. Does this work?

  It uses the State attribute, as per the RFC.

> 
> This is the initial request:
> 
> (0) Received Access-Request Id 170 from 10.30.9.1:8272 to 10.30.9.11:1812 length 611
> ...
> (0)     if (!&session-state:User-Password)  -> TRUE
> (0)     if (!&session-state:User-Password)  {
> (0)       update session-state {
> (0)         User-Password := request:User-Password -> ’xxxxx'
> (0)       } # update session-state = noop
> ...
> (0) session-state: Saving cached attributes
> (0)   User-Password = "asdf123"
> (0) Sent Access-Challenge Id 170 from 10.30.9.11:1812 to 10.30.9.1:8272 length 0
> (0)   Reply-Message = "Please enter the verification code from Google Authenticator."
> (0)   State = 0x6368616c6c656e6765

  Why is the State attribute being mangled?  It is NOT supposed to be "challenge".

> (0) Finished request
> Waking up in 4.9 seconds.
> (0) Cleaning up request packet ID 170 with timestamp +11
> Ready to process requests
> 
> 
> Now the TOTP Token gets entered and I receive the reply:
> 
> (1) Received Access-Request Id 171 from 10.30.9.1:8272 to 10.30.9.11:1812 length 622
> ...
> (1) session-state: No cached attributes

  Because the State attribute has been mangled.

> (1)     if (!&session-state:User-Password)  -> TRUE
> (1)     if (!&session-state:User-Password)  {
> (1)       update session-state {
> (1)         User-Password := request:User-Password -> ‘11111111'
> (1)       } # update session-state = noop
> ...
> (1) Sent Access-Challenge Id 171 from 10.30.9.11:1812 to 10.30.9.1:8272 length 0
> (1)   Reply-Message = "Please enter the verification code from Google Authenticator."
> (1)   State = 0x6368616c6c656e6765

  Which is (again) "challenge".

  Don't mangle the State attribute.  It is breaking the server.

  And why the heck would you go mangle the State attribute in the first place?  It doesn't make any sense.

  Alan DeKok.