Cisco Access Manager Deployment Guide

Components

Implementing network access control (NAC) is a solution - not a product - that combines many different products with different capabilities. Access Manager your AAA (authentication, authorization, and accounting) service in the Cisco Meraki Dashboard that implements network access security policy using the RADIUS protocol for users and devices with these components.

Trial Licensing 

An Access Manager license is required to enable Access Manager in your Meraki dashboard organization. Customers may request a free, 90-day trial license to conduct a proof of concept.

Proof of Concepts (POCs)  

A proof of concept (POC) with Cisco Access Manager (CAM) is very easy to conduct using your existing Meraki organization and starting with only a single wireless SSID or switch port. You do not need to deploy zero trust access on every port and SSID in every location to prove that Access Manager can solve your segmentation problems. Prove on a small scale that it works for your biggest problems then incrementally expand it to cover more locations, devices, scenarios, security methods, and endpoint types. Configuring each scenario can be done in minutes to hours, based on the number of dependencies to coordinate. Anything longer is usually not a technical issue but a symptom of the collaboration difficulties across your network, security, and other IT teams.

Scope 

This guide will show you how to validate Cisco Access Manager's ability to deliver consistent access control and segmentation using:

1. Campus and Branch environments
2. Cisco Meraki and Catalyst network devices
3. Wired and Wireless access methods
4. Authentication methods:
   • MAC Authentication Bypass (MAB) for Wired I/OT Endpoints including profiling for automatic classification
   • Guest Wireless with Optional Acceptable Usage Policy (AUP)
   • iPSK (Identity Pre-shared Key) for Wireless I/OT Endpoints
   • Machine Certificate Authentication (EAP-TLS)
   • User Certificate Authentication Auth (EAP-TLS) with optional Entra ID Lookup
   • Username/Password Authentication (EAP-TTLS+PAP) with Entra ID Lookup
5. Access Rules for custom policies implemented consistently for the enforcement of the Principle of Least Privilege
6. Authorization with one or more segmentation options:
   • VLAN ID/Name : assign a VLAN name or number (dynamic VLAN assignment)
   • Voice Domain : send the Cisco Vendor-Specific Attribute to use the Voice VLAN Domain
   • Adaptive Policy : classify this session's traffic with this Adaptive Policy (TrustSec) Security Group Tag (SGT)
   • Identity PSK : require a specific pre-shared key (PSK) value for this endpoint to associate wirelessly
   • Group Policy : apply the named Meraki Network Group Policy to this session
7. License Usage : verification and estimation in preparation of your production deployment
8. Operations : manage and maintain the segmentation and security of your users and devices

Depth vs Breadth  

When deploying access control across your entire network, there are typically two methodologies:

• depth-first : implement all authentication and authorization scenarios in a single device or location before moving to the next one
• breadth-first : implement a single scenario on every device in every location consistently before tackling the next one

Realistically, every deployment is somewhere between these two. But avoid the big bang methodology - where you try to lockdown every thing every where all at once - because it will blow up in your face. There are many exceptional scenarios you will discover and snowflake client configuration drifts that you will encounter so try not to experience them all on the same day. Even when you have secured every port and SSID, there will always be new network device hardware or branch offices or new endpoint types requiring a unique authorization. This is the nature of network security.

Timeline 

The overall time to complete a proof of concept or production deployment can range from a few hours to a few weeks depending the number of scenarios and the scale of your networks and devices. The configurations of scenarios within Access Manager are relatively fast and simple to implement. However, your ability to coordinate the required process and policy changes with your peers across your inventory of devices and clients outside of Access Manager will be the limiting factor. You cannot go from completely open network access to fully secured and segmented overnight.

Authorization  

When creating an Access Rule, after defining the matching conditions you may define how you would like to authorize the user or client to enforce the principle of least privilege in your network.

When creating or editing an Acces Rule, under the Authorization section, click on the Access permission dropdown to choose your desired option(s):

