Rejected authentication requests

This is one diagnosed by Hans Litteck from the University of London.

He'd noticed that attempts to authenticate a test user were failing and worked with Camden Council to figure it out. Thanks to all involved.

The exective summary is that Microsoft NPS was configured to reject any request that wasn't formatted like:

Called-Station-ID =~ :govroam$

i.e. the Called-Station-ID should have a suffix of ':govroam' after the address of the device.

To quote Hans:

RFC

Further to this Hans has looked into the attribute filters and determined that NPS should be configured not to filter out the following from a proxied request:

NAS-IP-Address
NAS-Identifier
NAS-Port
NAS-Port-Type

…

What isn't know at the moment is if this standard NPS policy or a configuration being placed on NPS by administrators.

A general note about attributes and filtering

The Govroam tech spec talks about attributes and what should be in the various packets and what shouldn't. The key things to note, relevant to the above, are in section 2.4.1.13:

The following RADIUS attributes MUST be forwarded unaltered by participants’
ORPSs if present in RADIUS Access-Request, Access-Challenge, Access-Accept
or Access-Reject messages.
13.1. User-Name
13.2. Reply-Message
13.3. State
13.4. Class
13.5. Message-Authenticator
13.6. Proxy-State
13.7. EAP-Message
13.8. MS-MPPE-Send-Key
13.9. MS-MPPE-Recv-Key
13.10. Calling-Station-Id
13.11. Operator-Name
13.12. Chargeable-User-Identity
Participants’ ORPSs MUST log all RADIUS authentication requests exchanged