WIFI Local Auth is unusable if more than 1 AP

Raido
Comes here often

WIFI Local Auth is unusable if more than 1 AP

I am looking into deploying wireless network with LDAP authentication.

 

Meraki supports "Local Auth" where RADIUS service runs inside access point.

When client authenticates to WIFI then RADIUS in AP will accept credentials and AP will communicate directly to domain controller over LDAP to check credentials.

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

 

My issue is that as RADIUS runs inside access point certificate presented to client when they connect to WIFI is presented by access point.

Meraki has designed every access point to present it's own certificate (even if same SSID is used across all APs).

So when client connects to WIFI and then roams to coverage area of other access point then wireless stops working and user needs to log into WIFI again.

 

This means that any time you have more than 1 access point you can't use Local Auth and only way is to use dedicated RADIUS server.

 

Even link I pasted above says that it is like this by design:

"When using 802.1X - Local auth, each AP uses it's own RADIUS server certificate to authenticate client. Every time a client connects to an AP, it receives the AP's RADIUS server certificate and if the client trusts it, it sends its credentials or its own certificate to be authenticated. The client must trust each AP's RADIUS server certificate on the network?"

 

This design seems to be so dumb. Why can't certificate be SSID based?

Any thoughts?

4 Replies 4
Ryan_Miles
Meraki Employee
Meraki Employee

There's a note on the SSID config page for the RADIUS Client Trust settings

 

"Configure wireless supplicants to expect RADIUS server certificates with the following properties. Use the 'Current organization' certificate name to trust all APs in this organization. Use the 'Current network' certificate name to only trust APs in this network."

Raido
Comes here often

Hey @Ryan_Miles 

I do see this note. Question is how can I utilize the "current network" certificate name to overcome issue with roaming?

 

Flaw of the design is that although "Issued to" is the same across all APs the thumbprint of the certificate is different.

So when client connects to one AP and then roams wireless get's disconnected because client don't trust different certificate from new AP.

 

Raido_0-1680613039611.png

 

Ideal design would use same cert from all APs across the SSID.

 

Claudiosm
Here to help

@Raido, what LDAP server are you using? I'm attempting to use Okta as ldap, and i can't even pass trough the authentication.

 

 

Raido
Comes here often

Although Meraki connects over port 389 it is not clear text LDAP.

It will try to negotiate secure connection it means that LDAP server needs to present certificate and Meraki needs to trust it.

I pointed Meraki directly to AD domain controller as 2FA was not needed for WiFi.

 

After it was clear that Meraki built in LDAP auth is not usable if there is more than 1 AP in the environment I started looking into deploying dedicated RADIUS server.

Initially wanted to use Freeradius but Meraki don't support sending user credentials to RADIUS to perform LDAP binding (it only supports challenge handshake) I took simple path and used domain joined Windows server with NPS service to perform RADIUS to LDAP authentication and it finally works as needed.

 

Challenge handshake don't work with LDAP binding.

http://deployingradius.com/documents/protocols/oracles.html

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels