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.

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.

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.

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
   • Wireless Guests with Optional Acceptable Usage Policy (AUP)
   • Wireless iPSK (Identity Pre-shared Key) for 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. Customizable Access Rules for policy consistency and enforcement of 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. Profiling of endpoints using network protocol attributes for fast classification and easy authorization
8. Licensing verification and estimation in preparation of your production deployment
9. Daily operations to manage and maintain the segmentation and security of your users and devices

Timeline

The overall time to complete a proof of concept can range from a few hours to a few weeks depending mostly on the scale you want to test. The configurations for your scenarios within Access Manager are relatively fast and simple to implement. Your ability to coordinate the required changes across your inventory of devices and clients outside of Access Manager will be the limiting factor. In any case, it is not recommended to spend more than a few weeks.

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.

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.

Default Rule 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 : allow some minimal access by default such as Guest access or Quarantine if no other rules are matched. Access Manager returns a RADIUS Access-Accept and sends whatever combination of VLAN, Adaptive Policy, and Group Policy is you choose to override the network device's settings. What options you choose to use is beyond the scope of this guide.

Adaptive Policy (TrustSec) Security Group Tags (SGTs)

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:

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.

Importing Network-wide Clients

Access Manager maintains a completely separate list list of clients from what you see in Network-wide > Monitor > Clients because not all the switches and access points (APs) may have access controlled by it's Access Rules. If you want to begin authenticating and segmenting these existing clients with Access Rules, you should add them using the network-wide client CSV export or REST APIs.

1. Navigate to Network-wide > Monitor > Clients

2. Select Download v and choose CSV

3. Edit the downloaded CSV by reordering and editing the following columns to match the required CSV import template for Access Manager:

   1. MAC address : move to the first column
   2. Endpoint device group : create/insert this new column and optionally assign ;-delimited group names
   3. Description : move to the third column

1. Save the updated CSV

2. Repeat these steps for each network in your organization

3. See Clients CSV Import section for how to import into Access Manager

If you have more than a few networks, you will want to consider automating the network-wide client export. Look at the github repository github.com/1homas/cam for helpful automation scripts including cam-network-clients.py that does this exactly.

Client 802.1X Supplicant Configuration

Refer to Access Manager - EAP-TLS Client Configuration (Windows, macOS and iOS) for OS-specific instructions to configure your clients for Certificate-based authentication with Access Manager. Manual configuration like this 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), 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
5. Review the authentication events in the Access Manager 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.

MAB Access Rules

Guest Wireless SSID

1. In the Cisco Meraki Dashboard, choose your network to configure
2. Go to Wireless > Configure > Access Control
3. Use the dropdown to choose the SSID name you want to use for Guest access
   1. SSID (name): guest (or whatever you want)
   2. SSID status: Enabled
   3. Under Security
      1. Choose MAC-based access control
      2. Choose Access Manager from the dropdown
   4. Splash page and choose one :
      • None for Hotspot open access
      • Click-through if you require guests to accept an Acceptable Usage Policy (AUP)
   5. Configure any other settings according to your network design including any AUP text, logo, or other theme
   6. Save your changes
4. Within a few minutes your SSID should be broadcasting on your network
5. Repeat this process for any other networks you want to secure with Access Manager

Guest Wireless Access Rule

1. Go to Access Manager > Policies > Access Rules
2. + Add a rule :

1. Connect a guest client to the guest SSID
2. Review the session in the Session Log

iPSK Wireless SSID

1. In the Cisco Meraki Dashboard, choose your network to configure
2. Go to Wireless > Configure > Access Control
3. Use the dropdown to choose the SSID name you want to use for Guest access
   1. SSID (name): ipsk (or whatever you want)
   2. SSID status: Enabled
   3. Under Security
      1. Choose Identity PSK with RADIUS
      2. Choose Access Manager from the dropdown
   4. Splash page must be set to None since IOT devices cannot perform any of the other Splash interactions
   5. Configure any other settings according to your network design
   6. Save your changes
4. Within a few minutes your SSID should be broadcasting on your network
5. Repeat this process for any other networks you want to secure with Access Manager

iPSK Access Rule

1. Go to Access Manager > Policies > Access Rules
2. + Add a rule to create these access rules :

1. Connect one or more iPSK wireless endpoints to the iPSK SSID
2. Review the Session Log for the authentications

Client iPSK Configuration

1. Navigate to Access Manager > Configure > Clients
2. ⛭ in the Clients table and enable the iPSK column if it is not already visible
3. Assign an iPSK to an existing client by selecting the MAC address of the client
   • iPSK: my-client-ipsk (must be 8–63 characters)
   • Save.
