Access Manager - Architecture And Example Use Cases
Access Manager provides a unified way of securing network access through a single dashboard. With these newly added cloud-delivered features, IT teams can seamlessly and effortlessly enforce and monitor identity and context-based access to the users and devices connecting to their networks – all without the need for the deployment and management of an external RADIUS server.
Note: Access Manager is currently in early access preview and will be rolled out to customer organizations in phases. During this period, there will be no licensing enforcement (free trial for all organizations). Licensing details for general availability will be shared soon.
Once it is available on your organization, you can participate in a free trial by opting-in to Access Manager on Early Access page (Organization > Early Access).
Architecture
There are three major components in the Access Manager architecture:
- Network Devices
- Identity and Security integrations
- Cloud-delivered Access Manager services
Network Devices: These are the devices like Switches and Access Points that provide network connectivity to the users and endpoints. When an endpoint connects to a SSID or a switchport that uses Access Manager as its authentication server, the authentication requests will be forwarded to Cisco Meraki Cloud for policy evaluation.
Identity and Security Integrations: Integrations with external products and services like Microsoft Entra ID etc. that provide identity, security and behavior context for a user or an endpoint connecting to the network. An administrator has the ability to include any identity or context information from these integrations as a part of matching criteria in the policy evaluation.
Cloud-delivered Access Manager Services: Services like Authentication, Authorization, Monitoring etc. that are deployed and managed by Cisco. These services make the policy decision based on the identity, context and behavior-based access rules configured by the administrator (an access rule has matching criteria and corresponding authorization result you can apply for any endpoints that match the matching criteria).
Use case Examples
We have many potential use-cases that support the requirements of PCI compliance, IoT device security, zero trust network access etc. Also, with the growing list of features and integrations’ support, we can support robust and seamless event driven identity and context-based authorization. Following are some of the currently supported major use-cases:
Use Case | Authentication and authorization |
Securing endpoints that are managed by your organization |
Certificate based authentication (EAP-TLS) with Entra ID user lookup to apply user identity based authorization. Apply authorization (SGT, VLAN, Group Policy etc.) based on Entra ID user group membership like HR, Finance etc. and user attributes like City, State, Job title etc. Username and password based authentication (EAP-TTLS/PAP) with Entra ID user lookup to apply user identity based authorization. Similar to the above, you can apply authorization (SGT, VLAN, Group Policy etc.) based on user group membership and user-attributes from Entra ID. |
Securing non 802.1X supported IoT, OT etc. or other endpoints |
MAC Authentication Bypass (MAB) and/or iPSK Apply authorization (SGT, VLAN, Group Policy etc.) based on specific or part of MAC address or endpoint groups with many MAC addresses. Also, using iPSK to apply authorization (SGT, VLAN, Group Policy etc.) based on unique pre-shared keys (PSKs) used by endpoints connecting to the network. |
Securing Managed Endpoints - EAP-TLS Authentication with Entra ID Lookup
Traditional Pre-shared Key and Username/Password based authentication have become increasingly vulnerable to several sophisticated phishing and brute force attacks. This is the reason why certificate-based authentication is one of the first methods we are supporting. Cisco highly recommends certificate-based authentication for managed endpoints wherever possible.
With certificate-based EAP-TLS authentication support, you can define and control network access to your managed endpoints that have client certificates deployed on to them. When a configured client connects to your Network Device (Switch or Access Point), the authentication requests will be forwarded to Cisco Meraki cloud. The services within the Cisco Meraki cloud will authenticate and authorize the session based on the rules you have configured on your dashboard.
For example, as shown below, an endpoint is authenticating using the certificate installed on it. Cisco Meraki Cloud receives the authentication response and evaluates the session against the rules configured by the administrator. In this example, an administrator has configured a rule that matches against the Certificate Issuer CN and Entra ID’s user-group. Any session that matches these conditions will receive a VLAN 250 and an SGT 30.
Securing Managed Endpoints - Username/Password Authentication against Entra ID
Although certificate based authentication is the most secure method, some organizations may not have their own PKI infrastructure and/or need an alternative method such as username and password authentication.
With Username/Password based authentication (EAP-TTLS/PAP) against Entra ID, you can control network access to your Managed endpoints without the need for deploying and maintaining external PKI infrastructure. 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 the credentials are entered and connection is initiated, the authentication requests will be forwarded to Cisco Meraki cloud. The services within the Cisco Meraki cloud will authenticate the endpoints against configured Entra ID. If the authentication is successful, the session will be authorized based on the rules you have configured on your dashboard.
For example, as shown below, an endpoint is authenticating using Username and Password. Cisco Meraki Cloud receives the authentication response and passes it to Entra ID. Once the authentication is successful, Access Manager will evaluate the session against the rules configured by the administrator. In this example, an administrator has configured a rule that matches against the Entra ID’s user-group. Any session that matches this condition will receive a VLAN 150 and an SGT 15.
Securing non 802.1X Supported IoT, OT or Other Endpoints - MAC Authentication Bypass (MAB)
Securing non 802.1X supported endpoints like cameras, printers, building management devices, IoT and OT devices etc. is even more important as these devices are traditionally prone to several security vulnerabilities and an easy target of several cyber-attacks.
As a part of early access preview, we are supporting MAC Authentication Bypass (MAB). Segmentation based on the results of device profiling and classification will soon follow.
For example, as shown below, an endpoint like a smart thermostat which does not support 802.1X , does not send any EAP packets. After 802.1X times out, when the endpoint sends any packet, the Network Device (Switch or Access Point) uses the source MAC address as the identity in the RADIUS access request it sends to Cisco Meraki cloud. Cisco Meraki Cloud does a lookup into its clients database and assigns an authorization after the evaluation against the rules configured by the administrator. In this example, any client that matches the condition of “part of Smart thermostats group” will receive VLAN200 and SGT20.
Optionally, if you need an extra layer of security over the traditional MAC Authentication Bypass that only uses MAC address to bypass the authentication, you can assign an IPSK passphrase as the authorization result in the access rule. In this scenario, when an endpoint is connecting using an IPSK passphrase that matches with the IPSK passphrase assigned in authorization, the rule will be matched and corresponding other authorization/s assigned (VLAN, SGT etc.) will be applied to the session. This will be useful in cases where you would need an extra layer of security over the traditional MAC Authentication Bypass that only uses MAC address to bypass the authentication.