Azure Cloud PKI is now released; how do we hook Meraki AP to it?

[Boyan1]

Hi everyone,

It's April of 2024, Microsoft Cloud PKI for Microsoft Intune has been out for some time and it looks very promising for AAD-only joined devices but how do we hook our MRs to it so one can do enterprise 802.11x based on PKI certificate auth (device based auth)?

https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-cloud-pki-overview

I know how to do it the legacy way, with on-prem CA etc EAP-TLS and RADIUS as the last mile authenticator to the Meraki AP but this "Cloud PKI" is totally new. It promises to eliminate on-prem CA, the InTune connector and ton of other heavy weight.

Anyone gone down that road? What endpoint would the APs talk to? What profile to setup the SSID under? So many unknowns?

Thanks

~B

[PhilipDAth]

Already done it.

Configure the SSID to use local auth with certificate authentication.  Upload your CloudPKI certificate.  Works great.

https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_8...

[Boyan1]

@PhilipDAth Thank you but what do you plug here? Azure Cloud PKI does NOT expose any end points on the public Internet to where the MR can be pointed to?

[Brash]

In the image here, you have certificate auth disabled.

Following what @PhilipDAth said, you need to enable it.

[Speedbird1]

I was just looking at this and its damn expensive

2000 devices/users somewhere in the region of £34000 per annum as a standalone Addon. 

You would think MS would include this in enterprise licences. 

[jrhop]

Under our account it looks to be £1.64 per licence/per month. Think the pricing is similar to SCEPMan with support.

[Speedbird1]

Just had a look a these costs again  SCEPMan is actually far cheaper coming in at 743 EUR per month for 2000 users compared to Microsoft $3280.00 per month. 

Unless i'm missing something, It makes no sense to pay Microsoft 20K more for this volume of users 🙄. 

It may make sense if you have a smaller volume but not for us.   

[RobinHelmig]

When running a test to install the certificate i get the follower error

[PhilipDAth]

In Cloud PKI, there are two different formats for downloading the root CA. You need to download the other format.

[jrhop]

Hi @PhilipDAth I am now testing this and stuck at the same point, I will have one option to download from Microsoft Cloud PKI and it downloads as .cer. Meraki says this is invalid. Any help would be much appreciated!

[jrhop]

Got it working now @PhilipDAth @RobinHelmig opened the cert and Details tab - copy to file and choose second option, even though it saves as CER you can upload it into Meraki.

[TJONES-614]

@RobinHelmig Did you get the correct format uploaded?     I'm not seeing where the other format is available.    Or do you download the .cer file and convert it to PEM? 

[RobinHelmig]

No i did not, i'm short on time at the moment.

[jrhop]

Did you get this working @TJONES-614 ? Is it the same certificate mentioned here https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-cloud-pki-configure-ca#create-trusted...

[TJONES-614]

I don't have it working.    However, I did deploy the trusted root and issuing certificates.    Once created, I used OpenSSL to convert the certificates into the PEM format.   

[jrhop]

I have it working pointing to the Meraki Local Auth and via NPS, the Local Auth method seems to take a long time to authenticate and I did have to reboot the AP to get it working. The lack of OCSP with Cloud PKI is a bit disappointing, only have CRL, which the Meraki Local Auth doesn't seem to support.

[Akeon]

Its working for me to a degree, 

1 Create Root CA in Intune

2 Create Issuing CA in intune

3 Create and deploy configuration profile for Trusted Certificates template for each CA in intune.
4 Create & Deploy SCEP profile

5  Create and Deploy Wifi Profile

6 Set meraki SSID to 
 

The only issue i am having is that pesky server validation warning when the client tries to connect. 
No matter what permeation of Server name I seem to try; I cant make stop it for showing on the first conneciton attempt. 
" Continue connecting? If you expect to find XYZWiFi in this location go ahead..."

Otherwise it works ok, I just dont want my users to have to click that warning so can't really use this unless anyone knows how to bypass that. 

[Boyan1]

You've gone far - thanks the the screenshot - that warning I think is a stupid windows thing - I’ve seen a specific checkbox in the supplicant policy to suppress that warning and few other “safety” warnings in Windows; I encountered this many moons ago in the NPS world with fully legit paid certs and still - people had to click to connect 

[Akeon]

Yah!  For anyone reading this - i found a solution that works beautifully. Although long winded and annoying. (And not ideal from a security standpoint)

1. Create the "Windows 10 Template - WiFi profile" in intune as you normally would.

