Meraki - RADIUS (NPS) Auth - AAD Devices & Certificates

[Gmorrallee]

Hi all. 

We've taken on a new client to roll out a bunch of Azure AD joined clients to the users. As part of this they will need to use their Meraki WiFi solution.

The Meraki is currently configured to use Radius on a  Windows 2019 Server with NPS installed. There is an on premise AD which is synced down to Azure AD. The Radius server is currently configured to use the on premise Domain Users group for authentication. However to prevent personal devices being joined to the WiFi network using their AD creds the client wishes to use certficates to authenticate instead. 

We have an internal CA and the root certificate is installed on all clients via InTune. 

It seems the we potentially need to deploy PKCS certificates via InTune and leverage the InTune Certificate Connector to sit betweeen the CA and InTune. 

However the part of this I'm struggling with and can't seem to find any information on is the actual connection between the certificates deployed via InTune and the Certificate Connector and the Radius Server authentication. 

So basically we can get certificates to the clients but how does the Radius server know to authenticate them?

Any thoughts?

Thanks

[GIdenJoe]

I'm no expert on the matter but the basics things I know:

1) Your clients will be configured through intune with the SSID to connect to using WPA2-Enterprise and EAP-TLS and the correct certificate to use.  Also if it's using machine or user auth or both depending on login screen or logged in.

2) When the client connects the AP will transmit the radius attributes service-type:framed (for dot1x) and a called-station-id which contains SSID and AP MAC address.  The client will also transmit it wants to do EAP-TLS.

3) The NPS server would have been configured with:
A list of IP's or radius clients (the AP's) or a subnet where the AP's live
The policy where it matches on service-type framed and called-station-id containing the SSID, and EAP-TLS as auth method.
The fields to look at in the certificate mostly common name and the attributes containing the AD group.

4) NPS sends it's cert to the client which is signed by the same CA, so the client trusts the NPS server
5) The client sets up the TLS connection and sends it cert over it containing all necessary fields
6) NPS evaluates and sends access-accept with attributes or access-reject if something is wrong

If I'm mistaken somewhere, please correct me 😉

[PhilipDAth]

Be prepared for a lot of work.  Microsoft has made the configuration you describe really hard.

You'll need to configure Intune to issue certificates from the on-premise CA server using SCEP/NDES.  These certificates are authenticated against the user in AD (they have the username embedded in the certificate).

When the user connects to WiFi and presents their certificate RADIUS extracts out the username and then continues to process as normal.

This is a lot of work to deploy and get working.  I'm waiting for Trusted Access to add support for Windows 10 so I can forget this nightmare.

https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Trusted_Access_for_S... 

Actually, I think you could do this via Meraki Systems Manager (which you would have to buy).  You can only enrol a Windows 10 machine in one MDM at a time - and you have already enrolled in Intune - but I think if you used Intune to deploy the Meraki Systems Manager agent you could then use the Meraki Agent to deploy Meraki certificates onto the machines for authentication, all automated.  It would also configure the WiFi settings on the machine.

https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Configuring_EAP-TLS_... 

I'd be tempted by this approach because the Microsoft method is such a lot of work.

[RonaldB]

Hello,

To deploy user and device certificates you can deploy PKCS certificates. This is easy to do. What you need is to download the PKCS certificate connector. You can find it when you go to the intune portal and Device configuration | Certificate connectors. Click on Add and download the PKCS certificate connector.

Go to an on-prem server which is in the same domain as the internal CA server. Don't worry, connection with the certificate connector will be as save encrypted tunnel so no complex firewall settings or other things to worry about.

Install the certificate connector and only PKCS have to be installed. If SCEP is applicable you can choose for PKCS ans SCEP during the setup steps of the connector.

After installing start the connector. If starting the app later, run the connector as admin.

Make sure you have a Azure global admin with an Intune (EM+S) license activated. If not do so but it will take some time before this is active, at least 15 min.

In the certificate connector login with the Azure Global Admin, and you are finished. You can see in Intune a green check that the connector is up and running.

