Back
Lesson 5 of 7

Network Device Onboarding

Objective

Add network devices to Cisco ISE, configure RADIUS and TACACS+ shared secrets on the network device, and organize devices into Network Device Groups (NDGs). This lesson explains the why and how so you can secure device management and authentication in production networks. In production, centralizing AAA to ISE enforces consistent administrative access policies, provides accounting/audit trails, and enables advanced features like Change-of-Authorization (CoA) and CoA-triggered policy changes.

Topology

(Reference the topology from Lesson 1. Only the new or relevant management IP for this lesson is shown below.)

ASCII topology (management plane)

[SW1]----------------[LAN]----------------[ISE-PSN]
Gi0/1                 192.168.102.0/24         mgmt0
Mgmt IP: 192.168.102.10                       192.168.102.105:1812 (RADIUS)

Note: The only ISE IP referenced in the source material is 192.168.102.105 with RADIUS on UDP 1812. We use that exact IP and port for all RADIUS/TACACS+ server entries.

Device Table

DeviceRoleManagement IP
SW1Network Device / Authenticator192.168.102.10
ISE-PSNISE Policy Service Node (RADIUS/TACACS)192.168.102.105

Quick Recap

  • Lesson 1 introduced the lab core topology and ISE deployment roles. This lesson focuses on onboarding network devices into ISE and configuring AAA on the network device so it can talk to the ISE PSN at 192.168.102.105:1812.
  • We assume SW1 is reachable to the ISE management IP over the management VLAN 192.168.102.0/24.

Key Concepts (theory + behavior)

  • Network Device (Authenticator): The device (switch, WLC, router) that receives authentication requests from endpoints or administrators and forwards them to the AAA server (ISE). In production, this central point enforces port-based access or admin access policies.
  • RADIUS vs TACACS+:
    • RADIUS is primarily for network access authentication (802.1X, VPN, network device accounting). RADIUS combines authentication and authorization in one flow and uses UDP (auth port 1812, accounting 1813).
    • TACACS+ separates authentication, authorization, and accounting (AAA) and uses TCP; it is the recommended protocol for device administration because it allows fine-grained command authorization and full accounting of commands.
  • Shared Secret: A symmetric key used between the network device and ISE to secure RADIUS/TACACS+ packets. This must match on both sides. Think of it as a password for the A/A channel: if it mismatches, requests are silently dropped or rejected.
  • Network Device Groups (NDGs): Logical grouping in ISE used to apply different policies, shared secrets, or command authorizations to sets of devices (for example, "Core-Switches", "Edge-Switches", "Wireless-Controllers"). NDGs map to easier policy assignment and scalable administration.
  • Packet flow when authenticating an admin or endpoint:
    • Admin connects to SW1 (SSH/console).
    • SW1 forwards authentication request to ISE (UDP 1812 for RADIUS or TCP for TACACS+).
    • ISE evaluates policies, returns Accept/Reject and optionally authorization attributes (VLAN, ACL, command authorization).
    • SW1 enforces result and optionally logs accounting to ISE (UDP 1813 for RADIUS accounting).

Analogy: Think of NDGs like folders on a file server: you place devices in the correct folder so that they inherit the right policies and access controls.

Step-by-step configuration

Step 1: Configure AAA and RADIUS/TACACS+ server entries on the network device (SW1)

What we are doing: Configure SW1 to use ISE as a RADIUS and TACACS+ server and set the shared secret. This allows SW1 to send authentication and accounting requests to ISE at 192.168.102.105:1812.

configure terminal
aaa new-model
! Configure RADIUS server
radius server ISE-RADIUS
 address ipv4 192.168.102.105 auth-port 1812
 key Lab@123
exit
! Configure TACACS+ server
tacacs server ISE-TACACS
 address ipv4 192.168.102.105
 key Lab@123
exit
! Create AAA groups and default methods (example for privileged exec access)
aaa group server radius ISE-RAD-GROUP
 server name ISE-RADIUS
exit
aaa authentication login default group ISE-RAD-GROUP local
aaa authorization exec default group ISE-TAC-GROUP local
aaa group server tacacs+ ISE-TAC-GROUP
 server name ISE-TACACS
exit
end
write memory