2. Deploy to a test device.

3. Manually go to control panel > Networks > WIfi Adapter > Status > Wireless Properties > Security Tab, (i dont have my computer with me so go hunting in there ) and untick the "Server Validation" option. The CA selections should now be greyed out.

4. Apply changes

5. Export the wifi profile as XML: open command prompt and; netsh wlan export profile key=clear folder="YOUR-FOLDER-SAVE-PATH"

6. In intune, delete/unassign the wifi profile you created in step 1.

7. Create a new profile this time select Windows 8 or higher > Wifi

8. Select the XML file you exported in Step 5, and publish the new WiFi Profile

9 Profit.

Works like a charm here. 

[Boyan1]

@Akeon I totally agree that this is a working solution; however something crossed my mind: isn't doing so dangerous as an evil doer could harvest credentials; simply create a network with the same SSID and supplicants will happily send user IDs and passwords, though auth will fail for the legit supplicants, the fake SSID owner will harvest them and then can use them on the real SSID to auth and get "wire" equivalent access, at least on a network level - far from an open door but one foot in so to speak...

[Akeon]

Absolutely - few things at play there, id personally like to see:

-Intune support OCSP 
-Meraki to support the validation

But compare this all to hosting your own CAs and NDES which is equally a security risk to manage. Not to mention the admin overhead involved.

I'll leave up to the individuals to determine their strengths / scenario / 'whats the bigger risk'.

PS. added a note to my prior steps to hat tip your point. 

[PhilipDAth]

This system does not transmit usernames or passwords.  I only ever sends the public key of the public part of the certificate.

The secret key of the certificate never leaves the device.

[jrhop]

Hi @Akeon I also had this issue with clients asking if they expect to find the network. Only way I found is to add the network name shown below into Intune WiFi profile, I used *. before, but appears it does not like wildcard. And make sure the root (IdenTrust) certificate is present on the devices you are connecting from.

[Akeon]

Yeah have that, i think you are right its not liking the wildcard.
Found solution above after a day of pain- thanks though!

[Daniel-GAC]