• Deny Access : Access Manager returns a RADIUS Access-Reject so there is no session started for this request and it should not receive an IP address
• Allow Access : Access Manager returns a RADIUS Access-Accept and the network permissions are whatever the network device has configured on the port or SSID
• Allow restricted access : Access Manager returns a RADIUS Access-Accept and sends whatever combination of network segmentation options you choose below to override the network device's default settings :
  • VLAN ID/name: dynamically assign a VLAN name or number - the VLAN identity must be defined in the network where the endpoint is authenticating
  • Voice domain: enable this option to put the client into the local voice VLAN
  • Adaptive policy: assign an Adaptive Policy Group (TrustSec SGT). Refer to the Adaptive Policy documentation for further details.
  • Identity PSK: require the assigned PSK - based on the 3 options below - to match the endpoint's PSK to complete the 4-way handshake for authentication :
    • Client iPSK only: use the client's iPSK passphrase configured in the Clients table to enforce per-MAC iPSK 
    • Client iPSK with fallback: use the client's iPSK passphrase configured in the Clients table or if it is undefined, fall back to the passphrase set below. Use this when transitioning a group of clients sharing a single PSK to the more secure per-MAC Client iPSK only policy.
    • Override client iPSK: all clients matching this rule must use the same specified passphrase, regardless of any per-client iPSK setting. Use this for a client groups that share a PSK. This was the previous Access Manager setting before the per-MAC iPSK option.
  • Group policy: Assigns a Meraki Group Policy by name. Refer to the Group policy documentation for details.

Default Rule Authorization 

Access Rules are evaluated top-down like any firewall policy by trying to match the device, session, client and authentication attributes against conditions. If no rules match, there is a final, catch-all, default rule and authorization. Before implementing any security policies in Access Manager, it's good to choose your default Access Rule.

1. Navigate to Access Manager > Policies > Access Rules and review the Default Rule's Authorization value which should be Deny Access for a secure default setting.
2. Select the Default Rule name to edit it's Authorization access permissions and choose your desired default:
   • Deny Access : the secure default for a closed network. All endpoints must match an explicit Access Rule so nothing may sneak in. Access Manager returns a RADIUS Access-Reject so there is no session started for this request.
   • Allow Access : the permissive default for an open network which is very useful for getting initial client visibility in production networks to prevent disrupting their network access when creating initial Access Rules. Access Manager returns a RADIUS Access-Accept and settings are whatever the network device has configured on the port.
   • Allow restricted access : customize it to allow some minimal access that you define (Guest or Quarantine) Access Manager to return with a RADIUS Access-Accept to override the network device's settings for the session. Which options you choose and why depends on your security requirements.

Monitored vs Enforced  

There are two approaches to deploying any kind of network access control for the first time:

• Monitored : allow all access by default in order to first gain visibility into all of the endpoints connecting to your network and assess how to match and authorize them for proper segmentation. This allows you to begin an incremental process of identifying and securing different populations of endpoints and users without disruption until you can notify them about any impending enforcement deadlines.
• Enforced : deny all access by default and only allow things that match your explicitly configured rules so that nothing sneaks into your network without the expected authentication method. This is often done in highly secure government and financial networks where security is the top priority.

If you will be testing access manager in a lab environment or on a very limited set of switch ports and SSIDs, you should use the secure default of Deny Access for your Default Rule. If you are trying to deploy on a live production network for the first time you should consider using the Allow Access default since you probably don't have any existing access control policies or segmentation in place anyway.

Adaptive Policy   

Adaptive Policy is the Meraki Dashboard name for Cisco TrustSec with security group tags (SGTs) and security group access control lists (SGACLs). While Adaptive Policy is not required for enforcement with Access Manager, we believe it provides superior microsegmentation over VLANs and without the complexity of traditional L3/L4 access control lists. Adaptive Policy capabilities are included with Access Manager but does require Meraki Advanced device licenses.

Even if you do not use Adaptive Policy to enforce segmentation initially, you are encouraged to configure it to begin thinking in terms of group-based policies. Adaptive Policy is not enforced until you enable it on specific networks which means you may also deploy it incrementally within specific networks when you are ready.

1. Navigate to Access Manager > Policies > Adaptive Policy > Groups
2. + Add Group for each of these tag names or whatever you think will apply in your network :
   • Unknown
   • Infrastructure
   • NetServices
   • Quarantined
   • Workstations
   • IOT
   • Employees
   • Guests
   • Cameras
   • VOIP
