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!