Arista Guardian for Network

Identity User Guide

Arista Networks
www.arista.com
Headquarters Support Sales
5453 Great America Parkway +1 408 547-5502 +1 408 547-5501
Santa Clara, CA 95054 +1 866 476-0000 +1 866 497-0000
USA [email protected] [email protected]
+1 408 547-5500
www.arista.com

© Copyright 2023 Arista Networks, Inc. All rights reserved. The information contained
herein is subject to change without notice. The trademarks, logos and service marks
("Marks") displayed in this documentation are the property of Arista Networks in the
United States and other countries. Use of the Marks are subject to Arista Network’s Term of
Use Policy, available at www.arista.com/en/terms-of-use. Use of marks belonging to other
parties is for informational purposes only.
Introduction 6
Accessing the UI 6
License 7
UI Theme 8
Third-Party Integrations 8
CV-CUE Integration 9
Procedure 9
CloudVision Integration 11
Purpose 11
Prerequisites 11
Procedure 11
MSS-G Integration 12
Purpose 12
Prerequisites 12
Procedure 12
External Integrations 14
Palo Alto Cortex XDR Integration 14
Purpose 14
Prerequisites 14
Procedure 14
Medigate Integration 15
Purpose 15
Prerequisites 15
Procedure 15
Microsoft Intune Integration 16
Purpose 16
Prerequisites 16
Procedure 17
Jamf Integration 18
Purpose 18
Prerequisites 18
Procedure 18
Splunk Integration 19
Purpose 19
Prerequisites 19
Procedure 19
Sumo Logic Integration 20
Purpose 20
Prerequisites 20
 Procedure 20
Configurations 21
Device Configuration 21
Devices 21
Add Access Device 21
Client Certificate 22
Device Groups 24
Certificates 25
Trusted Certificates 25
Identity Provider Configuration 26
Microsoft 365 (Azure) 27
Authentication 27
Authorization 27
OneLogin 30
Authentication 30
Authorization 30
Okta 31
Authentication 31
Authorization 31
Google Workspace 33
Authentication 33
Local 34
Network 35
802.1X 35
Prerequisites 35
Configuration 36
UPSK 38
Prerequisites 38
Configuration 38
Wireless Captive Portal 40
Prerequisites 40
Configuration 40
Wireless MAC Authentication 43
Prerequisites 43
Configuration 43
Wired 802.1X 44
Prerequisites 44
Configuration 44
Wired MAC Authentication 48
Prerequisites 48
Configuration 49
 Wired Captive Portal 51
Prerequisites 51
Configuration 51
Segments 52
Status 52
Enable 52
Disable 53
Monitor 53
Conditions 53
Actions 53
Configuration 53
Sample Segments 53
Sample Employee Access Segment 54
Sample Contractor Access Segment 55
Sample BYOD Access Segment 56
Sample IOT Access Segment 57
User Configurations 57
Users 57
External Users 57
Local User 58
User Groups 59
Local User Groups 60
Client Configuration 60
Client Groups 60
Group UPSK 60
Allowed Networks 61
Delegated Management 61
Clients 62
Client Details 63
System 65
Audit Viewer 65
License 65
Portal Settings 66
RadSec Settings 66
Support Logs 67
System Events 67
Troubleshooting 68
Monitoring 68
Dashboards 68
Sessions 69
Appendix 72
OIDC Vs SAML 72
Identity Providers 72
Microsoft Azure Active Directory 72
Google Workspace 73
OneLogin 74
Okta 74
Introduction
This document captures the details of the Arista Guardian for Network Identity (AGNI) user
guide. This document provides a detailed understanding of various configuration options
present in AGNI. The URLs, credential information, and user objects mentioned in this
document are for illustrations only.

Accessing the UI
AGNI has SSO integrations with Arista Wi-Fi Launchpad for login and logout functionality. AGNI
will be accessed using Arista Wi-Fi Launchpad. The user management and other access control
mechanisms will be done by Arista Wi-Fi Launchpad. Admin can log in to Arista Wi-Fi
Launchpad and navigate to the AGNI tile on the dashboard.

Figure 1: Accessing AGNI via Arista Launchpad

On clicking on the AGNI tile, the user is redirected to the AGNI dashboard. The Admin Console
provides administration, configuration, monitoring and troubleshooting of AGNI.

Figure 2: AGNI Dashboard

License
AGNI Network administrator can view the license information by accessing Configuration→
System → License

Figure 3: AGNI License

UI Theme
AGNI UI offers different themes and modes. Admin can use a dark theme or light theme as per
one's preferences. The system theme will get applied on AGNI UI by default. Admin can also
change the option placement in UI i.e. option bar can be on the top, bottom or at left. Admin can
change the UI from the top right side panel.

Figure 4: UI Theme Settings

Third-Party Integrations
AGNI natively integrates with Arista and various third-party applications. The integrations are
facilitated by configuring the Concourse Application.

Figure 5. Concourse Applications

 Figure 6. Concourse Applications

CV-CUE Integration
○ CV-CUE integration is achieved by installing the application as a Concourse App.
Follow the steps to install the application

Procedure
● Navigate to Concourse → Explore
● Install the ‘Arista CV-CUE’ application.
 Figure 7: Installing Arista CV-CUE Concourse Application

● Provide Arista CV-CUE parameters

○ CV-CUE Key ID
○ CV-CUE Key Value
● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● Initiate the synchronization by clicking on the Sync button on the plugin found in the
Installed Apps section.
● The synchronized WiFi details can be found in Configuration → Access Devices →
Devices.
CloudVision Integration
CloudVision integration is achieved through installing the CloudVision concourse application.

Purpose
Enabling CloudVision integration facilitates AGNI pulling the details of the managed wired
switches. The details are synchronized with AGNI and the information such as MAC address
and network device name are available as first class entities within AGNI to configure
segmentation policies.

Prerequisites
The integration requires an API token with necessary permissions to pull the managed switch
details. The token is obtained through CloudVision interface.

Procedure
● Navigate to Concourse → Explore
● Install ‘Arista CloudVision’ application.

Figure 8: Installing Arista CloudVision Concourse Application

● Provide API Token value

● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● Initiate the synchronization by clicking on the Sync button on the plugin found in the
Installed Apps section.
 ● The synchronized switch details can be found in Configuration → Access Devices →
Devices.

MSS-G Integration
MSS-G integration is achieved through installing the Arista MSS-G concourse application. The
integration allows MSS-G enforcement through AGNI based on the segmentation conditions for
an incoming access request.

Purpose
Enabling MSS-G integration facilitates AGNI pulling the segment details from CloudVision in
context with MSS-G enforcement. The details are synchronized with AGNI and the MSS-G
segments are available as first class entities within AGNI to configure segmentation policies.

Prerequisites
The integration requires an API token with the necessary permissions to pull the MSS-G
segment details. The token is obtained through the CloudVision interface.

Procedure
● Navigate to Concourse → Explore
● Install ‘Arista MSS-G’ application.
 Figure 9: Installing Arista MSS-G Concourse Application

● Provide API Token value

● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● Initiate the synchronization by clicking on the Sync button on the plugin found in the
Installed Apps section.
● The synchronized MSS-G segments can be viewed in this concourse application section.
External Integrations

Palo Alto Cortex XDR Integration

Palo Alto Cortex XDR is an Endpoint Protection concourse application. Integration is achieved
through installing this concourse application.

Purpose
Enabling Cortex XDR integration facilitates AGNI pulling the posture details from client devices
that are managed by this external application. The posture details are associated with the
clients and can be used in the segmentation conditions.

Prerequisites
The integration requires an API key with necessary permissions to pull the managed client
device posture details. Refer to vendor documentation to configure and obtain the API key.

Procedure
● Navigate to Concourse → Explore
● Install ‘Cortex XDR’ application.

Figure 10: Installing Palo Alto Cortex XDR Concourse Application

● Input the following

○ API URL - Palo Alto Cortex XDR server URL
○ API ID - Static identifier for the API access
○ API Key - API key configured in Cortex XDR for this integration
● Click on the Verify button to validate and Install button to complete the installation.
 ● The plugin is visible in the Concourse → Installed Apps.
● This integration is used to retrieve the posture of clients that are managed by Cortex
XDR and enforced as a part of segment conditions.

Medigate Integration
Medigate is an Endpoint Protection concourse application. Integration is achieved through
installing this concourse application.

Purpose
Enabling Medigate integration facilitates AGNI fetching device profile details of the clients
connecting to the network. Medigate profiles medical, IoT, IoMT, and several other devices that
are connecting to the network. The profiled details are directly available to be used in the
segmentation conditions.

Prerequisites
The integration requires an API token with necessary permissions to pull the profiled client
information. Refer to vendor documentation to configure and obtain the API token.

Procedure
● Navigate to Concourse → Explore
● Install ‘Medigate’ application.
 Figure 11: Installing Medigate Concourse Application

● Input API Token.

● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● This integration will enable synchronization of client device profile details into AGNI.

Microsoft Intune Integration

Microsoft Intune is a Device Management concourse application. Integration is achieved
through installing this concourse application to facilitate integration of MDM solutions with AGNI.

Purpose
Enabling Microsoft Intune integration enables the following capabilities:
● Ability to provision EAP-TLS client certificates via SCEP to the set of managed devices
through AGNI’s native PKI.
● Fetch client attributes and compliance status from the MDM provider. These attributes
are available to be used in segmentation conditions.

Prerequisites
The integration requires API credentials with necessary permissions to pull the client attributes
and compliance information. Refer to vendor documentation to configure and obtain the API
credentials.
Procedure
● Navigate to Concourse → Explore
● Install ‘Microsoft Intune’ application.

Figure 12: Installing Microsoft Intune Concourse Application

● Input the following:

○ Directory (tenant) ID
○ Application (client) ID
○ Client Secret
● Copy the generated SCEP URL and input in Intune for the creation of SCEP profile
● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● This integration will enable pushing enrollment of client certificates and synchronization
of client attributes and compliance details into AGNI.
Jamf Integration
Jamf is a Device Management concourse application. Integration is achieved through installing
this concourse application to facilitate integration of MDM solutions with AGNI.

Purpose
Jamf integration enables the provisioning of EAP-TLS client certificates via SCEP to the set of
managed devices through the AGNI’s native PKI.

Prerequisites
The integration requires SCEP challenge and URL generated in AGNI to be configured in the
Jamf administration portal. Refer to vendor documentation on the specific details to configure
these parameters.

Procedure
● Navigate to Concourse → Explore
● Install ‘Jamf’ application.

Figure 13: Installing Jamf Concourse Application

● Click on Install button to complete the installation.

● Enable Client Certificate Enrollment
 ● Copy the generated SCEP challenge and SCEP server URL and input in Jamf
administration portal for the creation of SCEP profile
● The plugin is visible in the Concourse → Installed Apps.
● This integration will enable enrollment of client certificates through AGNI’s PKI.

Splunk Integration
Splunk is a SIEM concourse application. Integration is achieved through installing this
concourse application to facilitate session log updates from AGNI.

Purpose
Enabling Splunk integration facilitates the session log updates for the users authenticating in the
network through AGNI. The update carries the user-id, ip address, client device and session
details of the incoming authentication requests.

Prerequisites
The integration requires Splunk SIEM credentials to be configured as a part of the concourse
application configuration. Refer to vendor documentation on the specific details to configure
these parameters.

Procedure
● Navigate to Concourse → Explore
● Install ‘Splunk’ application.

Figure 14: Installing Splunk Concourse Application

 ● Input the following:
○ Hostname
○ Port
○ Token
● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● This integration will enable pushing session details to Splunk as and when the users
authenticate.

Sumo Logic Integration

Sumo Logic is a SIEM concourse application. Integration is achieved through installing this
concourse application to facilitate session log updates from AGNI.

Purpose
Enabling Sumo Logic integration facilitates the session log updates for the users authenticating
in the network through AGNI. The update carries the user-id, ip address, client device and
session details of the incoming authentication requests.

Prerequisites
The integration requires Sumo Logic SIEM URL to be configured as a part of the concourse
application configuration. Refer to vendor documentation on the specific details to obtain this
parameter.