3. Navigate to Access Manager > Policies > Adaptive Policy > Custom ACLs
4. Select + Add custom ACL and create this example security group ACL :
   • Name: BlockMalware
   • Description: Block typical malware attack vectors or services that should not be running on desktop computers
   • IP Version: Any
   • Rules: complete the table below

1. Go to Access Manager > Policies > Adaptive Policy > Policies to view the matrix of source and destination tags.

   • The default value in each cell is Allow All.
   • The cells where the source and destination groups intersect is where you may Allow, Deny or apply a Custom ACL on the traffic between them.

2. When you are ready to enforce the group policies, go to Access Manager > Policies > Adaptive Policy > Networks

   1. Select the network(s) to you want to apply the group policies
   2. Select Enable to apply them and Disable to remove them
   3. Wait a few minutes while the Meraki Dashboard pushes the changes to network devices

Client Management 

There are several different options to manage clients in Access Manager depending on the scale and requirements.

Client 802.1X Supplicant Configuration  

Refer to the separate, dedicated documents for OS-specific instructions to configure your clients for Certificate-based authentication with Access Manager.

• EAP-TLS Client Configuration
• EAP-TTLS Client Configuration

Manual configuration of EAP settings is fine for testing individual computers, but to do this consistently for all your endpoints at scale, you will need a unified endpoint manager (UEM) application, also known as a mobile device manager (MDM) platform.

Switch Port Access Policies 

1. Go to Switching > Configure > Access Policies
2. + Add Policy to create a new one with the following best practice defaults :
   • Name: AM_Hybrid_MultiAuth
   • Authentication method: Access Manager
   • Connection:
     • Policy Type: Hybrid Authentication
     • Host mode: Multi-Auth
     • 802.1X control direction: Both
     • Re-authentication interval: 3600 (seconds)
   • Options
     • ☑ Voice Auth
     • □ Disable port bounce
   • Configure all other settings at your discretion
   • Save
3. Assign Access Policies to Switch Ports

Assign Access Policies to Switch Ports

1. Go to Switching > Monitor > Switch Ports
2. Select one or more switch ports that you want to assign your Access Policy using Access Manager
3. Select Edit and use the following values:
   • Port Status: Enabled
   • Type: Access
   • Access Policy: AM_Hybrid_MultiAuth (or whichever name you gave your policy with Access Manager)
   • Update to save and wait for the network devices to update
4. Connect one or more endpoints to the assigned ports to verify they are challenged for 802.1X or failover to MAB based on the policy configuration
5. Review the authentication events in Access Manager > Monitor > Session Log

Wireless SSID Security 

There are 3 different SSID Security options that Access Manager supports in the Meraki Dashboard :

1. MAC-based access control : MAB for MAC filtering with open Hotspot or Acceptable Usage Policy (AUP). See Guest Wireless SSID for configuration details.
2. Identity PSK with RADIUS : the client's association PSK must match the PSK returned by Access Manager. See iPSK Wireless SSID for configuration details.
3. Enterprise: uses 802.1X and EAP (Extensible Authentication Protocol) to authenticate users and machines. See Enterprise Wireless SSID for configuration details.

These three different security methods mean that you will different SSIDs to accommodate each of these access methods.

MAC Auth Bypass (MAB) for Wired IOT 

MAC authentication bypass - or MAB - is a non-standard RADIUS authentication request type used to identify and authenticate a client by MAC address instead of using the 802.1X and EAP protocols. This is a very common scenario especially for headless IOT devices, not necessarily due lack of operating systems support of the 802.1X protocol, but because network security is simply not a priority for the team that owns and manages the clients.

There are two ways to identify and group clients for authorization and segmentation that rely on MAB authentication:

• Static Clients Groups : the administrator manually enters and assigns client MAC addresses to Client Groups which are then matched in Access Rules for authorization
• Dynamic Profiling Classifications : every client that attempts authentication with Access Manager is automatically profiled using DHCP, CDP, and LLDP protocol attributes and classification labels are assigned for their device Type, Manufacturer, Model and OS. These classification labels may then be used in access rules to authorize them without needing to maintain static inventories of Client Groups by MAC address.

