Comparative Architectures of Centralised and Local Web Authentication

 The choice between Local Web Authentication (LWA) and Centralized Web Authentication (CWA) depends on your need for dynamic policy enforcement and advanced endpoint services.

Centralized Web Authentication (CWA)

CWA is the standard for modern ISE deployments because the logic and portals are managed centrally on ISE rather than on individual switches or controllers.

• Pros: Supports Change of Authorization (CoA), allowing ISE to dynamically update a user's access (like moving from a guest portal to full access) without a new login. it also supports advanced services like posture assessment, device registration, and BYOD onboarding.

• Cons: Requires the network access device (NAD) to support specific URL-redirection and CoA capabilities.

Local Web Authentication (LWA)

LWA is the "original" WebAuth method where the login page is hosted directly on the network hardware.

• Pros: Can be used with legacy or non-Cisco devices that do not support CWA or URL redirection.

• Cons: No CoA support, meaning access levels cannot change dynamically based on profiling or posture. it offers very limited customization for web pages and lacks support for automated services like client provisioning or password resets.

Most organizations choose CWA because it provides a unified guest experience across both wired and wireless networks.

Sponsor Portal Capabilities and Management Permissions

 Based on the provided documentation, here are the three valid capabilities that can be granted to a sponsor group:

• Sponsors can create new random accounts: The sponsor portal allows for the quick generation of multiple guest accounts at once using the "Create Random Accounts" feature.

• Any sponsor can manage accounts created by any other member of the sponsor group: The built-in GROUP\_ACCOUNTS sponsor group specifically enables members to view and manage guest accounts created by any other sponsor within that same group.

• Sponsors can suspend guest accounts: Sponsors have the authority to suspend guest accounts, which temporarily prevents access and issues a Change of Authorization (CoA) Terminate to remove the user from the network.

Why the other options are incorrect:

• ISE GUI access: Sponsors use a dedicated Sponsor Portal, not the ISE Admin GUI, which is reserved for system administrators.

• Setting specific passwords: While sponsors can reset passwords, ISE typically generates a random password rather than allowing the sponsor to define a specific one

• AD Group Management: Sponsors manage accounts within the ISE guest database, not external identity sources like Active Directory

Capabilities and Roles of Cisco ISE as a Certificate Authority

 Based on the provided sources, the three correct statements describing Cisco ISE as a CA are:

• Cisco ISE can issue endpoint certificates: ISE provides a lightweight PKI that can directly provision digital certificates to BYOD endpoints and other network devices.

• Cisco ISE can perform OCSP checks: The ISE CA can function as an Online Certificate Status Protocol (OCSP) responder to determine and check the revocation status of certificates it has issued.

• Cisco ISE can be configured as a subordinate CA of a corporate or external CA: ISE can work seamlessly with an existing enterprise PKI by acting as an intermediate or subordinate CA, allowing it to issue certificates signed by that external authority.

ISE Deployment: High-Impact Profiling Probes and Best Practices

 The three probes that should be avoided due to the excessive overhead and resource consumption they cause are:

• NetFlow: Enabling this probe can quickly oversubscribe or overwhelm a Policy Service Node (PSN) with millions of records. It is generally not recommended for broad profiling

• HTTP Span: This probe is computationally expensive and can consume a large amount of system resources on the PSN because it requires the interface to parse a multitude of potentially irrelevant traffic.

• DHCP SPAN: While functional, it is not considered a best practice because it is more resource-intensive than direct methods like DHCP - IP Helper. It is rated as having a high network impact 8.

By contrast, the RADIUS probe, Device Sensor, and DHCP - IP Helper are the preferred, more efficient methods for data collection.

Cisco ISE Endpoint Profiling and Change of Authorization Methods

 The three globally available Change of Authorization (CoA) options for endpoint profiling are:

• No CoA: This is the default setting used to disable global CoA for profiling.

• Port Bounce: This option temporarily shuts down the switch port and then re-enables it, which is particularly useful for forcing "headless" devices to request a new IP address via DHCP after a VLAN change.

• ReAuth: This option instructs the network access device to initiate a new authentication while maintaining the same session ID, allowing ISE to update the authorization result based on new profiling data.

Cisco ISE Session Propagation and pxGrid Data Flows

 Cisco ISE publishes session data to pxGrid through a coordinated flow between its primary personas:

• Data Collection: Policy Service Nodes (PSNs) handle active authentications and forward all session events and RADIUS accounting packets to the Monitoring and Troubleshooting (MnT) node via syslog (UDP/20514).

• Centralized Directory: The MnT node acts as the central repository, consolidating these logs into a global session directory.

• Publishing: The MnT node functions as a publisher, sending session topic data to the pxGrid controller.

• Brokering Context: The pxGrid controller manages the publish/subscribe (pub/sub) bus, allowing authorized subscribers (such as a SIEM, Firepower, or Stealthwatch) to receive real-time notifications or perform bulk downloads of this session context.

In modern deployments (pxGrid 2.0), this information is typically exchanged using WebSocket and REST-based APIs for greater efficiency.

The Mechanics of Cisco ISE Policy Synchronization

 During an active authentication, PSNs operate autonomously and typically do not need to interact with the PAN to make a decision.

The interaction is structured as follows:

• Policy Synchronization (Pre-Authentication): The PAN acts as the central control centre, maintaining the master database of security policies. It replicates this entire database to all PSNs in the "ISE cube," ensuring they have the local information required to handle requests independently.

• Autonomous Evaluation: When a Network Access Device (NAD) sends a RADIUS request, the PSN processes it using its local copy of the policy. It does not query the PAN for "permission" during the authentication flow.

• Data Updates (Post-Authentication): If a PSN learns new data about an endpoint during the session—such as profiling attributes or guest user information—it synchronizes that information back to the Primary PAN. The PAN then pushes that update to all other nodes in the deployment to ensure consistency across the network.

Because of this design, authentications can continue even if the PAN is offline, though you wouldn't be able to modify any policies until the PAN is restored or a secondary is promoted.