I see that Meraki MR access points now support iPSK. I also saw a configuration example posted using FreeRADIUS and Cisco ISE but I was wondering if there was anything available for configuring iPSK with Microsoft NPS posted anywhere.
Any information would be greatly appreciated.
Thanks in advance.
Take a look at this recent blog here:
The documentation Meraki provides for IPSK is at the moment a bit sparse:
They do provide some information, but it’s rather incomplete and even incorrect at places. The main caveat is that it lacks instructions for Windows NPS support, which is presumably the most used RADIUS server for Meraki 802.1X implementations. The reason for this is that Windows NPS probably lacks the RADIUS attributes or functionality to support IPSK. The instructions do mention Cisco ISE, which is a rarity in the SMB market, and FreeRADIUS, but this is more of a pointer than an instruction. Plus it forgets to mention the most awesomest feature of all: VLAN assignment!
Thank you. The customer currently does implement Microsoft NPS for Windows user/computer authentication using PEAP so I think I'll have to just try iPSK with it and see how it goes.
I believe that since Microsoft NPS integrates directly with AD I may have to generate AD user accounts that reflect the MAC address of the 'PSK-only' devices (older IoT devices) for authentication. As far as I can tell the RADIUS attributes that are needed are options in Microsoft NPS.
I haven't tried it yet. I am waiting to get a 'PSK-only' device in my hands. Hoping to give the config a shot later on this week or sometime next week. I'll gladly post if it's a success of failure.
I ran into the same issue. I was using NPS on Windows 2012 R2. What version of Windows server are you using? I was thinking of trying Windows Server 2019 to see if any updates to NPS features/functions were done.
In the meantime I am waiting for approval to get an MR license or two so I can continue testing (my eval license expired). Really hoping to get this working using NPS since the majority of my customer already deploy it.
I am using Windows Server 2019 - which attributes did you use?
My clients are not accepting my attributes for the PSK.
I have created an account in Acitive Directory (for MAB) and it gets authenticated successfully. But it will not accept the Tunnel-Password as PSK - did you succced on getting the correct attribute to use?
I am in the same position you are but I was using Windows Server 2012 R2.
I was also able to get MAB to work but the Tunnel-Password attribute would not be accepted by the clients. I was going to try using the Cisco-specific attributes to see if any of those would work.
I was hoping that the version of Windows server I was using was the cause of the issue but if you are using Windows Server 2019 then it's not that.
@Joe2112 I have also tried with the Cisco-AV-Pair attributes. It didn't work either.
Here you can see my original attributes setup - where Tunnel-Password is not acceptet.
Upon re-reading all the documentation, I've changed my mind. I think it may be possible to re-configure NPS to make this work, but this is not a normal workflow you would use NPS for.
The first thing I don't like is you have to create a user in AD where the username and password are the MAC address of the device.
Unless you go to a lot of trouble, this means someone could just log into an AD attached machine using those same details, and access anything that "Domain Users" or "Authenticated users" has access to.
You have no way to change the password or lock the person out or any way to remove them from those two built-in groups.
This just sounds dangerous to me.
ps. The solution may be to stop NPS sending some of the other attributes, and getting it to just send the Tunnel-Password attribute.
In beta version 27.1 you have the feature IPSK without radius. Very interesting. But I don't like the limit of 50 unique psk's per ssid.
Indeed look very promising. But I hope they well increase the number of allowed unique psk's. To give an example: Mist can do 5000 and Cisco Meraki 50. But it is a nice start!
I have the same fears but then I came upon this
it might be weird for system admins to have accounts trhat cannot do login but it seems the way to go.
Am I correct?
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:
PSK configured on the WLC is 'Waarisdesleutel' just like the RADIUS attribute.
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.
Try pfSense with the FreeRADIUS module. It provides a nice web interface to manage mac/psk entries, plus you get the power of shell to script bulk enrollment.