See the section Client Management for how to quickly create Client Groups and assign known client MAC addresses to them with Client CSV Import from your existing Network-Wide Clients.

The following sequence is typical for a MAB authentication and authorization flow:

1. The client initiates the connection with the SSID or switch port. 
2. The network device will challenge the client with an IEEE 802.1X authentication request
3. The client will not respond to the challenge because it does not support or have 802.1X configured
4. The network device will timeout the 802.1X challenge process
5. At some point, the endpoint will have sent Ethernet frames identifying it's MAC addres
6. The network device will send a RADIUS MAB request containing the client MAC to Access Manager for authorization
7. Access Manager evaluates the MAC, network device, and session attributes against the access rules for a match on their conditions
8. The authorization permissions (SGT, VLAN, etc.) from the first matched access rule will be sent to the network device for enforcement
9. The network permissions for the client's session will be enforced by the network device based on it's security capabilities

Guest Wireless 

There are two types of Guest access supported by Access Manager:

• Open, hotspot for simple, direct access without interruption
• Click-through with Acceptable Usage Policy (AUP) for branding, time, traffic, or legal disclaimers you want to communicate to guest users

There are advantages to using Access Manager for your guest access scenarios over wireless security without it :

• automatic profiling of your guest endpoints to give you insights about their device types
• optional filtering of any guest endpoints by MAC or Profile
• visibility of all guest sessions to understand the location, frequency, scale, and profiles of the guest access service

All guest sessions will consume an Access Manager license for the duration of their session.

In the example guest flow 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 (MAC filtering) the MAC address 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 the guest user completes the AUP process, Splash Access allows the guest out to the Internet

iPSK for Wireless IOT 

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.

Access Manager has 3 different options for assigning an identity pre-shared key (iPSK) for a client in the Access Rule authorization:

• Client iPSK only: Only clients with a configured iPSK passphrase can authenticate against this rule. Use this to require and enforce per-MAC iPSK. Configure the per-client MAC in the Clients page.
• Client iPSK with fallback: Clients with a configured iPSK passphrase use it to authenticate; all other clients fall back to the passphrase set below. Use this when transitioning from a shared PSK for all clients to the more secure Client iPSK Only policy. Configure the per-client MAC in the Clients page.
• Override client iPSK: All clients authenticate using the passphrase set below, regardless of any per-client iPSK. Use this when all clients matching a rule all use the same PSK. This was the previous behavior where all clients matching a rule must have the rule's assigned PSK.

The typical authentication flow for an iPSK authentication and authorization is :

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 Cisco 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 and since they match, it is authorizedasdf
7. The scanner gets a DHCP IP address and all it's traffic is tagged with a Scanner SGT

Certificate Authentication (EAP-TLS)  

Traditional Pre-shared Key and username/password based authentication have become increasingly vulnerable to attacks. The EAP-TLS authentication allows administrators to control network access for managed users and endpoints using digital certificates. The Access Manager access rules will evaluate the authentication request based on the client (subject/user/machine) certificate's attributes to differentiate their network access.

A certificate is considered authentic if :

1. it has been signed by a trusted certificate authority (CA) configured in Access Manager's Certificates page
2. the client certificate is within the validity period specified in the certificate
3. the certificate has not been revoked by the CA using a certificate revocation list (CRL)

In the EAP-TLS authentication flow above:

