iPSK Configuration with Microsoft NPS

Here to help

iPSK Configuration with Microsoft NPS



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.



28 Replies 28
Kind of a big deal

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!

Nolan Herring | nolanwifi.com

Nolan -


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.




Kind of a big deal
Kind of a big deal

Microsoft NPS definately can not do iPSK.


You could integrate FreeRADIUS with AD and simply replace NPS.

Did you have any luck with Microsoft NPS and iPSK setup?

Kurtis -


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.




That would be great, thank Joe!

Hi Jie2112

Had you any luck with configuring this with Windows NPS. I can get it to accept the Filter-ID for Group Policy - but I can't get it to accept the PSK. I have used the attribute Tunnel-Password for this.



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. 






Hi all,
Im struggling with the same iPSK-NPS issue. I can tell you, that it is possible to generate a Radius Accept message, even if you have no AD users (theres a setting for that). But:  What I can see, that all the additional attributes are missing in the Access-Accept message. There´s only the t=Class(25) Attribute in it, nothing more.
Did someone ever managed to get this running? Seems to be like an NPS issue.
Kind of a big deal
Kind of a big deal

It wont be possible to make this work with NPS.

Ok, seems to be like that, but why is that? What is the NPS doing different?

Kind of a big deal
Kind of a big deal

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.


@Complit - I saw this in the release notes for the beta firmware last week and I am looking forward to trying this out. I hit a brick wall with the iPSK w/ Microsoft RADIUS config attempt (running into the same issues that others have posted in this thread), but this (iPSK w/o RADIUS) look very promising.


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!

Hi & Thanks for the information.

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:

  • 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.



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


      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.

Meraki Employee
Meraki Employee

I know this is an old thread, but since so many have asked and with a recent development on this front, it is pertinent to share that IPSK with NPS is now supported on MR 30.1 and higher firmware when using both the RADIUS standard AVP Tunnel-Password AND Cisco AVPs "psk" and "psk-mode=ascii". Please see the updated documentation here: https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication#Mi...




If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it.

Can confirm I got this to work on NPS now, hopefully it won't be too long before a firmware version over 30.1 is Stable

Building a reputation

+1 I would love to see those integrations, or for the beginning Radius using Cloud Identity Providers (AzureAd, Gsuite, Okta etc.)

A model citizen

I just ran across this update. Has anyone got this working with a per device MAC authentication and VLAN assignment, like the Freeradius setup?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.