2nd request to RADIUS on missing user specific policies

[kbl]

When GCP is used as storage backend and RADIUS is used as auth method request to authenticate against RADIUS is being sent twice for users without explicitly configured policies.

To Reproduce
Steps to reproduce the behavior:

1. Intialize Vault with GCP storage backend,
2. Enable RADIUS auth method under auth/radius path,
3. Run vault login -method=userpass -path=radius username=xxx (xxx shouldn't have any policies assigned, should only use those configured with unregistered_user_policies

In such case, after successfull authentication context is cancelled due to:

"error":"failed to read value for \"auth/<hash>/user/mpietraszek\": Get https://storage.googleapis.com/magic-bucket/auth/<hash>/user/mpietraszek: context canceled"

After that cancellation another request to RADIUS is being made. The latter fails as OTP was already used.

Below is a tcpdump showing requests being made during authentication process:

# tcpdump -n dst host radiu or src host radiu
09:59:42.042366 IP vault.54122 > radiu.1812: RADIUS, Access-Request (1), id: 0x43 length: 105
09:59:43.307065 IP radiu.1812 > vault.54122: RADIUS, Access-Accept (2), id: 0x43 length: 44
09:59:44.656698 IP vault.43448 > radiu.1812: RADIUS, Access-Request (1), id: 0xb2 length: 105
09:59:46.443127 IP radiu.1812 > vault.43448: RADIUS, Access-Reject (3), id: 0xb2 length: 50

Expected behavior
GCP storage backend should allow login by unregistered users.

Environment:
I've reproduced the bug with following servers/clients:

• Vault v0.10.3 ('c69ae68faf2bf7fc1d78e3ec62655696a07454c7')
• Vault v0.10.2 ('3ee0802ed08cb7f4046c2151ec4671a076b76166')

• Server Operating System/Architecture:

Linux vault 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux

• Vault server configuration file(s):

{
  "api_addr": "https://vault:8200",
  "storage": {
    "gcs": {
      "bucket": "magic-bucket",
      "ha_enabled": "true"
    }
  },
  "listener": {
    "tcp": {
      "address": "0.0.0.0:8200",
      "cluster_address": "0.0.0.0:8201",
      "tls_cert_file": "/etc/vault/vault.crt",
      "tls_key_file": "/etc/vault/vault.key"
    }
  },
  "disable_mlock": false
}

[kbl]

Wow, that was quick! I've planned to dive into the code to fix that and certainly expected something more than 4-lines diff ;). Thanks!

[jefferai]

@kbl Validating the fix in your environment is always a nice way to help :-)