Cisco Access Manager - Architecture And Example Use Cases

EAP-TLS Certificate-based Authentication (Entra ID User Lookup Optional) 

Traditional Pre-shared Key and username/password based authentication have become increasingly vulnerable to attacks. EAP-TLS authentication allows administrators to control network access for managed users and endpoints using digital certificates. The Access Manager services within the Dashboard will evaluate the session based on the configured rules. Access Rule conditions may perform matches on any Endpoint Certificate attributes for the subject whether a user or device/computer to differentiate network access

For the example above:

1. A user's workstation is has been configured to use 802.1X with a user and/or machine certificate
2. The user performs a login or connects their computer workstation to a switch or access point (AP) which initiate an EAP-Start (extensible authentication protocol) over 802.1X
3.  The workstation sends a digital certificate as it's authentication credential through the EAP tunnel via RADIUS authentication request to Access Manager
4. Access Manager validates the certificate if the Certificate Issuer CN matches one of Access Manager's Trusted Certificate Authorities (CAs)
5. If an Access Rule contains an Entra ID user (not device) group lookup in a condition, Access Manager retrieves the groups for the user identity using the certificate attribute configured in the Certificates page for the respective CA:
   • Subject common name
   • Subject serial number
   • Subject alternate name: DNS
   • Subject alternate name: RFC822
6. Access Manager returns a RADIUS authorization to the network device containing an Employees security group tag (SGT) assignment
7. The workstation workstation gets a DHCP-assigned IP address and all it's traffic is tagged with a Employees SGT

EAP-TTLS/PAP Username/Password Authentication with Entra ID Lookup 

While certificate based authentication is the most secure method, some organizations may not have their own Public Key Infrastructure (PKI), and so require an alternative authentication method such as username and password.

With username/password based authentication (EAP-TTLS/PAP) against Entra ID, you can control network access to managed endpoints without the need for deploying PKI. When an endpoint connects to your Network Device (switch or access point), the endpoint will be prompted to enter the username and password (Entra ID credentials). Once entered, the authentication requests will be forwarded to to the Cisco Meraki cloud and Access Manager services within the cloud will authenticate the endpoints against the Entra ID. If the authentication is successful, the session will be authorized, and access granted based on the configured rules.

In the authentication flow above:

1. A user connects their computer workstation to a switch or access point (AP) which initiates an EAP-Start (extensible authentication protocol) over 802.1X
2. The user enters their Microsoft Entra ID user principle name (UPN, username@domain.onmicrosoft.com) as the username and their password 
3. Cisco Access Manager receives the authentication response and proxies it to Entra ID using OAuth
4. After Entra ID authenticates the user successfully, Access Manager obtains the user's group memberships for evaluation against it's Access Rules
5. Access Manager finds a match for the user in the Access Rule named Employees
6. Access Manager returns a successful authorization to the network device allowing access and assigning a security group tag (SGT) to the endpoint's traffic
7. The user's workstation gets a DHCP-assigned IP address and all it's traffic is tagged with a Employees SGT

MAC Authentication Bypass (MAB) for IOT Endpoints 

Unmanaged endpoints, such as Internet of Things (IoT) and Operational Technology (OT) devices that do not support 802.1X are traditionally prone to security vulnerabilities, so it is essential to find a method to secure these devices. Access Manager can be used to secure unmanaged endpoints using MAC Address Bypass (MAB).

In the example above:

1. A camera is unconfigured for 802.1X but attempts to connect to the network
2. The switch uses 802.1X to initiate an EAP-Start (extensible authentication protocol) request to the endpoint
3. The camera ignores all EAP challenges since 802.1X is unconfigured and the EAP process times out
4. The switch initiates a MAC Authentication Bypass (MAB) request to Cisco Access Manager since it knows the camera's MAC address from the source address in DHCP and other traffic
5. Access Manager find the MAC address belonging to the Cameras client group and matches the Access Rule for Cameras
6. Access Manager returns the RADIUS authorization which includes a security group tag (SGT)
7. The scanner gets a DHCP IP address and all it's traffic is tagged with a Camera SGT

Identity Pre-Shared Key (iPSK) for IOT Endpoints 

Wireless I/OT endpoints often do not have sophisticated interfaces enterprise authentication with 802.1X or certificate management. Many do support basic wireless pre-shared keys (PSKs) but it is not a good security practice to use the same PSK for all endpoints in your network in case it is leaked. It is much better to use a unique, identity pre-shared key (iPSK) tied to an endpoint (client) group or even endpoint MAC address.

In the example above:

1. The handheld scanner attempts to associate to the wireless access point (AP) with it's configured pre-shared key (PSK)
2. The AP performs a new RADIUS MAB request to Access Manager
3. Access Manager verifies the MAC belongs to the Client Group named Scanners
4. Access Manager checks the Access Rules and matches the Scanners rule for all members of the Scanners client group
5. Access Manager returns an authorization to the AP with a security group tag (SGT) and the iPSK assigned for the Scanners client group
6. The AP compares the scanner's iPSK with the assigned PSK from Access Manager if they match, it is authorized
7. The scanner gets a DHCP IP address and all it's traffic is tagged with a Scanner SGT

Wireless Guests with Splash Access  

In the example above:

1. A guest user associates to an Open, unencrypted SSID ("AM-Guest") that is configured to use Splash Access with an Acceptable User Policy (AUP)
2. The AP sends a RADIUS MAB request to Access Manager
3. Access Manager verifies there are no Access Rules blocking the MAC address (MAC filtering) then matches the Guests rule
4. Access Manager returns an authorization to the AP with a security group tag (SGT), 'Guests'
5. The Guest computer gets a DHCP IP address
6. The Guest computer operating system detects that a captive portal (Splash Access) is preventing Internet access and opens a browser window to the portal
7. After completing the AUP process, Splash Access allows the Guest out to the Internet