Next is to create a certificate connector which has the correct certificate requirements. For Intune I believe you have 2 requirements to make sure you can enroll the certificate and that is under Subject Name: Supply in the request, and at permissions, add the server which has the certificate connector installed the read and enroll certificate permissions. I think that is it but be sure to look online for advise when deploying the certificates with Intune.

I used this method for always on vpn configurations and WPA2 Enterprise PEAP Wifi Configurations based on user certificates.

Hopefully this helps.

[RonaldB]

Hello all,

Deploying a device certificate from an internal CA is not very difficult as I mentioned in my last post. But using NPS as a Radius server with device certificates is. This is because the NPS server checks the device from the certificate.

. But with Azure AD joined device the NPS server will not find the device in Active Directory and because of this it will not except the connection like cockneymanc mentioned. 

I have read in other posts about creating the devices in Active Directory as an object (so not Hybrid joined) just to be able to check the device. I can't remember the exact steps but it was for me to much manual tasks which I didn't like doing.

At one customer I deployed device certificates for Wifi which works great, but they don't use NPS. I saw that they are connecting to a Linux server which does the authentication check. I have no idea what this was but it works. If it is secure? I don't know. It probable just checks if the certificate is valid with a working certificate chain and CRL. But that is all guessing. If anyone is interested I can ask the customer to explain what has been setup to just have an idea if someone would like to go for this approach. 

This means: 

- Azure AD joined devices.

- Certificate Authority in on-prem AD

- Intune Certificate Connector for deploying certificates to Azure AD joined devices.

- Device Certificates en Root certificate deployed with Intune on the devices

- PEAP smartcard/certificate based authentication Wifi profile with device authentication. Wifi profile deployed with Intune.

- Some kind of Linux server as the RADIUS server (so no NPS here)

[Berlin_IT_Guy]

Thanks @RonaldB for all your help with this.

I'm fairly new to certificate auth methods, so im learning on the job.

I have set up and deployed NDES with the Intune connector by following the article you posted.

Cert enrollment works and a cert is issued from my on-prem CA to the Azure AD Device.

I will test the user cert auth on my internal NPS later this week via Meraki wi-fi radius auth.

If its not too much trouble to ask your client what Linux Radius solution there where running, it would be much appreciated and very interesting.