Hi @Akeon we are trying to deploy a similar setup to yours but we are struggling on the details of your steps on intune :(. 

Could you share a more detailed walk through? or answer some of my questions below that would be really appreciated.

In the PKI what type of cert needs to be made with what settings?

How do we create and deploy SCEP profile and create and deploy Wifi Profiles? 

Thank you in advanced you have already been very helpful.

[Akeon]

Hey mate, sure fire away with questions - but to get you going are you wanting to authenticate the machine or the user?

In my setup I have two separate networks and we are Hybrid-Azure

WiFi_Device = Internet only

- Purpose is so devices can authenticate with azure at a login screen if user credentials are not cached. This uses a Machine certificate 
SCEP Device Cert: Assign to your computer group.

WiFi_User = Internet + Corporate resources.
SCEP User Cert - Also assign to your device group (and apply filtering if you want to limit users).


Make sure you are pushing out a trusted certificate profile for:

IDEN Trust (from your meraki ssid page)

Hydrant CA O1 (from your meraki ssid page) - not 100% sure you need this but i added it.
Your Root CA

Your Issuing CE.

All 4 will be needed in the WiFi profile to stop the annoying windows "is this wifi trusted/what you expect" message.

WiFi Profile: device and user are basically the same except the cert you choose so ill only post the one screenshot and note the variances. 

PS. this also works for auto configuration of iphones WiFi/outlook365 email config without passwords. 

PPs. sorry we sort of derailed a bit from the OP and turned this into a guide

PPPs. Before anyone cries boogeyman - we are enrolling certs to KSP because surface devices and possibly others have a bug with 4096 keys not working in TPM

[Daniel-GAC]

This is really useful thank you.
We was looking at Authenticating using the Machine but it is probably better from a security aspect to use user's. Does it matter if we are Azure cloud only? 

[Akeon]

Not at all.  Id argue Azure cloud only is better! (and easier)

[Daniel-GAC]

So im presuming we get this cert to upload from the Meraki for the trusted certificate?

[Akeon]

Yup from the access control page 

Wireless > Access control

Hydrant Server cert was a bit harder to track down hence i don't know if its needed or not. 

[Daniel-GAC]

Might be being impatient as we just set this up but getting this error on the devices we have deployed to. Which cert do we upload back into the Meraki portal? The Issuing CA

[Akeon]

Check the cert you are pointing to in your intune wifi profile is actually deployed to the device/user
Open MMC

Add Certificates snap-in (local computer for machine certs, My User Account for user certs)  

Go to personal certificates

Check the cert has been deployed.

Yes the issuing CA gets uploaded to meraki.

[Daniel-GAC]

Okay the SCEP cert does not seem to be deploying and we dont know why haha.
Intune just says "Error" which is really useful. How do we get it to deploy properly for user certificate store?

Thanks in advanced!

[jrhop]

Have you tried following this guide? There are quite a few steps involved in the process https://oliverkieselbach.com/2024/03/04/how-to-configure-cloud-pki-certificate-based-wifi-with-intun...

It doesn't include the Meraki part, but it details the steps required to get Cloud PKI setup and the Intune configurations setup. You will need the Cloud PKI trusted cert and issuing cert deployed and then a SCEP configuration for the device to request the SCEP certificate.

[Daniel-GAC]

Out Cert's keep deploying here! Not sure what we are doing wrong. But we are going to start again and re try the setup with user auth rather then computer.

[Akeon]

Mine show up in root under computer (not user). When creating the trust profiles in intune, for:
Root CA

Issuing CA

Iden Trust

I am selecting Computer certificate store - Root

Then when adding the mmc snaping be sure to select the local computer store. 

Otherwise if you trust some random on the internet and have Teams (world class advise), DM me and ill spare 15 mins to check it all over.

[amb310]

---

@Akeon wrote:

Yup from the access control page 

Wireless > Access control

Hydrant Server cert was a bit harder to track down hence i don't know if its needed or not. 

---

I think it is because I've got the same setup you have, and I cannot get the pesky "connect" dialog to go away.

Where exactly did you pull the Hydrant Server O1 cert from because I cannot find the <explitiveDeleted> thing.

[Akeon]

From here:

HydrantID Server CA O1 Certificate - 89B89BB69EEDFBB0C6BD0DEC674E3CA3929D2DF9 (fyicenter.com)

But as long as you have the Iden Trust cert deployed to your trusted root store i wouldnt have thought you would need it.

[amb310]

Thanks!

That's what I'd have thought too, however, I will do some testing today and triple check my work. Then report back either way, that it may help others setting this up.

[amb310]

Apologies for the late update. 

After some testing, I can say I did not need the HydrantID server cert. I reexported and reimported the IdenTrust and everything worked.

[Akeon]

I mean yeah if the device gets stolen then thats about the scenario id think it would be a concern. But then they have to be in wifi range so stolen from your office? Unlikely but possible.

You can decside what your risk appetite. 

I VLAN off the device network so it still can get to internet. 

For your azure cloud auth; your device is going to need internet access prior to windows login - else your devices wont be able to talk to the interwebs to authenticate the username/password when your staff try to log in. 

User only cert wont let you do that.  Machine cert will, hence im using both and relying on Windows to swap to the correct user network after login.
Clear as mud?

With multiple profiles you can check Wifi Priority order with :
netsh wlan show profiles

Set the priority with :
netsh wlan set profileorder name="YOUR_USER_NETWORK_NAME" interface="Wi-Fi" priority=1
netsh wlan set profileorder name="YOUR_DEVICE_NETWORK_NAME" interface="Wi-Fi" priority=2

Also point out this may very well be overkill for you - if your are Azure only then im taking a bet you have no on-prem server resources to secure in which case Machine only cert is probably fine on its own and forget half of what I have written. 

[PhilipDAth]

Apply the built In "block" group policy in this case.

[CGRE]

What was the solution for this, the name? The current network or org name I can find no issue on the Meraki portal, but where do you apply this in the Intune profile itself?

Am getting the "network at this location expected" message and you have to click connect manually every time, the client machine has all the certs required and when I hit connect it does authenticate and work fine, its just this Windows issue with it doing some kind of pre-check?

[Kyote]

Did you deploy a wifi profile?

[Akeon]

Consolidated walkthrough here - Step by step Cloud PKI setup + Meraki setup + Wifi deployment for windows. 
Cloud PKI-WiFi.docx

Credit to Oliverkieselbach.com who i copied and pasted some notes from.  

[PhilipDAth]

Excellent document.

[HockadayJJT]

Do you still have this doc available? I can't reach it for some reason--

[Akeon]

Just Microsoft OneDrive issues. Its there and shared but took me a few page refreshes to get it to open.

[Mikeyy]

Hey thanks alot! I got it to work perfect with all my windows clients- but not for IOS or Mac - any idea what settings should be changed?

[PhilipDAth]

The manufacturer of your devices.  🤣

[PhilipDAth]

I don't know the answer - but verify that the Apple devices properly recognise the root CA certificate as trusted.

[Akeon]

Hey Mikeyy, My profile is applied to the User - not the Device in intune.
If you want to filter to only company devices, use Filters.

These are my IOS SCEP settings:

[Mikeyy]

Hi Akeon!

I have the exact same config as you but I'm getting the following error:

"Client failed 802.1X authentication to the RADIUS server.auth_mode='wpa2-802.1x' vlan_id='101' radius_proto='ipv4' radius_ip='127.0.0.1' reason='radius_login_failure' radio='0' vap='2' channel='1' rssi='32'".

Could you do a screenshot how you have your Meraki access control setup? Maybe I'm missing something obvious here?

[Akeon]

I'm by no means an expert on the WiFi Side (happy for anyone else to chime in)  - but that tells me the WAP is not accepting the certificate.

Have you confirmed the iOS device has been issued a certificate and it is installed?
In the phone/ipad  go: Settings > General > VPN & Device Management > Management Profile > More Details

Under: SCEP DEVICE IDENTITY CERTIFICATES, Look for your certificate with the Subject name equaling the UserPrincipalName of the person.

Ours is deployed using the microsoft "Company Portal" app on the iphones.

SSID config for reference is: 

[Mikeyy]

Hi again,

I do have it on the phone- but still unable to join the same SSID the windows machines are able to? I get a popup asking for username & password when trying to connect to that ssid.

Would you be so kind a screenshot some more your settings just to see if I've missed? Greatly appreciated.. 🙂

[Akeon]

Just adding another peice after massive issues with WiFi Roaming.

Scenario - Our windows laptops seem to roam every few seconds, then after a short time get disconnected. 
I found that when the roam happens between access points, the device has to reauthenticate. With on prem certs/NDES thats fine as its pretty instant.

In our Cloud PKI world, cloud wifi our authentication logs show the process as taking up to 25 seconds! 

The result is if your on a video call, and your device roams - you are effectivly on hold for that 25 seconds. 


Solution was to enable Fast Roaming on the wifi profile settings, which effectivley allows the authentication to be cached for a short duration.  In my case the business day.

[GIdenJoe]

Indeed, the setting you are showing here is effectively enabling 802.11r (FT) on the clients.  If your SSID is configured to support FT then the whole radius thing does not need to happen every time you move between AP's.

If you go to your client in dashboard and look at roaming analytics you will also see the type of roam which should be an 802.11r roam taking as few as 20-50 ms to complete the roam.

[amb310]

Out of curiosity, has anyone tried configuring this for use with ChromeOS devices?

I've not dug into that yet, just wondering.

[Akeon]

Not me, I’ve only done:

IOS = passwordless email / wifi profiles

Android = passwordless email

Windows = WiFi only

[JonnyWinter]

Doing this, is there any way to return a group policy ID or VLAN for a certain user/device/etc.? Appreciate the work here, great stuff!

[Akeon]

If I understand your question correctly, you are asking if the SSID can attach clients (whether user or device) to a specific VLAN. Is that correct?

is so answer is yes that’s exactly what I do. I’ll post a screenshot when I’m in the office tomorrow .

if no please clarify the question 🙂

[JonnyWinter]

Apologies, I didn't realise how detail lacking my message was until re-reading it now. I'll be more clear - 

Assuming that I was to have performed the configuration outlined in this thread, and have successfully tied Azure Cloud PKI to an SSID performing Local Authentication via Meraki. My next thought is - how do I send "user-group-a" to VLAN-12 and "user-group-b" to VLAN-34. Or, how would I send "devce-group-a" to VLAN-56 and "device-group-b" to VLAN-78.

As it stands, I use ISE (or any RADIUS solution tied to an IDP, really) to send certain groups to certain VLANs using filter-ids to match group policies, and the group policy puts the identity in that VLAN (wireless only). 

The method isn't what phases me, so if it's completely different that's all good. It's the outcome - specific groups of users/devices into specific VLANs all using the same SSID - i.e., "CORP-SSID".

Thanks! 

[Akeon]

I got you now; though cant give you the answer you particularly want as Meraki is doing local auth - it doesn't know what users/groups should belong to what VLAN. 

I tackled this by creating a separate SSID for each VLAN I want to bind the users too when using local auth on a certificate. 
SSID for = Mobile phones / BYOD = VLAN 123

SSID for  = Corporate devices network = VLAN 456

Then control who gets what SSID and certificate profile through your MDM / Device Policy system

You can apply policies on device type though. 


Next Question: How do I prevent someone from just connecting to the other SSID and therefore VLAN if they have a certificate.
A: couple of ways, but primarily because you can have up to 6 CAs in Azure, you can create an entirely separate certificate chain (RootCA, IntermediateCA, User/Device Cert) for the Guest/BYOD services bound to SSID-1 compared to corporate devices (or multimedia devices) bound to SSID-2

In terms of managing extra infrastructure, it's all cloud anyway so there is really not much extra overhead on-going. It is all just frontloading the setup.

Someone more awesomer than I may have a better/cleaner answer. 

[JonnyWinter]

Thanks for the reply. Appreciate the response. I had come to the "Assign group policies by device type" answer to get around this - so on the same page there. The information around the # of CAs is great, and makes sense how to create separate certificate chains for each SSID. 

My only outcome to achieve now is assigning different groups to different VLANs - but that group is user based. If anyone has an outcome to work that into this solution that would be amazing.

[GIdenJoe]

Using device based group policy is not recommended because the profiling is not customizable like you have in a radius server like ISE.  So the system is too rigid and you would have too many devices not fitting the profiles correctly and not getting the correct VLAN/group policy.

You still need some way to see the groups of the users/machines and then apply the correct policy to it.  Usually this can only be done using a radius server.  In case of meraki mdm instead of Azure you could have sentry wifi policies selecting the correct group policy.

[JonnyWinter]

Thanks for the reply. I'm really looking to not use any other MDM than Microsoft Intune, this Cloud PKI, Meraki MR/MX/MS, and Entra ID - so in this case, although it's a big step in the right direction, I'm unable to achieve the outcome I'm looking for. 

[Akeon]

If you are open to multiple SSIDs you can; using only Intune, CloudPKI and Meraki WiFi.
1. In intune, create CLOUDPKI cert chain {Root CA, Intermediate CA, Endpoint profile} designated for VLAN 1  (or whatever VLAN number you specify)
2. In meraki, Create SSID scoped to VLAN 1 

3. In Intune create a user or device group for VLAN 1 users and deploy the profiles/certs to that group only.

Repeat each step 1-3, changing the names to VLAN 2  and VLAN2 Users .

End result:
  two ssids

  on two seperate vlans

  applicable to two different sets of user groups.

  and users can only join their particular wifi ssid assigned to them. 

Note 1: you can only do this 3 times due to the 6 CA limit in CloudPKI, and needing a root and intermediate CA.

Note 2: You cant delete a CA once created without logging a support ticket with MS and getting them to do it for you, which in my experience was rather annoying. So think before you click.  😄Apparently this has now changed!

[JonnyWinter]

I'm not; it's not something that's scalable whilst trying to meet the criteria of the High Density Design Guide with a large environment and keeping SSID quantity to ~3-4. If I was to apply this principal to a network that I have in mind with the filtering between groups and subnets, I'd be up to ~10 SSIDs for user groups alone. No matter. I'll have to stick to RADIUS via something like ISE.

[Karam-Alshukur]

So I managed to do to use MS Cloud PKI to issue SCEP certificates to my devices (Windows, IOS & Android)
Created WI-FI profile for each platform, a lot of troubleshooting and now everything seems find and my devices can authenticate against some cloud radius service without any issues.

Next Step, I'm trying to authenticate wired clients as well via same method, did anyone tried that here?

[PhilipDAth]

That can't be done without a RADIUS server.  MS switches can't perform native certificate authentication like the MR access points.

[Karam-Alshukur]

I have cloud radius service from radiusaas.com, and this is how I'm authenticating my wireless users.
MRs are configured to redirect access requests to the radius server where authentication happens.

Now I'm just trying to add wired clients to the game as well, I did configured my testing access policy, and applied that to the switch ports, my testing machine is windows which is connected by cable to the switch port, however something is going wrong and trying to figure out this

[Hig]

Hello, I've managed to hook everything up using only Cloud PKI and Meraki, however i've got a lot of connection issue where some PCs get disconnected before reconnecting after some time, I thought it was a problem with the fast roaming as I saw in this thread but it didn't changed anything, anyone got an idea please ?

[Kyote]

Sorry to revive this thread, but I'm wondering if anyone was able to successfully deploy this through jamf? I have it working with our Windows device (through Intune) currently.