What just happened:

  • aaa new-model enables the AAA framework on the device.
  • The radius server block creates a server object pointing at 192.168.102.105 and sets the auth port to 1812 with the shared secret Lab@123. This tells the switch where to send RADIUS authentication requests.
  • The tacacs server block creates a TACACS+ server object with the same shared secret.
  • aaa group server commands bundle servers into groups so authentication/authorization lists can reference a group rather than individual servers.
  • The aaa authentication login and aaa authorization exec lines configure the default authentication and exec authorization methods: try RADIUS (via the group) first, then local. Exec authorization references TACACS+ group to retrieve command authorization.
  • write memory saves the change to NVRAM.

Real-world note: Use the same shared secret on both the ISE network device entry and the switch. Use secure, complex secrets in production and rotate them periodically.

Verify:

show running-config | section radius
radius server ISE-RADIUS
 address ipv4 192.168.102.105 auth-port 1812
 key 7 031F1A0F081B
!
show running-config | section tacacs
tacacs server ISE-TACACS
 address ipv4 192.168.102.105
 key 7 031F1A0F081B
!
show aaa servers
Server group: ISE-RAD-GROUP
 Server: ISE-RADIUS (192.168.102.105) state: ACTIVE
Server group: ISE-TAC-GROUP
 Server: ISE-TACACS (192.168.102.105) state: ACTIVE
  • The show running-config | section radius and | section tacacs show the configured server blocks.
  • show aaa servers confirms the server groups and status. The key displayed will be encrypted in the config; expected output shows the server IP and active state.

Step 2: Add the network device into ISE and assign a shared secret and NDG (GUI steps)

What we are doing: Create a network device entry in ISE that represents SW1, assign it to an appropriate Network Device Group, and configure the same shared secret so ISE will accept authentication requests from SW1.

# NOTE: ISE configuration is performed via the GUI. The steps below are GUI actions, but verification is via network device show commands.
  • In ISE GUI: Administration > Network Resources > Network Devices > Add
    • Name: SW1
    • IP Address: 192.168.102.10
    • Device Type: Switch
    • Shared Secret: Lab@123
    • Network Device Group: Create/Assign (e.g., NHPREP/Edge-Switches)
    • Enable RADIUS Authentication and TACACS+ (select the protocols the device will use)

What just happened:

  • Creating a device entry in ISE registers SW1’s IP and associates the correct shared secret and NDG. When SW1 sends RADIUS/TACACS+ packets from its management IP, ISE will match that source IP to this object and validate the shared secret. The NDG determines which policies and authorization profiles ISE applies to SW1.

Real-world note: In production use a naming and NDG hierarchy that scales (e.g., Root -> Location -> Role -> Vendor). The slides indicate a maximum of six NDG levels; design for clarity and manageability.

Verify:

! On SW1: generate a test auth request (for example, an SSH login attempt) and observe debug or logs
terminal monitor
debug aaa authentication
! (Attempt SSH from your admin workstation to SW1)
! Expected debug excerpt:
RADIUS: Sending Access-Request id 23 to 192.168.102.105:1812
RADIUS: Vendor-Specific-Attr (Cisco) present
RADIUS: Received Access-Accept id 23 from 192.168.102.105:1812
  • The debug output demonstrates SW1 sent an Access-Request to the ISE at 192.168.102.105:1812 and received an Access-Accept. This proves both the shared secret matched and the ISE entry exists for SW1’s IP.

Step 3: Create and use Network Device Groups (NDGs) in ISE for policy scaling

What we are doing: Explain NDG creation and show how they are used in policies. NDGs let you apply different authentication/authorization behaviors to different device sets.

# NDG creation is performed in the ISE GUI:
# Administration > Network Resources > Network Device Groups
# Create a new NDG structure:
# Root: NHPREP
# Child: NHPREP/Edge-Switches
# Child: NHPREP/Core-Switches

What just happened:

  • The NDG hierarchy provides logical scoping for devices. When SW1 is assigned to NHPREP/Edge-Switches, you can target policies (for example, allow only certain TACACS+ command sets) to that NDG. In large deployments this prevents repetitive policy entries and centralizes device management.

Real-world note: Standardize NDG naming conventions (location, role, vendor) as recommended in the slides. Standardization reduces errors and makes policies predictable.

Verify:

! On ISE GUI: Navigate to Network Devices and view SW1 entry
! Expected GUI fields:
Name: SW1
IP Address: 192.168.102.10
Shared Secret: [configured]
Network Device Group: NHPREP/Edge-Switches
RADIUS: Enabled
TACACS+: Enabled
  • Confirming these fields in the GUI proves the device is properly onboarded and grouped.

Step 4: Configure accounting and CoA considerations on the network device

What we are doing: Enable RADIUS accounting and ensure the device can accept CoA (Change of Authorization) requests from ISE. Accounting provides session start/stop records; CoA lets ISE change session attributes dynamically.

configure terminal
! Enable RADIUS accounting to send start/stop messages to ISE
aaa accounting network default start-stop group ISE-RAD-GROUP
! Ensure the ISE server entry is present for accounting (server already configured in Step 1)
end
write memory

What just happened:

  • aaa accounting network default start-stop group tells the switch to send accounting start and stop messages to the RADIUS server group. ISE receives Session-Start and Session-Stop for visibility and logging. If CoA is needed, ensure ISE and the network device support CoA and IP connectivity from ISE to the device (and matching shared secrets). The reference notes RADIUS CoA (RFC 2865/2866/3579/5176) support and behavior.

Real-world note: In busy wireless or mobile environments accounting events are frequent; verify your ISE sizing (TPS/session expectations) to avoid overloads during peak events.

Verify:

show running-config | include accounting
aaa accounting network default start-stop group ISE-RAD-GROUP
! Check live accounting packets (debug)
debug radius packets
! Expected excerpt when a session starts:
RADIUS: Sending Accounting-Request id 12 to 192.168.102.105:1813
RADIUS: Received Accounting-Response id 12 from 192.168.102.105:1813
  • The debug output confirms accounting requests are sent to 192.168.102.105 (note accounting uses UDP 1813 per the reference).

Verification Checklist

  • Check 1: SW1 has RADIUS and TACACS+ server entries pointing to 192.168.102.105 with shared secret Lab@123 — verify with show running-config | section radius and show running-config | section tacacs.
  • Check 2: ISE contains a Network Device entry for SW1 with IP 192.168.102.10 and shared secret Lab@123 — verify in the ISE Network Devices GUI (Network Devices > SW1).
  • Check 3: Authentication attempt from an admin to SW1 results in RADIUS Access-Request and Access-Accept — verify with debug aaa authentication and the expected RADIUS debug messages.
  • Check 4: Accounting Start/Stop messages are sent to ISE — verify with debug radius packets showing Accounting-Request/Response on UDP 1813.

Common Mistakes

SymptomCauseFix
SW1 sends Access-Request but ISE does not respondShared secret mismatch or SW1 IP not present in ISE network devicesVerify shared secret is Lab@123 on both SW1 and ISE; ensure SW1 source IP matches the ISE network device entry
Authentication requests time out (no response)Network connectivity or incorrect port (RADIUS uses UDP 1812)Verify IP connectivity to 192.168.102.105; ensure firewall allows UDP 1812/1813 and TCP for TACACS+ if used
ISE receives requests but authorizations not applied as expectedDevice not assigned to correct NDG or policy mismatchCheck NDG assignment and policy conditions in ISE; standardize NDG naming to match policy logic
Excessive retries to multiple servers causing delaysToo many servers in method list or short dead timerLimit to three servers, increase dead timer as recommended by best practices to avoid cascading failures

Key Takeaways

  • Always configure and verify the same shared secret on both the network device and ISE; mismatch will silently fail authentication.
  • Use Network Device Groups (NDGs) to scale and simplify policy assignment across many devices — design NDG trees with consistency (location, role, vendor).
  • Enable accounting (RADIUS start/stop) for auditing and session visibility; plan ISE sizing for peak loads (wireless/roaming can spike load 100x).
  • Prefer TACACS+ for device administration (fine-grained command authorization) and RADIUS for network access; both can coexist and are managed by ISE.

Tip: Standardize IOS versions, AAA syntax, and NDG naming across the estate. As the slides emphasize: Standardize! Standardize!! Standardize!!! This reduces corner cases and speeds troubleshooting.

If you complete these steps, your network device will be correctly onboarded into ISE, using 192.168.102.105:1812 for RADIUS and TACACS+ with the shared secret Lab@123, and placed into a scalable NDG structure for targeted policy application.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security