Procedure
● Navigate to Concourse → Explore
● Install Sumo Logic application.
 Figure 15: Installing Sumo Logic Concourse Application
● Input Sumo Logic server URL
● Click on the Verify button to validate and Install button to complete the installation.
● The plugin is visible in the Concourse → Installed Apps.
● This integration will enable pushing session details to Sumo Logic as and when the
users authenticate

Configurations
This section covers the configuration aspects of the following entities:
● Device Configurations
● Certificate Configurations
● Identity Provider configuration
● Network Configurations
● Segment Configurations
● User Configurations
● Client Configurations

The section below illustrates the detailed configuration steps for the different configuration
options mentioned above.

Device Configuration

Devices
Network Access Devices represent the NADs connecting to AGNI via RadSec and are added in
the Configuration –> Access Devices → Devices section. These can be added into the
system via
● Manual addition by specifying the access device details
● Importing via APIs
● If the devices are managed by Arista CloudVision then they can be automatically
imported into the system by installing Arista CloudVision or Arista CV-CUE concourse
application.The section about the Third-party Integrations describe these concourse
plugin installation for further reference.

Add Access Device

This option provides manual addition of network access devices into the system. AGNI is a
multi-vendor solution that supports working with several third-party vendors that support
RadSec protocol. List network vendors include
● Arista WiFi
● Arista Switch
 ● Aruba
● Cisco
● Generic

The Generic option can be used to add any other vendor that supports RadSec and complies to
the protocol.

Figure 16: Device Addition

Client Certificate
AGNI establishes RadSec connection with the network devices. In majority of the cases, the
TPM certificate of the network devices can be used to establish the RadSec connection. In
cases where this is not possible then AGNI offers the ability to generate a self-signed certificate
for the access devices that can be used to establish a RadSec tunnel. Customers can also
procure network access device certificates externally and use it for the RadSec communication.

The procedure to generate client certificate for network access devices is described below:

● The certificate generation process involves generating the device certificate and its
private key. On clicking the “Generate” option, the system generates a p12 file
containing a self-signed certificate and private key for the network access device. The
output is encrypted through the password as provided by the administrator.
 Figure 17: RadSec client certificate generation

● The client certificate generation for the network access devices can also be
accomplished by uploading the Certificate Signing Request (CSR). In this case, the CSR
is generated on the network access device (refer to vendor specific documentation) and
the output is provided in the interface. The system signs the CSR and generates the
certificate that can be uploaded in the network access device.

Note: While generating the CSR ensure to provide

○ the device MAC address as Common Name
○ DNS as domain name

Figure 18: RadSec client certificate via CSR

○ The CSR can either be uploaded or pasted in the UI.

 ● For Arista WiFi devices, there is an option to generate bulk CSRs from Arista CV-CUE
interface. Bulk CSRs can be uploaded as a zip file to generate the client certificates.

The RadSec status is conveyed in the administration. The connection details can be explored
by inspecting the device logs on per access device.

Figure 19: Device details

Device Groups
Device Groups can be set up with one or more network devices for the ease of management
and policy administration. The Device Groups are available in the Segment conditions to
enforce policies for network access.
 Figure 20: Device Groups

Certificates
The native PKI built into the product enables the life cycle management of client certificates
issued through its services.

Trusted Certificates
The Trusted Certificates section displays the Root and Issuer CAs of builtin PKI. The certificate
can be downloaded by navigating to Configuration → Certificates → Trusted.

Various settings for AGNI certificates can be viewed by navigating to Configuration →

Certificates → Trusted and clicking on Settings.
 Figure 21: Trusted Certificates

External certificates can be imported into the product by clicking on the “Add Certificate”
option. Importing external root, intermediate, issuer certificate chain enables the system to work
with external PKIs.

For external PKIs, the system supports certificate revocation checks either through querying the
URL or statically checking against the revocation list.

Identity Provider Configuration

AGNI interacts with IDPs via OIDC and OAuth2.0 protocols. The list of supported IDPs includes:
● Microsoft 365 (Azure)
● Google Workspace
● OneLogin
● Okta
● Local

AGNI’s integration with IDPs is required to perform

● Authentication -
○ User onboarding workflows to onboard the client devices via UPSK, EAP-TLS,
Captive Portal
○ Admin login to the user interface
○ Admin login to the UPSK client portal
○ User login to the UPSK client portal
● Authorization - To gather user authorization attributes (eg: groups, account status, user
attributes) from the identity providers. Note that authorization is optional and identity
provider configuration for authorization is only required if there are network access
policies that provide access to the users based on the user authorization attributes.
Microsoft 365 (Azure)

Authentication
AGNI uses its application endpoint registered with Microsoft Azure AD that handles all the
authentication requirements. No other configuration is required to perform authentication.

Authorization
If you are not performing authorization of the users (or using any of the identity provider
attributes in network policies), you can skip this step.

Otherwise perform the following:

● Navigate to Identity → Identity Provider
● Edit Identity Provider (or Add a new identity provider)
● Enable Identity information Synchronization
● Provide the identity provider details (Refer to Appendix section on how to configure the
details in Microsoft Azure AD)
○ Directory (tenant) ID
○ Application (client) ID
○ Client Secret
● Click on Verify. Once the operation is successful, the system will pull the list of groups
from the identity provider and that can be used in the policies.
 Figure 22:Add Identity Provider

● Select the groups from the Available Groups. The selected groups will be visible in the
Synchronized Groups tab and ready to be used in the network access policies.

Figure 23: Identity Provider Available Groups

Figure 24: Identity Provider add Synchronize Groups

● Click on Add to save the changes.

● Sync Interval - This parameter dictates when the system has to synchronize user
attributes from the IDP. To perform on demand synchronization click on the ‘Sync now’
button. Else the system will synchronize once every Sync Interval duration specified.
● User Attributes - These are additional attributes that can be added into the IDP. The
synchronization operation fetches the additional attributes specified and can be used in
the segmentation policies.

Figure 25: Identity Provider and User Attributes

● Preview - Users and user attributes can be previewed in the preview section. This
enables the ability to visualize user attributes from the IDP and use them in the
segmentation policies.

Figure 26: Identity Provider and User Preview

OneLogin

Authentication
AGNI uses OIDC protocol to authenticate the users into the IDP. Setup OneLogin with an OIDC
application and note down the Client ID and Issuer URL.

Authorization
Authorization is performed through setting up API access under the Developers section in
OneLogin administration. Create new API credentials in OneLogin for AGNI that has
permission to read at least - user fields, roles and groups. Once set up, note down the Client ID
and Client Secret.

Enter these values in AGNI by adding a new Identity Provider for OneLogin.

● Navigate to Identity → Identity Provider

● Edit Identity Provider (or Add a new identity provider)
● Provide the details for
○ Name - Name of the identity provider
○ Domain Name - Domain name of the organization
● Provide details for - Identity Information. The details are used for authentication and can
be found as described in the authentication section above.
○ OIDC Issuer URL
○ OIDC Client ID

Figure 27: OneLogin add Identity Provider

● Enable Identity information Synchronization

 ● Provide the Identity Information Synchronization details (Refer to Appendix section on
how to configure the details in OneLogin or its vendor documentation)
○ API Client ID
○ API Client Secret
● Click on Verify. Once the operation is successful, you can add the group information as
it appears in OneLogin and use them in the authorization policies.
● Click on Add or Update section to save the identity provider configuration.
● Sync Interval, User Attributes and Preview functions are similar to the previous IDP
details mentioned.

Figure 28: OneLogin Identity Provider Synchronization

Okta

Authentication
AGNI uses OIDC protocol to authenticate the users into the IDP. Setup Okta with an OIDC
application and note down the Client ID and Issuer URL.

Authorization
Authorization is performed through setting up API access under the Security section in Okta
administration. Create new API Token in Okta for AGNI.

Enter these values in AGNI by adding a new Identity Provider for Okta.

● Navigate to Identity → Identity Provider

● Edit Identity Provider (or Add a new identity provider)
● Provide the details for
○ Name - Name of the identity provider
○ Domain Name - Domain name of the organization
● Provide details for - Identity Information. The details are used for authentication and can
be found as described in the authentication section above.
○ OIDC Domain
○ Application (client) Client ID

Figure 29: Okta Identity Provider Configuration

● Enable Identity information Synchronization

● Provide the Identity Information Synchronization details (Refer to the Appendix section
on how to configure the details in Okta or its vendor documentation)
○ API Key
● Click on Verify. Once the operation is successful, you can add the group information as
it appears in Okta and use them in the authorization policies.
● Click on Add or Update section to save the identity provider configuration.
● Sync Interval, User Attributes and Preview functions are similar to the previous IDP
details mentioned.
 Figure 30: Okta Identity Provider Synchronization

Google Workspace

Authentication
AGNI uses OAuth protocol to authenticate the users into the IDP. Authorization is performed by
setting up API access under the Security section in Google Workspace administration. Create
new API JSON in Google Workspace for AGNI.

Enter these values in AGNI by adding a new Identity Provider for Google Workspace.

● Navigate to Identity → Identity Provider

● Edit Identity Provider (or Add a new identity provider)
● Provide the details for
○ Name - Name of the identity provider
○ Domain Name - Domain name of the organization
● Provide details for - Identity Information.
● Enable Identity information Synchronization
● Provide the Identity Information Synchronization details
○ Customer ID
○ Account Email
○ Upload Service Account credentials
● Click on Verify. Once the operation is successful, you can add the group information as
it appears in Google Workspace and use them in the authorization policies.
 ● Click on Add or Update section to save the identity provider configuration.
● Sync Interval, User Attributes and Preview functions are similar to the previous IDP
details mentioned.

Figure 31: Google Workspace

Local
AGNI supports the local identity provider. This enables the addition of local users into the
system and to validate the product feature set. The local identity provider is enabled by default.
 Figure 32: Local IDP Configurations

Network
Networks represent the entry point for the network access control. They also represent different
ways the client can connect in your environment. Various Network options are available based
on the authentication needs.

802.1X
802.1X Networks can be set up to provide AAA access to the clients with the highest level of
security via EAP-TLS. AGNI supports EAP-TLS authentications from the clients using its native
PKI or through the external PKI.

Prerequisites
● Wireless SSID is configured on the APs to perform 802.1X authentication
● Clients are onboarded with credentials and configured to perform 802.1X authentication
either via native PKI or external PKI
● In case of external PKIs, the PKI root and issuer certificates are imported into AGNI
Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wireless
● Provide the SSID name. Make sure the name matches with the SSID configured in
wireless APs
● Status
○ Enabled - Enables this network to honor incoming requests
○ Disabled - Disables this network
● Authentication
○ Type of authentication should be set to Client Certificate. This enables the
system to honor EAP-TLS authentication requests.
● Domain Machine Authentication
○ Enable this setting to process the domain machine authentication (via EAP-TLS)
requests.
● Trusted External Certificates
○ If external PKI is being used and if you require AGNI to honor the external
certificates, enable the setting with an option to check against CRL and OCSP
URLs for certificate revocations.
○ The setting assumes external PKI root and issuer certificates are imported into
AGNI
○ User Identity Binding
■ Required - If set, then the certificate should have a valid queryable user
identity for request authorizations.
■ Optional - If set, then the certificate can contain any identity that is
optionally bound or not bound to the user. For example, this option can be
set to honor appliance authentication where the certificates are not bound
to any user rather set to machine identity.
 Figure 33: Wireless EAP-TLS Network
● Onboarding
○ Enable this setting when using AGNI PKI
○ Allow Local User Self Registration
■ Disabled - Disallows local users to self register into the system as a part
of the user onboarding process.
● Authorized User Group - This setting is optional. Choose the
names of the User Groups, if you need to allow onboarding to be
permitted for the users belonging to these groups. When this
setting is not provided the system honors onboarding requests
from all the users of the organization.
■ Enabled - Users can self register into the system as a part of the user
onboarding process.
○ Click on Add Network. The operation will
■ Create the network
■ Create an Onboarding URL which should be set as a captive portal URL
in the WiFi configuration of your AP. Clients will be redirected to this URL
for onboarding
 Figure 34: Wireless EAP-TLS Network User Onboarding