On that note, has anyone tried using a cloud based 3rd party radius service that integrates into Azure AD, like this one from SecureW2 (https://www.cloudradius.com/radius-authentication-with-azure-ad) ?

[PhilipDAth]

The cloud-based RADIUS service looks good @Berlin_IT_Guy .  Another one I have seen but not tried is:

https://wiflex.eu/ 

[RonaldB]

Hello @Berlin_IT_Guy ,

I asked the customer and it seems that they are using an Aruba Wifi system which comes with 2 Clearpass servers. The Clearpass servers do the authentication which do not require the device to be available in the domain controller to check the device name which the certificate has been requested for.

[Berlin_IT_Guy]

Hi @RonaldB,

Thanks for finding out. I presume it only works for Aruba.

I have seen one user implemented user based cert auth using FreeRadius: https://stackoverflow.com/questions/40747952/freeradius-authentication-through-azure-active-director...

I wonder if the same can be done for device cert auth...

@PhilipDAthThanks for the link, it looks promising. I'm going to try to get it working on NPS with user cert auth before I give up and pay for a cloud based service.

AFAIK, the only difference between user cert auth and device cert auth is that the wi-fi will only connect once the user has logged into the device. I can live with that until we find a working device cert auth method for Azure AD Joined devices.

[Berlin_IT_Guy]

Hi All,

So my test today did not go as expected.

Seems my Intune Wi-Fi profile is not configured correctly.

Anybody have any experience in how to configure the profile for it to work on Meraki?

I currently get an error saying "cant connect because you need a certificate to sign in"

This is what I currently have:

[RonaldB]

Hi Berlin_IT_Guy,

I don't know if the issue is with the Wifi configuration. I still used the OMA-URI configuration with the config in a xml which exported from a working system.

Can you confirm when you configure the Wifi profile manually on the client, that you can connect? Just to make sure that it is an Intune configuration issue and not a general Wifi config issue. Also check the personal certificate store on the device if the enrolled certificate is present on the device.

Next to that, are you setting this up with user authentication or device authentication? If you use user authentication and user certificates you can use to enroll the user certificate with PKCS certificate configuration profile instead of SCEP. This will also work with NPS because the validation of the user certificate is based on the user account, which is part of Active Directory, so NPS can do the validation. 

If you do this on device authentication, then you get back to the issue on this discussion where NPS doesn't know the device and cannot validate the device certificate. This will give the same message as you posted. More information can be found on the NPS server in the eventlog.

Hopefully this helps.

[Berlin_IT_Guy]

Thanks @RonaldB

I will try everything you suggested.

Working from home makes it difficult to test. I only go into the office about once a week nowadays.

I opted for user certificates since I would like this to work on Azure AD Joined devices (Not Hybrid).

The certificate is present on my device, it was enrolled using a SCEP profile on Intune.

The certificate also shows up in Intune --> Dashboard --> Devices --> Monitor --> Certificates

I will revert back if I get it working.

[RonaldB]

Hello everyone,

Just for your information.

I just read this on the Intune what's next side from Microsoft:

New version of the PFX Certificate Connector and changes for PKCS certificate profile support

We’ve released a new version of the PFX Certificate Connector, version 6.2008.60.607. This new connector version:

• Supports PKCS certificate profiles on all supported platforms except Windows 8.1

  We’ve consolidated all of the PCKS support in the PFX Certificate Connector. This means if you don’t use SCEP in your environment, and don’t use NDES for other intents, you can remove the Microsoft Certificate Connector and uninstall NDES from your environment.

• Because the Microsoft Certificate Connector hasn’t had functionality removed, you can continue to use them to support PKCS certificate profiles.

• Supports certificate revocation for Outlook S/MIME

• Requires .NET Framework 4.7.2

So with the PFX certificate connector, we can also use the PKCS features and do not need any NDES of SCEP environment at all. If you start from scratch I would advice to try this new connector so you are all up-to-date. When already using the PKCS connector, you can still keep on using it.

[RonaldB]

Hello Berlin_IT_Guy,

As soon as the deployment of certificates work, you can also see a successful request of the certificate in the console on the CA server. In Intune you can see this also in the certificate profile itself. It will also have a Certificate part in the left column below "Device Status", "User Status" and "Per-Setting status".

And in the end you can open the MMC certificates stap-in on the device to see in the personal user (or device) store if the certificate is present there. In the snap-in you can also look in the device - trusted certificate authorities for the Root CA of you certificate server. Both has to be present.

Probably you already knew this but just in case.

[Berlin_IT_Guy]

@RonaldB 

Thanks for all the info and advice posted.

Yes, my user certificates are enrolling successfully in Intune and visible everywhere you mentioned.

I can also see the user cert in the MMC user cert snap in.

I now need to get my Wi-Fi profile working. I do have a xml export from a working PC of the Wi-Fi profile deployed via GPO. I doubt it will work since its configured to user a device certificate.

[RonaldB]

Hello Berlin_IT_Guy,

What I would advice is to get an Azure AD joined device managed bij Intune, which has the user certificate in place.

On this device you configure the Wifi profile manually and this way you can test that the connection works fine. On this device you export the Wifi profile with netsh.

First you can view the wifi profles:

- netsh wlan show profiles

look for the network profile name and use this to export it.

- netsh wlan export profile "type_profile_name_here" folder=c:\wifi

This will create an xml file which you can use in Intune.

Just as an extra remark, if you do this for WPA-Personal wifi configs (so not in this case because you are using WPA-Enterprise), also use the option key=clear. So the command would be: netsh wlan export profile "type_profile_name_here"  key=clear folder=c:\wifi. This makes the WPA key exported in plain text and doing so makes it possible to import it on other systems. Else you can only use it on your own system.

Now you create an Configuration profile in Intune. Select a custom profile for Windows 10 (OMA-URI)

For the name field I always use the wifi SSID but it is just for reference as well as the description is.

For OMA-URI use: ./Vendor/MSFT/WiFi/Profile/yourSSID/WlanXml

change yourSSID to the SSID of the wifi.

Data type is string

And the value is the content of the xml which contains the Wifi configuration which you exported. 

This should do the trick.

[Berlin_IT_Guy]

Hi RonaldB,

Just an update. So I finally managed to get it working. YAY!

Had to tweak my radius profile a bit and exported the manually set up Wi-Fi profile as you suggested.

I'll make sure to post updates here, if I ever get device based certificate authentication working in Intune.

(Never going to get used to calling it "Endpoint Manager")

The idea is still to go full cloud, moving to a 100-percent internet-first model for client connectivity.

Being dependent on an "on-perm" Radius and CA does not serve that goal. (Both Azure VM's)

For now user cert auth using this method is good enough, until I can find something to better serve our goals.

Thanks for everyone's help and support.

[jpcaid]

Hi @Berlin_IT_Guy 

Are you able to send a screenshot of your working configuration please?

I am looking to set this up as well.

Many thanks!

[Berlin_IT_Guy]

Hi @jpcaid 

Sure, Here is my SCEP cert config in Intune.

You can also find the full setup guide here. The easy way to deploy device certificates with Intune – Modern IT – Cloud – Workplace (oliverkiesel...

[jpcaid]

Thanks, @Berlin_IT_Guy 

Sorry i meant the wifi settings (configuration profile settings)  is that's possible please?

[Berlin_IT_Guy]

@jpcaid 

There is not much to see.

It's an Imported Wi-Fi XML profile.

I used the "Wi-Fi import" option when selecting "Windows 8.1 and later" configuration profile platform.

To get the XML file, you set up the Wi-Fi network manually on a test device and get it to work, then export the xml file using command prompt.

I believe this was mentioned somewhere in this thread.

Below is an example. If you want to make use of it, you will need to update the following properties to match your environment:

<name>

<hex>

<TrustedRootCA>

<IssuerHash>

<?xml version="1.0"?>
<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">
    <name>Your SSID</name>
    <SSIDConfig>
        <SSID>
            <hex>3845876245786</hex>
            <name>Your SSID</name>
        </SSID>
		    <nonBroadcast>true</nonBroadcast>
    </SSIDConfig>
    <connectionType>ESS</connectionType>
    <connectionMode>auto</connectionMode>
    <MSM>
        <security>
            <authEncryption>
                <authentication>WPA2</authentication>
                <encryption>AES</encryption>
                <useOneX>true</useOneX>
            </authEncryption>
            <PMKCacheMode>enabled</PMKCacheMode>
            <PMKCacheTTL>720</PMKCacheTTL>
            <PMKCacheSize>128</PMKCacheSize>
            <preAuthMode>enabled</preAuthMode>
            <OneX xmlns="http://www.microsoft.com/networking/OneX/v1">
                <authMode>machine</authMode>
                <EAPConfig>
                    <EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
                        <EapMethod>
                            <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
                            <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
                            <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
                            <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
                        </EapMethod>
                        <Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
                            <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
                                <Type>13</Type>
                                <EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
                                    <CredentialsSource>
                                        <CertificateStore>
                                            <SimpleCertSelection>true</SimpleCertSelection>
                                        </CertificateStore>
                                    </CredentialsSource>
                                    <ServerValidation>
                                        <DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
                                        <ServerNames></ServerNames>
                                        <TrustedRootCA>a1 b2 c3 d4 e5 f6 g7 h8 i0 j1 k2 l3 m4 n5 o6 p7 q8 r9 s0 </TrustedRootCA>
                                    </ServerValidation>
                                    <DifferentUsername>false</DifferentUsername>
                                    <PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation>
                                    <AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
                                    <TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
                                        <FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
                                            <CAHashList Enabled="true">
                                                <IssuerHash>a1 b2 c3 d4 e5 f6 g7 h8 i0 j1 k2 l3 m4 n5 o6 p7 q8 r9 s0 </IssuerHash>
                                            </CAHashList>
                                        </FilteringInfo>
                                    </TLSExtensions>
                                </EapType>
                            </Eap>
                        </Config>
                    </EapHostConfig>
                </EAPConfig>
            </OneX>
        </security>
    </MSM>
    <MacRandomization xmlns="http://www.microsoft.com/networking/WLAN/profile/v3">
        <enableRandomization>false</enableRandomization>
    </MacRandomization>
</WLANProfile>

[TaylorFusion]

Hi everyone,

Just found this as I too have a very similar ask to this thread and (MS) documentation is scant.

What did the OP end up doing? We're doing NPS for authN as well and it sounds like device certs are out, based on this earlier RADIUS technology not being able to authN non-domain joined devices.

I am not clear on why RADIUS/NPS is even required though, if the Intune enrolled devices (non-domain joined) are receiving a valid certificate from the (domain joined) CA on prem?

Isn't that the whole point of doing cert-based authN? Along with the certificate, can't the Intune policies be configured to otherwise validate them as secure for authN and AuthZ?

Thanks

[Gmorrallee]

Hi - as the OP I can report we did indeed get this working - however it was a right slog (and involved many long calls with MS support!) 

We did get NDES working to deploy SCEP certificate deployment for user auth to the RADIUS server - the process we followed is basically here: Support Tip - How to configure NDES for SCEP certificate deployments in Intune - Microsoft Tech Comm... (this was provided by our MS PS tech that we ended up having engaged)

However longer term we are definitely going to look at some of the other options such s Radius as a Service etc mentioned in this thread as obviously user certificates for WiFi auth is not ideal

[RonaldB]

Hi Gmorrallee,

Why are you using SCEP to deploy certificates to Azure AD joined devices? It is much easier to deploy certificates from your internal CA environment when using PKCS certificate profile in Intune.

With that you only need the certificate connector setup and the correct certificate template requirements. Then you configure the PKCS certificate profile and you have your certificate on the device.

The requirements are:

- Compatibility set to win7/2008R2 or higher

- Private key exportable

- Subject name supply in the request

- For deployment with the certificate connector you need to give the server which has the certificate connector installed or a setup service account for that, have certificate enroll permissions on the certificate template.

For the rest you can leave everything default. This is for a user certificate. I don't know by heart if a device certificate has any different requirements.

Hopefully this helps.

[RonaldB]

Hello TaylorFusion,

You are right about if we need the RADIUS server to check AD if the devices exists. But this is just how NPS works. NPS is an Active Directory integrated solution which checks if the resource (user or device) which is mentioned in the certificate is present in Active Directory. If it cannot find the resource, it will not approve the connection. This is more safe solution because it has a double check, let say it like that.

So if you would like to do device authentication with a device certficate, you should use a different solution for RADIUS. Another customer of mine uses a linux RADIUS solution which doesn't do the AD rescource check.

For most cases user authentication is enough for Azure AD joined device. The only reason I can think of is for Wifi to be able to get an internet connection, and with this able to log on to a device (for example an Azure AD joined device) to logon for the first time. So when no cached user profile exists on the device.

Hopefully this helps.

[Chabs]

Did you ever work this out? I can't believe such a simple part of the puzzle isnt really in any documentation anywhere- how do you configure Microsoft's NPS server to use these cloud SCEP certs for authentication? How do we add an external cert to the trusted lists within the NPS settings.    I dont really see any of these replies succinctly giving you this answer. 

[Gmorrallee]

Not yet - we seem to get loads of different parts of the puzzle but have not yet been able to complete it. 

We've been engaged with MS support for several months and still haven't got it resolved. We've got a field services engineer helping out now but between either or him cancelling we've still not got anywhere. 

Apparently it's seemingly impossible find any sort of documentation to explain this from the ground up and work through it step by step.... (i.e. what sort of certificate, what settings do we need in InTune, on the NPS box etc)

Hopefully when we finally get our field service tech involved next week we might finally get there. 

[Gmorrallee]

I actually had a blazing row with MS support cos they were like "oh you need to do this, this and this" but missing vital steps on actually HOW you do those things along the way. 

[Chabs]

Ugh dealing with Microsoft support, there goes weeks of going round in circles. 

Sounds like our Infrastructure is exactly the same as yours. 
I am thinking to just try importing the cloud SCEP cert (in our case SCEPMan cert) in to the Radius server Trusted Root Certificates. Then there seems to be an option to add additional certs in the Microsoft NPS settings. (currently its using the PKI cert assigned to the RADIUS server) 

Playing with this risks breaking our current wifi and RADIUS servers though. 

I'm currently talking to Glueck Kanja who have been very helpful - I'll let you know if we get anywhere. 

Thanks again! 

[Berlin_IT_Guy]

I am trying to achieve the exact same thing in our organization. Thus far my efforts have not been fruitful. I will post an update if I happen to get it working.

The advice given here thus far has been a huge help.

Thank you.

[cockneymanc]

I used the following to set this up.

I have AP-deployed, Intune-enrolled W10 devices, enrolling device/user certs from on-prem CA via SCEP and the NDES connector as part of ESP, as described in this article, using an Intune-deployed WIFI profile, connecting to Meraki wifi network, auth'ing against NPS using PEAP-TLS.

https://www.jeffgilb.com/ndes-for-intune/

Only real issue for us is the lack of device-based certificate auth, simply because with AAD-joined devices there are no computer account objects in on-prem AD to add to an AD group used in an NPS condition.  So yes on full-AAD joined devices we have to use User certs, so available post-logon.  If you require device-based certs enabling pre-user-logon auth to the WiFi network, you will prob need to use hybrid AAD join, so you get the computer account on-prem which you can add to a group and use in NPS.

Looks like a lot of work, but it isn't really.  If you already have on-prem AD, on-prem enterprise CA, an Azure tenant, familiarity with AAD Applications/Enterprise Applications, it's not a big deal.  Took a couple of hours.  Good luck 🙂

[Chabs]

Unfortunately your post is pointless!  Everyone already knows how to get user certs to work on inTune devices.

The whole point of the issue is trying to have Intune only devices connect with device certs - so connected before user logins. We obviously don't want to join these in a hybrid manner on prem, we're rolling off on prem, these devices are NON DOMAIN JOINED/non hybrid joined. Not in Active Directory, only AAD. Thank you though! 

[cockneymanc]

Sorry for my pointless post.

More pointless than PhilipDAth's (great) post:

"You'll need to configure Intune to issue certificates from the on-premise CA server using SCEP/NDES.  These certificates are authenticated against the user in AD (they have the username embedded in the certificate)...

...When the user connects to WiFi and presents their certificate RADIUS extracts out the username and then continues to process as normal."

(User certs)

More pointless than RonaldBs (very useful) post:

"I used this method for always on vpn configurations and WPA2 Enterprise PEAP Wifi Configurations based on user certificates."

(User certs)

OP makes no reference to only using device certs.  Are user certs not a valid approach to his desire to prevent his staff connecting personal devices to his Meraki Wifi?

OP says in various replies:

"Apparently it's seemingly impossible find any sort of documentation to explain this from the ground up and work through it step by step.... (i.e. what sort of certificate, what settings do we need in InTune, on the NPS box etc)"

and:

"I actually had a blazing row with MS support cos they were like "oh you need to do this, this and this" but missing vital steps on actually HOW you do those things along the way."

Chabs says:

"Did you ever work this out? I can't believe such a simple part of the puzzle isnt really in any documentation anywhere- how do you configure Microsoft's NPS server to use these cloud SCEP certs for authentication?"

No mention of device certs anywhere?  My psychic powers are letting me down again (i have a similar problem with the wife.......)

So i was trying to be helpful by providing a link to a blog by an Azure senior PFE containing step-by-step instructions on how to set this up, that i know to work as i used it myself when first setting this up.  Yes, it is user-based certs.

RE: device certs, as i think you already know, you are unlikely to get native NPS doing cert auth for non-domain-joined devices.  It is from an era where this requirement was inconceivable and the on-prem domain is the security boundary etc.  I'm sure every guide you have googled starts with 'Create an AD account and....' or 'From a domain-joined machine...'.  Having Meraki auth against a 3rd party RADIUS solution may do the job though, or something like PhilipDAth's nifty idea with Systems Manager agent.

Microsoft's new Always-On VPN (replacing Direct Access) will do machine-based vpn tunnel initialisation, pre-logon, but - unsurprisingly - requires hybrid join so the computer object exists on-prem, for the cert auth to work.  So i think this is also suggestive of the idea you can't do device-based cert auth on a non-hybrid device, using only Microsoft stack.

Good luck with it.  It will be interesting to see what solutions appear.  No doubt an AAD service will appear at some point to provide this sort of facility and 'bridge the gap'.  AAD/Intune/MDM is still in it's infancy really.

CM

[Chabs]

Thank you, gosh yes ignore my strong wording in hindsight. Thanks for your well thought out responses!

[cockneymanc]

All good my friend.  We're all on the same team with this stuff 🙂

[Gmorrallee]

Just a quick update from me as the OP as I realised I'd not checked in here for a while.

So thanks to everyone for their advice - I've not been through it all yet, however. 

So we eventually have the user certificates pulling down to the InTune managed AAD devices and the NPS authenticating these for the WiFi auth - but we've now hit the snag as others have mentioned about lack of ability to user a device cert for AAD devices for the NPS to authenticate against. 

I'm currently trying to work out if we can find a way round this (have seen several suggestions although again things I need to get my head around) or if we can style it out with the client as "a security feature" as WiFi only works when logged on 🙂

[Berlin_IT_Guy]

Hi All,

So I have finally found a solution for Azure Device based certificate Authentication that actually works.

Although it makes use of a paid 3rd party cloud based PKI service and Radius-as-a-Service.

I have tested it and it works like a charm. Setup is also not too complicated.

For those interested and willing to go for a paid service to escape the dependency on on-prem systems, here are the links.

https://scepman.com/

3rd Party CA Certificate Enrollment with Intune

https://www.radius-as-a-service.com/

Cloud Radius

Both services are offered by the same German firm "Glueck & Kanja".

Kind Regards

[ChristianK]

Hi Everyone,

sorry that I've not seen this thread before. And thanks @Berlin_IT_Guy for mentioning our products. Our company has deployed some of the largest 'cloud only' Azure AD ecosystems in the world and received the Microsoft Worldwide Partner of the Year award several times for these kind of deployments. And these deployments are the reason why we were kind of upset that Microsoft still requires on premises components to get the SCEP/PKI and RADIUS stuff done. In the end we've decided to solve this problem which was somehow easier for us because we do had about 20 years of crypto background in the company (years ago we've developed one of the first OpenPGP and S/MIME implementations).

Long story short: Happy if our products help in the Meraki context too. And I would love to give some more background information. 

SCEPman is an Azure KeyVault and Azure AppService based 'SCEP PKI' designed for AzureAD/Intune and available in Azure Marketplace to install within your own tenant. That said, the keys and certificates never leave your  sovereignty. There's a free Community Edition and an Enterprise Edition (with support for Traffic Manager, PKI sub-root and Windows Hello for Business Hybrid support) available.

RADIUS-as-a-Service is currently a multi-geo cloud RADIUS with cert and optional username/password support (i.e. to deploy an amount of fixed devices like printers, kiosk systems or others). But there will be a 'in your own tenant-deployed' version soon so you may also have RADIUS running in your sovereignty.

Happy to answer any questions,

thanks again,

Christian

[SoUnCool]

Hi@ChristianK 

How do you enroll  intune devices in your RADIUS?

[ChristianK]

Hi @SoUnCool ,

sorry again for the late reply, missed the question.

I don't exactly know how do you mean 'hHow do you enroll intune devices in your RADIUS?'. Let me recap what we do, maybe that helps:

All Intune managed devices (Win, Mac, iOS, Android) get the SCEP policy to enrol for a certificate in SCEPman (https://scepman.com). In addition they receive the WPA2 Enterprise profile for a given SSID where the access points are configured to use RADIUSaaS (https://radius-as-a-service.com). RADIUSaaS itself has an administrative portal where you can register the cert root (or just add the SCEPman URL).

That's it. Whenever a device with the SCEPman cert connects to a corporate Wifi the RADIUSaaS is able to validate the access. Because of SCEPman OCSP this validation happens in real-time against AzureAD user- or device-state (enabled/disabled, compliant).

Does this explanation help?

[SoUnCool]

@ChristianKThank you, this helps, I was thinking that you may have done your own RADIUS etc

we looked at this solution but found it not suitable for us and decided to go with https://www.cloudradius.com/

We are able to do device cert auth for wifi access, too bad that Meraki VPN does not support EAP-TLS for device cert VPN auth