Hi,
I got it working with a Cisco WLC (8.5) and NPS on Server 2012. The WLC part is pretty straight forward (PSK Based SSID with MAC filtering and AAA server configured). I know this is a Meraki forum but want to share the part of the NPS config. It might give others some leads:
NPS / Windows:
- Create a user with its MAC-address as username an password (format aabbccddeeff). This creates an issue with the default Password Policy because it rejects the password. For testing I disabled it but this is unacceptable in production.
- Add the user to a group (e.g. IOT)
- Create a network policy with the condiftion of the User Group (IOT) and other favourite conditions
- Do not select any Authentication Methods and add Vendor Specific RADIUS Attributes (Cisco-AVPair)
PSK configured on the WLC is 'Waarisdesleutel' just like the RADIUS attribute.
Caveats:
Password Policy is configured at the domain level so changing it will affect the whole domain. If you want to use NPS for this setup, install an sperate DC server with an seperate domain. Install NPS on this server and use this one for IOT-authentication.
If you want to use only one front end RADIUS server you can use this server. For normal 802.1X users you can add a policy which proxies the requests to the internal NPS server.
Seperating the IOT-users from your normal domain solves another problem and that is access to other Windows resources.
Edit : it seems in Authentication methods you need to select PAP only. My client was suddenly offline and fiddling with PAP and the "Allow clients to connect without selecting...." option got it back online. Going to keep an eye on this.
The story continues:
Have tested it with a MR33 and it fails to work with Microsoft NPS. I've also tried FreeRadius and that works. During the tests I made come captures:
This is FreeRadius capture (the only interesting part is the Access-Accept reply from the RADIUS server):
This is the NPS reply:
Assuming Meraki ignores the other attributes, one thing is different in the Tunnel-Password attribute; NPS is not adding a Tag field in the reply. From the RFC
Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is greater than 0x00 and
less than or equal to 0x1F, it SHOULD be interpreted as indicating
which tunnel (of several alternatives) this attribute pertains;
otherwise, the Tag field SHOULD be ignored.Don't know if this is the case but this might be the reason it is not working.