UPSK
UPSK provides secure access to the network based on the unique PSK generated by the
system. UPSKs are governed by the security principles that ensure the passphrases are unique
and secure. UPSKs can be generated by the end user through the user onboarding workflow or
administrators through the administration workflows. They can be generated on a per-device
basis or per group of devices as per the requirements of the network.

Prerequisites
● Wireless SSID is configured on the APs to perform UPSK authentication
● Onboarding roles are configured on the APs
● Onboarding PSK passphrase is configured on the SSID.
● Walled garden domain names are configured to allow access to the required domains
(more details under ‘Show Domains’ section below).

Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wireless
● Provide the SSID name. Make sure the name matches with the SSID configured in
wireless APs
● Status
○ Enabled - Enables this network to honor incoming requests
○ Disabled - Disables this network
● Authentication
○ Type of authentication should be set to Unique PSK (UPSK). This enables the
system to honor UPSK authentication requests.
● User Private Networks
○ Enable this setting when interacting with Arista APs. This setting enables sending
Arista VSAs for UPSK transactions.
○ Shared Clients Optional. Enable the setting and choose the list of clients this
connection can share from the configuration. This is specific to Arista APs.
 Figure 35: Wireless UPSK Network

● Onboarding - Enables the end user to self-register the devices.

○ Initial Passphrase for Onboarding - Specify the initial passphrase that should
be used by the clients to connect to the UPSK network. Note that this passphrase
should match that configured on the SSID of your APs.
○ Initial Role for Onboarding - Specify the initial role to be associated with when
the clients connect to the UPSK network. Note that this role should be configured
in the APs.
○ Show Domains - Shows the list of walled garden domain names that need to be
allow-listed in your network infrastructure (wired or wireless) to allow the
onboarding process. Without this the user authentication may be blocked by the
network infrastructure.
○ Allow Local User Self Registration
■ Disabled - Disallows local users to self-register into the system as a part
of the user onboarding process.
● Authorized User Group - This setting is optional. Choose the
names of the User Groups, if you need to allow onboarding to be
permitted for the users belonging to these groups. When this
setting is not provided the system honors onboarding requests
from all the users of the organization.
 ■ Enabled - Users can self-register into the system as a part of the user
onboarding process.

Figure 36: Wireless UPSK Network User Onboarding

● Click on Add Network. The operation will
○ Create the network
○ Create an Onboarding URL which should be set as a captive portal URL in the
WiFi configuration of your AP. Clients will be redirected to this URL for
onboarding
○ Create a QR code that can be used to connect to the SSID and get redirected to
the onboarding page as well.

Wireless Captive Portal

Captive Portal provides network access based on the authentication mechanism through the
web browsers. The credentials are either validated locally (in case of local users) or via SSO (in
case of external IDP integration).

Prerequisites
● Wireless SSID is configured on the APs to perform Captive Portal authentication
● Onboarding roles are configured on the APs
● Onboarding PSK passphrase is configured on the SSID.
● Walled garden domain names are configured to allow access to the required domains
(more details under ‘Show Domains’ section below).
● When using Captive Portal for guest users, ensure the guest portals are configured in
Arista Guest Manager application and CV-CUE concourse application credentials have
permissions to load the guest portals.

Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wireless
● Provide the SSID name. Make sure the name matches with the SSID configured in
wireless APs
● Status
○ Enabled - Enables this network to honor incoming requests
○ Disabled - Disables this network
● Authentication Type
○ Type of authentication should be set to Captive Portal. This enables the system
to honor browser based authentication requests.
● User Type
○ Organizational user - When set, the system uses configured IDP and
authenticates the users externally via SSO
○ Guest user - When set, the guest portals are loaded from the Arista Guest
Manager application. Select the desired guest portal.
● Captive Portal
○ Initial Role for Portal Authentication - Specify the initial role as configured in
the AP required for portal authentication. Note that the client will remain in this
role until the user is successfully authenticated.
○ Show Domains - Shows the list of walled garden domain names that needs to
be allow-listed in your network infrastructure (wired or wireless) to allow the
onboarding process. Without this the user authentication may be blocked by the
network infrastructure.
○ Re-authenticate Clients
Note: This setting is applicable when the user type is set to ‘Guest user’.
■ Periodic - When set, the clients are re-authenticated once in every
‘Re-authentication Period (days)’ as configured.
● Re-authentication Period (days) - Specifies the frequency of
re-authentication in days.
■ Always - When set, the clients are re-authenticated every time when
connected to the captive portal network.
○ Authorized User Group - This setting is optional and applicable when the User
Type set to ‘Organizational user’. Choose the names of the User Groups, if you
need to allow onboarding to be permitted for the users belonging to these groups.
When this setting is not provided the system honors onboarding requests from all
the users of the organization.
○ Re-authenticate Registered Clients
Note: This setting is applicable when the user type is set to Organizational user’.
■ Periodic - When set, the clients are re-authenticated once in every
‘Re-authentication Period (days)’ as configured.
● Re-authentication Period (days) - Specifies the frequency of
re-authentication in days.
■ Always - When set, the clients are re-authenticated every time when
connected to the captive portal network.
 ■ Not Required - When set, the user is permitted always into the network
after the first captive portal authentication.

Figure 37: Wireless Captive Portal Network

Figure 38: Wireless Captive Portal Network

● Click on Add Network. The operation will

○ Create the network
○ Create an Onboarding URL which should be set as a captive portal URL in the
WiFi configuration of your AP. Clients will be redirected to this URL for
onboarding
 Figure 39: Wireless Captive Portal Network Onboarding

Wireless MAC Authentication

Wireless network configuration provides means to authenticate end clients connected to the
network via client MAC addresses. This enables clients to associate to the network based on
various factors surrounding MAC addresses such as registered, allow all clients or vendor
specific client entities.