4. Assign an iPSK to a new client by selecting + Add Clients > Add a Client
   • MAC address: xx:xx:xx:xx:xx:xx
   • Description: optional
   • iPSK: my-client-ipsk (must be 8–63 characters)
   • Client Groups: optional
   • Save

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
3. Ensure you upload a full trusted certificate chain by compiling all intermediate and root certificates into a single .cer or .crt file.
4. 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.
5. Refer to Microsoft - Export a trusted client CA certificate chain for detailed guidance.
6. Choose the Identity and features you want to enable for each CA certificate chain you upload:
   1. Identity: Subject Alternative Name RFC822 (recommended)
   2. Choose the certificate attribute with a value that matches the user's email address - or user principal name (UPN) - in Entra ID. This is usually the Subject Alternative Name RFC822 field (email address) but it might be one of the other fields. 
      1. Status: Enabled for all certificate authorities you want to trust
      2. Use for Extended Local Authentication: 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.
      3. Be sure to enable Extended Local Authentication on both the Certificate and the SSID Access Control page.
      4. Trusted Anchor: must be enabled on at least one certificate in the chain
7. Select Save.

Certificate Authorizations

Just like all other access control scenarios, you may use any attributes available from the available Attribute Sources. In the case of certificates, you may create Access Rule conditions against any of the attributes in the Endpoint certificate attribute source to differentiate access for your various users and machines.

If you do not have a way to view your user or client certificates before creating the respective Access Rule(s) for them, simply connect your client and view their certificate attributes in Access Manager's Session Log Details. Even if the authentication fails, you will be able to view all of the client certificate's subject attributes to match them in your Access Rule(s) for proper authorization.

See EAP-TLS Certificate-Based Authentication with Entra ID Lookup - Cisco Meraki Documentation

Machine Certificate Authorization Access Rule

Access rules for machine authorization typically should filter on the EAP-TLS authentication protocol then check any of the available certificate subject attributes you need to differentiate it from other groups of clients using certificates. This may involve components of the Common Name or a custom string in a subject alternative name (SAN) attribute depending on how your organization issues certificates. Here is a simple example:

User Certificate Authorization Access Rule

Access rules for user authentication should check for the EAP-TLS authentication protocol then any of the certificate subject attributes to differentiate groups of user certificates. This may involve Common Name components like the Department or Organization Unit (OU) or simply checking the domain of a SAN RFC822 attribute - a very technical way to say an email address - based on how you issue certificates. Here is a simple example:

User Certificate Authorization Access Rule with Entra ID Lookup (optional)

This scenario requires your Access Manager Certificates Identity attribute configuration to match whichever attribute in your certificate contains the user principal name (UPN) in Microsoft Entra ID. Typically this is the subject certificate's SAN RFC822 attribute. Access Manager will use the specified attribute to perform a query against your Entra ID tenant to obtain the specified user's group memberships and other attributes in Entra ID. These attributes will then be available as an Access Rule Attribute Source to match for differentiated authorization. Here is a typical example:

Client Certificate Testing

Ensure your clients have been configured for 802.1X and EAP-TLS as discussed in Client 802.1X Supplicant Configuration.

1. Connect one or more clients to :
   • a switch port assigned a Switchport Access Policy with Access Manager
   • a wireless SSID configured with Enterprise security with Access Manager
2. Review the Session Log for the authentication results
   1. The most common client configuration error is not downloading the Access Manager certificate and adding it to the client's trusted root certificate store causing the client not to trust Access Manager's authentication challenge.
   2. If the client was not authorized correctly, look at the Session Log Details and review the device, session, and client details including the client certificate attributes to ensure what it sent matches one of your configured (and enabled) Access Rules.

Entra ID Group Authorization Access Rule

User Authentication Testing

Ensure your clients have been configured for 802.1X and EAP-TTLS as discussed in Client 802.1X Supplicant Configuration.

1. Connect one or more clients to :
   • a switch port assigned a Switchport Access Policy with Access Manager
   • a wireless SSID configured with Enterprise security with Access Manager
2. Review the authentication events in the Access Manager Session Log
   1. If the Status is Success, verify it matches the Access Rule and authorization you were expecting
   2. A Status of Failed means the client could not talk to Access Manager using the EAP-TTLS+PAP protocol
      1. Verify the client configuration is configured to support EAP-TTLS+PAP authentication
      2. Verify the client has the Access Manager certificate installed in the client's trusted root certificate store to trust Access Manager during the authentication challenge
   3. A Status of Rejected means the client did not match one of your configured Access Rules
      1. Select the Status value to review the device, session, and client details and their respective attributes
      2. Verify one or more of your Access Rule conditions match these attributes to authorize it as you expect