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?
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 😉
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.
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.
I'd be tempted by this approach because the Microsoft method is such a lot of work.