Prerequisites
● Wireless SSID is configured on the AP to perform MAC Bypass Authentication
● Roles/VLANs used in the segmentation policies are configured on the AP.

Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wireless
● Provide the SSID name. Make sure the name matches with the SSID configured in
wireless APs
● Status
○ Enabled - Enables this network to honor incoming requests
○ Disabled - Disables this network
● Authentication
○ Set the authentication type as MAC Authentication to honor MAC-Based
Authentication (MBA) requests
● MAC Authentication Settings
○ Allow All Clients - Allows MAC authentication to succeed for all the clients
irrespective of registration status.
■ Add New Clients to Group - Specify the client group to persist the newly
authenticated MAC addresses.
○ Allow Registered Clients Only - Allows MAC authentication to succeed for the
clients that are registered in AGNI.
■ Disallow user-associated clients - If the option is enabled, then MAC
authentication is rejected for the previously onboarded clients.
○ Allow Authorized OUIs Only - Allows MAC authentication to succeed for the
listed OUIs only.
■ Allow New Clients to Group - specify the client group to persist the
newly authenticated MAC addresses.
 ○ Allow Registered Clients and Authorized OUIs - Behavior similar to Allow
Registered Clients Only and Authorized OUIs Only combined.

Figure 40: Wireless MAC Authentication Network

Wired 802.1X
Wired network configuration provides means to authenticate end clients connected to the wired
switch port. The system supports 802.1X authentications from the endpoints.

Prerequisites
● The switch is configured to perform 802.1X against the product
● VLANs/ACLs used in the segmentation policies are configured on the switch.

Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wired
● Access Device Group
○ Optional setting. If the network authentication is only applicable to a subset of
Access Devices then choose the Access Device Group. Otherwise the network
is applicable to all the network access devices.
● Authentication
○ Choose the Authentication Type as Client Certificate (EAP-TLS)
● Domain Machine Authentication
○ Enable this setting to process the domain machine authentication (via EAP-TLS)
requests.

Figure 41: Add Network (Authentication)

● Trust External Certificates

○ Disabled - Option is applicable when using the system's PKI. This is the default
option.

Figure 42: Trust External Certificates

○ Enabled - Option is applicable when using external PKI. Note to import Root and
Issuer CAs into the system.
■ CRL Verification - Select this option to verify the certificate revocation via
CRLs
■ OCSP Verification - Select this option to verify the certificate revocation
via OCSP.
 Figure 43: Add Network (Trusted External Certificates)

● Fallback to MAC Authentication

○ Disabled - If 802.1X authentication fails then the system will reject the client
authentication attempt

Figure 44: Add Network (Fallback To MAC Authentication)

○ Enabled - If 802.1X authentication fails then the system falls back to MAC
authentication.
■ MAC Authentication Type - Lists the available authentication settings
and choose the one applicable for the network.
● Allow All Clients - When set, the MAC authentication admits all
the clients that are attempting the wired authentication. Choose a
client group to add the authenticated MAC addresses. This will
help to build an inventory of the client devices.

Figure 45: Add Network (MAC Address Authentication Settings)

● Allow Registered Clients Only - The system will honor MAC

authentication attempts only from the registered clients. All the
other clients will be rejected.
 Figure 46: Add Network (Fallback to MAC Authentication)

● Allow Authorized OUIs Only - When set the system will honor
the MAC authentication attempts only from the clients matching
the authorized OUI list. The Authorized OUI list needs to be
specified for this setting. Choose a client group to add the
authenticated MAC addresses. This will help to build an inventory
of the client devices.

■ Allow Registered Clients and Authorized OUIs - Behavior similar to

Allow Registered Clients Only and Authorized OUIs Only combined.

Figure 47 : Allow Authorized OUIs Only

● Onboarding - Admin can enable the Onboarding option to enable self certificate
generation. Users can use the onboarding url to get authenticated and generate the
certificate. Admin can allow onboarding for specific user groups.
For local users admin can enable self registration to enroll them in the system.
 Figure 48 : Onboardig

● Click on Add Network to save the configuration. The created wired 802.1X network is
shown as below.

Figure 49: Sample Wired 802.1X configuration

Wired MAC Authentication

Wired network configuration provides means to authenticate end clients connected to the wired
switch port. MAC authentication is a way of authenticating wired clients if the endpoint doesn’t
do 802.1X.

Prerequisites
● Switch is configured to perform MAC ByPass authentication against the product
● VLANs/ACLs used in the segmentation policies are configured on the switch.
Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as Wired
● Access Device Group
○ (Optional setting) If the network authentication is only applicable to a subset of
Access Devices then choose the Access Device Group. Otherwise, the network
is applicable to all the network access devices.
● Authentication
○ Authentication Type - Choose MAC Authentication
● MAC Authentication Settings - Lists the available authentication settings and choose
the one applicable for the network.
○ Allow All Clients - When set, the MAC authentication admits all the clients that
are attempting the wired authentication. Choose a client group to add the
authenticated MAC addresses. This will help to build inventory of the client
devices.

Figure 50: Add Network

○ Allow Registered Clients Only - The system will honor MAC authentication
attempts only from the clients that are registered with the system. All the other
clients will be rejected.

Figure 51: Add Network (MAC Address Authentication Settings)

○ Allow Authorized OUIs Only - When set, the system will honor the MAC
authentication attempts only from the clients matching the authorized OUI list.
The Authorized OUI list needs to be specified for this setting. Choose a client
 group to add the authenticated MAC addresses. This will help to build inventory
of the client devices.
○ Allow Registered Clients and Authorized OUIs - Behavior similar to Allow
Registered Clients Only and Authorized OUIs Only combined.

Figure 52: Add Network (Authorized OUIs)

● Click on Add Network to save the configuration. The created wired MAC authentication
network is shown below.
 Figure 53: MAC ByPass Authentication Configuration

Wired Captive Portal

Captive Portal authentication provides capabilities for L3 authentication in the network. The end
user is connected to the switch port and is redirected to the Captive Portal to perform the
authentication post-successful Mac Authentication. Network access is provided based on the
authentication result.

With Captive Portal authentication the network administrators have the flexibility to drive
reauthentication at periodic intervals (in days), never or always.

Prerequisites
● AGNI Captive Portal URL should be configured in the switch ACL
● ACL and Mac Authentication configuration on switches
● Network Enforcement details configured in the switch

Configuration
● Navigate to Access Control → Networks. Click on Add Networks
● Provide the Network Name and choose ConnectionType as wired
● Authentication
○ Authentication Type - Choose Captive Portal
● Captive Portal
○ Initial ACL for Portal Authentication - Specify the initial ACL for Captive Portal
authentication. Note that this ACL needs to be configured on the switch and the
user is forced to redirect to the captive portal by ACL applied on the switch port.
○ Re-authenticate Registered Clients - Specify one of the below options
■ Always - If the user to be authenticated every time they connect to switch
port
 Figure 54: Captive Portal