1. A user's workstation is has been configured to use 802.1X with a user or machine certificate
2. The user connects their computer workstation to a network device (a switch or access point AP
3. The network devices challenges the workstation with an 802.1X authentication request
4.  The workstation sends it's configured client certificate as it's authentication credential through encrypted EAP tunnel to Access Manager
5. Access Manager authenticates the certificate if the Certificate Issuer CN matches one of Access Manager's Trusted Certificate Authorities (CAs)
6. If an access rule contains an Entra ID user (not device) group lookup in a condition, the groups are retrieved 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 (typical)
7. Access Manager returns an authorization for the workstation's session to the network device containing an Employees security group tag (SGT) assignment
8. The workstation gets a DHCP-assigned IP address and all it's traffic is tagged with a Employees SGT

Username+Password Authentication (EAP-TTLS) with Entra ID Group Lookup 

You may perform username+password authentication of users to the Entra ID identity provider (IdP) and match their group memberships or other attributes. With username/password based authentication (EAP-TTLS/PAP) against Entra ID, you can control network access to managed endpoints without the need for deploying a public key infrastructure (PKI) with a certificate authority (CA). 

In the EAP-TTLS 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

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

Import and Enable PKI Certificate Chain

1. Navigate to Access Manager > Configure > Certificates
2. Select Upload CA certificate and choose the full chain of your PKI's root CA
   Ensure you upload a full trusted certificate chain by compiling all intermediate and root certificates into a single .cer or .crt file.
   Begin by exporting each certificate in the chain as a Base64 encoded .cer file. Open each exported file with a text editor, and copy the entire contents. Paste them sequentially into a new text file, ensuring there are no extra spaces or lines between certificates. Save this file with either a .cer or .crt extension to create the complete certificate chain.
   Refer to Microsoft - Export a trusted client CA certificate chain for detailed guidance.
3. Configure the certificate features for the uploaded CA certificate :
   • Identity: Subject Alternative Name RFC822 
     This is the certificate subject's identity and for Entra ID group lookup it must contain the user principal name (UPN) which is usually the Subject Alternative Name RFC822 field (email address) 
   • Status: Enabled
     Enable for all certificate authorities you want to trust
   • Use for Extended Local Authentication: (optional) 
     When enabled, wireless APs will cache certificates from this CA for fallback authentication if the connection to the Meraki Dashboard and Access Manager is unavailable for any reason. During fallback, Access Manager rule evaluation will not work and the VLAN configured on the SSID will be applied after successful authentication. it  must be enabled for both the Access Manager certificate and the SSID Access Control page.
   • Trusted Anchor: Enabled
     Must be enabled on at least one certificate in the chain
4. Select Save.

Microsoft Entra ID Integration  

You may configure Microsoft Entra ID integration to synchronize all users, user groups, and attributes and store these in the Cisco Meraki Dashboard database. A proactive synchronization may be enabled to occur every 6 hours and you may initiate a manual synchronization at any time.

Synchronizing Entra ID data (users, groups, attributes) eliminates the need for API requests for each session, reduces latency, and avoids Microsoft's service limits. After successful certificate authentication, Access Manager uses the endpoint certificate's username to query the synchronized Entra ID database. Access rules are then applied to the session to determine authorization (such as SGT or VLAN) based on user groups like HR, Finance, or other Entra ID attributes.

1. In the Cisco Meraki Dashboard, go to Access Manager > Configure > Users
2. + Create IdP and connect your Microsoft Entra ID tenant following the Organization End Users instructions
3. Review the Synced Users & User Groups to ensure you have all the users and representative group

License Usage

Your license consumption for all concurrently active sessions is tracked in Access Manager > Monitor > Session Logs > Active Sessions and offers filters by networks. It also includes a metric panels for the 90th percentile daily sessions which is the value used for tracking compliance.

Session Log Archiving 

Access Manager saves a maximum of 31 days of sessions via API and 30 days in the Dashboard. Export of Session Logs via the Dashboard is not supported, either. Your only option for exporting Session Logs for metrics or audit beyond 31 days is to download them using the /nac/sessions/history REST API.

Client Export

The Access Manager > Configure > Clients page has no client export option and you must use use the /nac/clients REST API.  You may create your own or consider using an existing free, open source script, cam-clients.py, that can get, create, update, and delete Access Manager clients.

Guest Client Purge 

The Access Manager > Configure > Clients page is where you see and manage all clients that have been provisioned via Dashboard, CSV, or REST API or discovered from RADIUS authentication requests. They all will be collected there for visibility until you explicitly delete them. In the case of guest clients which are quite transient and typically use randomized MAC addresses, you will probably want to purge them from your Clients page regularly to remove clients no longer of interest and to keep searches fast.

Since Access Manager does not have a specific Guest Purge feature, you must use the Clients > Filters option (match on your guest SSID) and manually select and delete by the Last Seen date. A much faster approach is to use a script with the /nac/clients/bulkDelete REST API. You may create your own or consider using an existing free, open source script for this purpose : cam-guest-purge.py