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.

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

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