■ Periodic - If the re-authentication is required once in a few days. The
configuration setting requires a Re-authentication period interval to be
specified in days

Figure 55: Captive Portal (Re-authentication Option Periodic)

● Add the network. The process will generate a Captive Portal URL which should be
specified in the switch ACL.

Figure 56: Captive Portal URL

Segments
Segments allow a way to provide differentiated access for the incoming access request. The
segments comprise of Status, Conditions, and Actions.

Status
The Segment status comprises Enable, Disable, and Monitor modes.

Enable
Enables the segment configuration. Segment is evaluated and if conditions match then an
appropriate action is returned as a part of segment evaluation.
Disable
Disables the segment configuration. Segment is not evaluated even if it is configured.

Monitor
Sets up the segment in monitor only mode. The actions will be ignored even if the conditions
match. This is useful to evaluate the segment before rolling out to production.

Conditions
Conditions provide ability to define rules based on various attributes associated with:

● RADIUS request
● Networks
● Clients
● Users
● Access Devices

The conditions are evaluated in the order of the configuration and they proceed to match all
evaluation algorithms. The condition is evaluated to be true only if all the rules match.

Actions
Actions define the result that needs to be sent to access devices. The results can take various
forms that are interpreted by the network access device. Actions can be formed via:
● VLAN assignment
● Application of ACLs
● Allow or deny helper access primitives
● Standard RADIUS attributes
● VSAs

Configuration
● Navigate to Access Control → Segments. Click on Add Segment
● Input Name, Description
● Add Conditions
● Add Actions
● Click on Add Segment to save the segment

Sample Segments
Sample segment policies are shown below.
Sample Employee Access Segment

Figure 57: Employee Access Segment Policy

Sample Contractor Access Segment

Figure 58: Contractor Access Segment Policy

Sample BYOD Access Segment

Figure 59: BYOD Access Segment Policy

Sample IOT Access Segment

Figure 60: IOT Access Segment Policy

User Configurations

Users
Admin can manage local and external users from the Users tab. External users correspond to
the users in external identity providers while the local users are those within AGNI’s local
identity provider.

External Users
AGNI synchronizes the users in external IDPs (eg: Azure AD, Okta, OneLogin, and others)
along with user attributes and group memberships. The users are marked external in the user’s
listing.
 Figure 61: External Users

Admin can enable or disable the status of these users if IDP sync is disabled. If the sync is
enabled, then the user status is configured in IDPs will be reflected in AGNI . Also, the admin
can manage the devices logged-in via this username.

Figure 62: External User Updation

Local User
Local users are managed within AGNI and can be used against any of the product workflows to
locally authenticate with the system. The emails are sent by AGNI only if the Login Invitation
Email option is enabled.
 Figure 63: Local Users Addition

User Groups
User Groups facilitate the management of external and local groups. External groups are
managed via external IDP and local groups are managed locally to the system. User Groups
can be used in the segmentation policies to authorize the users into the network. External User
Groups are synchronized with the configured IDPs. These are managed externally. AGNI
provides visibility of the group details in this interface. If an external user group needs to be
deleted then Admin has to remove it from the Available Groups in the IDP config. The changes
are local to the system and not reflected in the external IDPs.

Figure 64: External User Groups

Local User Groups
Local User Groups provide the ability for administrators to manage the users within local group
membership. With this one can map local users with the configured local user group. As this is
managed locally in the system, the administrators can add, modify and delete these entities.

Figure 65: Local User Group

Client Configuration

Client Groups
Client Groups provide a way to manage the client devices that are being authenticated by AGNI.
The clients can be added either manually or dynamically by the system.

Group UPSK
Client Groups can be defined with a Group UPSK which can be used to onboard the desired
client devices in that specific group.
 Figure 66: Client Group UPSK

Allowed Networks
The network access to the clients under the group can be controlled by specifying the Allowed
Network option.

Figure 67: Client Group Allowed Network

Delegated Management
The Client Group management can be delegated to a User Group that is specified under this
setting. This may be required if the administrator decides to delegate the responsibility of
managing a specific set of client groups to specific users in an organization. This allows
delegated administrators to add or remove clients from the group.
 Figure 68: Client Group Delegated Management

Clients
The Clients section captures the endpoints in the following scenarios:
● Dynamically registered clients as a part of authentication (eg: auto registered via UPSK)
● Manually registered clients as a part of self registration
● Manually registered clients as a part of user onboarding
● Clients synchronized as a part of a Concourse application

The clients can also be imported or added into the system through the Add Clients or Import
Clients option. The addition of the clients requires the MAC address of the clients and while
import requires the client entries to be present in a CSV file. A sample reference CSV file import
template can be used to construct the client entries.
 Figure 69: Client Addition

Figure 70: Client Import

Client Details
Clicking on the clients opens up client details page showcasing the following information:

● Client Information - Capturing - MAC address, description, client group, passphrase

and status
● Client Attributes - Custom attributes associated with the client if available
● Client Details - Client device classification details
● Client Fingerprint - DHCP, MAC OUI, User Agent fingerprinting information if available
● Last Session Details - Details about the last client connectivity to the network
● Network - Network details
● Access Device - Client connection to the access device and its details
● Sessions - Current and past sessions associated with the client
● Client Activity - Client activity is present if there is a CoA activity for the client

Figure 71: Client Details

Figure 72: Client sessions

System
This section captures the administrative tasks at the system level.

Audit Viewer
Captures details about system configuration modifications. This helps to track any changes
performed on the system along with the owner, modified details and timestamp.

Figure 73: Audit Viewer

License
Displays the licensing information about the type, count and validity period.
 Figure 74: License

Portal Settings
The Portal Settings can be used to customize the Captive Portal network user experience. This
allows customization of logo, text, images and theme to be applied on the captive portal page
for the organization needs. The customization can be applied to landing as well as login pages.

Figure 75: Portal Settings

RadSec Settings
The RadSec certificate of the system can be viewed and downloaded from Configuration →
System → RadSec Settings . The certificate needs to be imported into the network access
devices for the successful establishment of the RadSec tunnel.
 Figure 76: RadSec Settings

Support Logs
The Support Logs section provides the ability to view and download the system logs for the
specified duration that can be used to analyze the system operations. The logs are shown from
various services running as a part of the system operation and can be used for troubleshooting.

Figure 77: Support Logs

System Events
Various events recorded by the services are logged under System Events. They provide
information, warning or errors related to the system operation. Remediation action can be taken
if necessary.
 Figure 78: System Events

Troubleshooting

Monitoring
AGNI provides monitoring tools in terms of dashboards and session details. The tools provide a
mechanism to troubleshoot the system operations, client authentication, and network device
connection establishment status with AGNI.

Dashboards
The user and client authentication details, access device status can be viewed from the AGNI
dashboards. The Session Trend captures the authentication trend with the details on total and
failed authentications over a period of time.

To access dashboards, navigate to Monitoring → Dashboard

 Figure 79: AGNI Dashboard and Session Trend

Charts are available to indicate the top failure reasons and top locations affected by the failures
in the customer environment. The custom widget provides the ability to choose the charts based
on the past date.

Figure 80: AGNI Dashboard and charts

Sessions
Sessions provide a runtime view of authentication trends. All the authentication details from
802.1X, UPSK, Captive Portal, MBA are captured in this view.

Sessions capture granular details about the incoming authentication request, system
processing, and response. The sessions can be filtered based on:
● MAC address
● Identity
 ● IP address
● Session Identifier

To access sessions, navigate to Monitoring → Sessions.

Figure 81: Sessions

To view the session details click on the eye icon. This will open up a detailed session
information and can be used for troubleshooting.

Figure 82: Session Details

 Figure 83: Session Details

Show logs option in session details provide valuable information about the session and
complete debug logs of the request. This can be used to troubleshoot the request failure and
take an appropriate action.

Figure 84: Sessions and show logs

Appendix

OIDC Vs SAML
The following factors may help in choosing between OIDC and SAML.
● SAML is an older standard and hard to use for modern application use cases mainly
because of the complexity surrounding the protocol.
● OIDC is a newer and well maintained protocol built on top of OAuth 2.0 framework.
OIDC uses industry standard mechanisms to define the rules to securely transfer claims
between involved parties.
● OIDC is designed to be a modern replacement of SAML and it replicates most of the
fundamental SAML use cases. This by design reduces the complexity and overhead
caused by XML and SOAP based messages used in SAML.
● As SAML uses XML the vulnerabilities associated with XML must be avoided during
SAML implementation. This introduces further complexities in the implementation and
varies from vendor to vendor.
● OIDC is based on OAuth 2.0 and it incorporates a lot of the documented threat model
and security considerations.

Identity Providers

Microsoft Azure Active Directory

● Log in to Azure Active Directory instance.

● Create a New Registration by navigating to Home→Manage → App Registrations
● Click on the newly created registration. Note the values of
○ Application (client) ID. This will be the Client ID field to be used in AGNI
○ Directory (tenant) ID. This will be Tenant ID field to be used in AGNI
● Navigate to Manage → Certificates & Secrets. Add a ‘New Client Secret’
● Note the value of the newly created secret.
○ This value will be the Client Secret value to be used in AGNI
● Navigate to Manage → API Permissions. Set the following permissions.
 API Permission Type Admin Consent Status

Directory.Read.All Application Yes Grant admin consent

Group.Read.All Application Yes Grant admin consent

GroupMember.Read.All Application Yes Grant admin consent

User.Read.All Application Yes Grant admin consent

Google Workspace

● Log in to Google Workspace

● Note the following entities from Google Console
○ Customer ID
○ Domain
○ Account Email - The username of the Google Workspace account that has
minimum permissions to read the User and Group objects. Normally, this is the
account that is used to configure or manage the GWS configuration objects.
○ Service Account
● Reading Customer ID and Domain
○ Log in into https://admin.google.com
 ○ Navigate to Account → Account Settings
○ Note Customer ID displayed in the Profile section
○ Navigate to Domains → Manage Domains
○ Note the primary domain name as Domain
● Configuring Service Account
○ Log in into https://console.cloud.google.com
○ Create a new project for AGNI
○ Navigate to APIs & Services → Credentials
○ Create a new Service Account and download the JSON
● Scopes for Service Account
○ Log in into https://admin.google.com
○ Select Enable Google Workspace domain-wide delegation for the Service
Account
○ Enter the following common separate OAuth scopes
■ https://www.googleapis.com/auth/admin.directory.user,
■ https://www.googleapis.com/auth/admin.directory.user.readonly,
■ https://www.googleapis.com/auth/admin.directory.user.security,
■ https://www.googleapis.com/auth/admin.directory.group,
■ https://www.googleapis.com/auth/admin.directory.group.readonly,
■ https://www.googleapis.com/auth/admin.directory.group.member,
■ https://www.googleapis.com/auth/admin.directory.group.member.readonly,
■ https://www.googleapis.com/auth/admin.directory.rolemanagement,
■ https://www.googleapis.com/auth/admin.directory.rolemanagement.reado
nly,
■ https://www.googleapis.com/auth/cloud-platform

OneLogin
● Log in to OneLogin administration interface
● Navigate to Applications → Applications and add new OpenId Connect (OIDC)
application
● Note down the Client ID and Issuer URL under SSO section of the application
● Navigate to Developers → API Credentials
● Add New Credentials and the privileges set to Read users
● Note down Client ID and Client Secret

Okta
● Log in to Okta administration interface
● Navigate to Applications → Applications and add new Create App Registration
● Choose Client Authentication as None
● Choose Proof Key for Code Exchange (PKCE)
● Set the Application Type as Single Page App (SPA)
● Grant Type set to Client Acting on behalf of a user
○ Authorization Code
 ○ Refresh Token
● Specify the Sign in redirect URLs (AGNI’s cluster details as documented)
● Set Login initiated by App Only
● Once created note down Client ID
● Navigate to Security → API
● Create a new token
● Note down
○ Issuer URI
○ API Key