CN117240718A

CN117240718A - Network access control intent-based policy configuration

Info

Publication number: CN117240718A
Application number: CN202211600309.5A
Authority: CN
Inventors: V·德蒙特耶夫; K·K·马纳尔; M·R·奇特希拉拉; N·曼休拉穆尔蒂; R·R·塔迪梅蒂
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2022-06-14
Filing date: 2022-12-13
Publication date: 2023-12-15

Abstract

Network access control intent-based policy configuration. Techniques for configuration and application of intent-based Network Access Control (NAC) policies for authentication and authorization of enterprise networks of a multi-tenant Network Access Server (NAS) device access organization are described. The network management system configures intent-based NAC policies for the organization. The cloud-based NAC system can apply the appropriate intent-based NAC policy in response to an authentication request from the NAS device. The NAC system identifies a vendor of the NAS device, matches the incoming attributes in the authentication request with a standardized set of matching rules for the intent-based NAC policy, and converts an extracted policy result set corresponding to the standardized set of matching rules to a vendor-specific set of return attributes based on the vendor of the NAS device. The NAC system sends a vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

Description

Network access control intent-based policy configuration

Cross Reference to Related Applications

The present application claims the benefit of U.S. patent application Ser. No. 17/937,208, filed on 9/2022, and U.S. provisional patent application Ser. No. 63/366,382, filed on 14/2022, 6, and incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates generally to computer networks and, more particularly, to managing access to computer networks.

Background

A business or site, such as an office, hospital, airport, stadium, or retail store, typically installs a complex wireless network system (including a wireless Access Point (AP) network) throughout the site to provide wireless network services to one or more wireless client devices (or simply "clients"). An AP is a physical electronic device that enables other devices to connect wirelessly to a wired network using various wireless network protocols and technologies, such as wireless local area network protocols conforming to one or more IEEE 802.11 standards (i.e., "WiFi"), bluetooth/Bluetooth Low Energy (BLE), mesh network protocols such as ZigBee, or other wireless network technologies.

Many different types of wireless client devices, such as laptop computers, smart phones, tablet computers, wearable devices, appliances, and internet of things (IoT) devices, integrate wireless communication technology and may be configured to connect to a wireless access point when the device is within range of a compatible AP. To gain access to the wireless network, the wireless client device may first need to authenticate to the AP. Authentication may occur via a handshake exchange between a wireless client device (AP) and an Authentication Authorization and Accounting (AAA) server that controls access at the AP.

Disclosure of Invention

In general, this disclosure describes one or more techniques for configuring and applying intent-based Network Access Control (NAC) policies for authentication and authorization of enterprise networks of a multi-tenant Network Access Server (NAS) device access organization. In accordance with the disclosed technology, a Network Management System (NMS) that provides a management plane for one or more cloud-based NAC systems and a plurality of NAS devices associated with one or more organizations configures intent-based NAC policies for the organization based on user input indicative of the intent of a network administrator. A NAC system providing NAC services to an organization may apply an appropriate intent-based NAC policy of the one or more intent-based NAC policies in response to receiving an authentication request from the NAS device to access an enterprise network of the organization. The NAC system automatically identifies a vendor of the NAS device based on the authentication request, matches the incoming attributes in the authentication request with a standardized set of matching rules for the intent-based NAC policy, and converts an extracted policy result set corresponding to the standardized set of matching rules in the intent-based NAC policy to a vendor-specific set of return attributes based on the vendor of the NAS device. The NAC system then sends the vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

Traditionally, NAC authentication and authorization policy configuration is a very complex process that requires an organization's network administrator's in-depth knowledge of the particular NAC product, as well as in-depth understanding of the particular AAA protocol (e.g., RADIUS). This complexity grows exponentially with each additional NAS provider in the enterprise network, as the network administrator needs to know exactly what type of attribute is used by a particular NAS provider and device type. This complexity typically results in the network administrator creating a unique set of policy rules and return attributes for each NAS vendor and device type, making overall policy management operationally challenging.

The disclosed technology provides one or more technical advantages and practical applications. For example, the disclosed technology enables NAC policies to be created based on the intent of the network administrator (e.g., who can authenticate to the network, what policies are to be applied based on the user or device identity and its status, etc.). The intent-based NAC policy includes a standardized set of matching rules and a corresponding set of extraction policy results that are agnostic to the vendor. In some examples, the standardized set of matching rules for the intent-based NAC policy includes both authentication rules and authorization rules standardized to be vendor agnostic. In this way, the disclosed techniques may combine or collapse multiple configuration phases (i.e., authentication policy configuration and authorization policy configuration) into a single configuration phase. The intent-based NAC policy configuration disclosed herein hides the configuration complexity associated with conventional NAC systems from administrators and other end users and significantly improves the operational experience when managing NAC systems.

Further, the disclosed techniques enable dynamic vendor learning such that the NAC system can automatically identify the vendor of the NAS device based on the authentication request and vendor signature received from the NAS device. The NAC system can automatically configure a first vendor-specific set of return attributes from the intent-based NAC policy based on the first vendor identified for the first NAS device requesting network access. The NAC system can also automatically configure a second vendor-specific set of return attributes from the same intent-based NAC policy based on the second vendor identified for the second NAS device requesting network access. The disclosed techniques greatly simplify overall NAC policy configuration and operation, especially in large-scale, multi-provider networks. The technique also reduces the requirements on the network administrator so that no in-depth AAA or NAC product knowledge is required.

In one example, the present disclosure relates to a system comprising an NMS configured to manage a plurality of multi-vendor NAS devices associated with one or more organizations, and at least one cloud-based NAC system in communication with the NMS. The at least one NAC system is configured to: obtaining, from the NMS, one or more intent-based NAC policies of one of the one or more organizations, wherein the one or more intent-based NAC policies include one or more standardized sets of matching rules associated with corresponding sets of extraction policy results that are agnostic to the vendor; receiving an authentication request from the NAS device for an enterprise network of the organization; identifying a vendor of the NAS device based on the authentication request; matching one or more incoming attributes included in the authentication request from the NAS device with a standardized set of matching rules for an intent-based NAC policy of the one or more intent-based NAC policies; converting, based on the vendor of the NAS device, a set of extraction policy results corresponding to a standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes; and transmitting the vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

In another example, the present disclosure relates to a method comprising obtaining, by a cloud-based NAC system, one or more intent-based NAC policies of an organization from an NMS configured to manage a plurality of multi-vendor NAS devices associated with the organization, wherein the one or more intent-based NAC policies include one or more standardized sets of matching rules associated with corresponding sets of extraction policy results that are agnostic to the vendor; receiving, by the NAC system, an authentication request from the NAS device for an enterprise network of the organization; identifying, by the NAC system, a vendor of the NAS device based on the authentication request; matching, by the NAC system, one or more incoming attributes included in the authentication request from the NAS device with a standardized set of matching rules for an intent-based NAC policy of the one or more intent-based NAC policies; converting, by the NAC system, a set of extraction policy results corresponding to the standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes for the vendor of the NAS-based device; and sending, by the NAC system, the vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

In another example, the disclosure relates to a computer-readable storage medium storing instructions that, when executed, cause one or more processors to: obtaining, by the cloud-based NAC system, one or more intent-based NAC policies of the organization from an NMS configured to manage a plurality of multi-vendor NAS devices associated with the organization, wherein the one or more intent-based NAC policies include one or more standardized sets of matching rules associated with corresponding sets of extraction policy results that are agnostic to the vendor; receiving an authentication request from the NAS device for an enterprise network of the organization; identifying a vendor of the NAS device based on the authentication request; matching one or more incoming attributes included in the authentication request from the NAS device with a standardized set of matching rules for an intent-based NAC policy of the one or more intent-based NAC policies; converting, based on the vendor of the NAS device, a set of extraction policy results corresponding to a standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes; and transmitting the vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

The details of one or more examples of the technology of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.

Drawings

Fig. 1A is a block diagram of an example network system including a network management system and a network access control system in accordance with one or more techniques of this disclosure.

Fig. 1B is a block diagram illustrating further example details of the network system of fig. 1A.

Fig. 2 is a block diagram of an example network access control system in accordance with one or more techniques of this disclosure.

Fig. 3 is a block diagram of an example network management system in accordance with one or more techniques of the present disclosure.

Fig. 4 is a block diagram of an example access point device in accordance with one or more techniques of this disclosure.

Fig. 5 is a block diagram of an example edge device in accordance with one or more techniques of this disclosure.

Fig. 6 is a conceptual diagram illustrating a general NAC policy configuration procedure for two different NAS providers.

Fig. 7 is a conceptual diagram illustrating an intent-based NAC policy configuration process in accordance with one or more techniques of the present disclosure.

Fig. 8 illustrates an example user interface provided by an NMS to implement configuring intent-based NAC policies based on labels in accordance with the techniques of this disclosure.

Fig. 9A and 9B illustrate an example user interface provided by an NMS to implement configuration of new labels, including selecting a label type for a new label and selecting a label value for a new label, in accordance with the techniques of this disclosure.

Fig. 10 is a flowchart illustrating example operations of an application of applying an intent-based NAC policy in response to receiving an authentication request from a NAS device in accordance with one or more techniques of the present disclosure.

Detailed Description

Fig. 1A is a block diagram of an example network system 100 including Network Access Control (NAC) systems 180A-180K and a Network Management System (NMS) 130 in accordance with one or more techniques of the present disclosure. The example network system 100 includes a plurality of sites 102A-102N at which a network service provider manages one or more wireless networks 106A-106N, respectively. Although in fig. 1A, each station 102A-102N is shown to include a single wireless network 106A-106N, respectively, in some examples, each station 102A-102N may include multiple wireless networks, and the disclosure is not limited in this respect.

Each site 102A-102N includes a plurality of Network Access Server (NAS) devices 108A-108N, such as an Access Point (AP) 142, a switch 146, and a router 147.NAS devices may include any network infrastructure device capable of authenticating and authorizing client devices to access an enterprise network. For example, station 102A includes a plurality of APs 142A-1 through 142A-M, a switch 146A, and a router 147A. Similarly, station 102N includes a plurality of APs 142N-1 through 142N-M, a switch 146N, and a router 147N. Each AP 142 may be any type of wireless access point that connects to a wired network and is capable of providing wireless network access to client devices within a site, including but not limited to a business or enterprise AP, router, or any other device. In some examples, each of the APs 142A-1 to 142A-M at station 102A may be connected to one or both of switch 146A and router 147A. Similarly, each of the APs 142N-1 through 142N-M at station 102N may be connected to one or both of switch 146N and router 147N.

Each station 102A-102N also includes a plurality of client devices, also referred to as user equipment devices (UEs), generally referred to as UEs or client devices 148, representing the various wireless-enabled devices within each station. For example, plurality of UEs 148A-1 through 148A-K are currently located at site 102A. Similarly, a plurality of UEs 148N-1 through 148N-K are currently located at site 102N. Each UE 148 may be any type of wireless client device including, but not limited to, a mobile device such as a smart phone, tablet or laptop computer, personal Digital Assistant (PDA), wireless terminal, smart watch, smart ring, or other wearable device. UE 148 may also include a wired client device (e.g., an IoT device such as a printer, security device, environmental sensor) or any other device connected to a wired network and configured to communicate over one or more wireless networks 106.

To provide wireless network services to UE 148 and/or communicate via wireless network 106, AP 142 and other wired client devices at site 102 are directly or indirectly connected to one or more network devices (e.g., switches, routers, gateways, etc.) via physical cables (e.g., ethernet cables). Although illustrated in fig. 1A as if each site 102 included a single switch and a single router, in other examples, each site 102 may include more or fewer switches and/or routers. Furthermore, two or more switches of one site may be connected to each other and/or to two or more routers, e.g., via a mesh or partial mesh topology in a hub-and-spoke architecture. In some examples, the interconnected switches 146 and routers 147 include a wired Local Area Network (LAN) at the site 102 hosting the wireless network 106.

The example network system 100 also includes various networking components for providing networking services within a wired network, including, for example, a NAC system 180, the NAC system 180 including or providing access to: an authentication, authorization, and accounting (AAA) server for authenticating users and/or UEs 148, a Dynamic Host Configuration Protocol (DHCP) server 116 for dynamically assigning network addresses (e.g., IP addresses) to UEs 148 upon authentication, a Domain Name System (DNS) server 122 for resolving domain names to network addresses, a plurality of servers 128A-128X (collectively "servers 128") (e.g., network servers, database servers, file servers, etc.), and NMS 130. As shown in fig. 1A, various devices and systems of network 100 are coupled together via one or more networks 134 (e.g., the internet and/or an intranet).

In the example of fig. 1A, NMS 130 is a cloud-based computing platform that manages wireless networks 106A through 106N at one or more sites 102A through 102N. As further described herein, NMS 130 provides an integrated set of management tools and implements the various techniques of this disclosure. In general, NMS 130 may provide a cloud-based platform for wireless network data acquisition, monitoring, activity logging, reporting, predictive analysis, network anomaly identification, and alarm generation. In some examples, NMS 130 outputs notifications, such as alarms, alerts, graphical indicators on the dashboard, log messages, text/SMS messages, email messages, etc., and/or suggestions regarding wireless network problems, to a site or network administrator ("administrator") interacting with administrator device 111 and/or operating administrator device 111. Additionally, in some examples, NMS 130 operates in response to configuration inputs received from an administrator interacting with administrator device 111 and/or operating administrator device 111.

Administrator and administrator devices 111 may include IT personnel and administrator computing devices associated with one or more sites 102. The administrator device 111 may be implemented as any suitable device for presenting output and/or accepting user input. For example, the administrator device 111 may include a display. The administrator device 111 may be a computing system, such as a mobile or non-mobile computing device operated by a user and/or administrator. In accordance with one or more aspects of the present disclosure, administrator device 111 may represent, for example, a workstation, a laptop or notebook computer, a desktop computer, a tablet computer, or any other computing device operable by a user and/or presenting a user interface. The administrator device 111 may be physically separate and/or located in a different location from the NMS 130 such that the administrator device 111 may communicate with the NMS 130 via the network 134 or other communication means.

In some examples, one or more NAS devices 108 (e.g., AP 142, switch 146, and router 147) may be connected to edge devices 150A-150N via physical cables (e.g., ethernet cables). Edge device 150 includes a cloud managed wireless Local Area Network (LAN) controller (WLC). Each of the edge devices 150 may comprise a local device at the site 102 that communicates with the NMS 130 to extend some micro services from the NMS 130 to the local NAS devices 108 while using the NMS 130 and its distributed software architecture for scalable and resilient operation, management, troubleshooting, and analysis.

Each of the network devices of network system 100 (e.g., NAC system 180, servers 116, 122, and/or 128, AP 142, switch 146, router 147, UE148, edge device 150, and any other servers or devices attached to or forming part of network system 100) may include a system log or error log module, where each of these network devices records the status of the network device, including normal operating status and error conditions. Throughout this disclosure, one or more network devices of network system 100 (e.g., servers 116, 122 and/or 128, AP 142, switch 146, router 147, and UE 148) may be considered "third party" network devices when owned by and/or associated with an entity other than NMS 130, such that NMS 130 does not directly receive, collect, or otherwise access the record status and other data of the third party network devices. In some examples, edge device 150 may provide an agent through which logging status and other data of third party network devices may be reported to NMS 130.

In the example of fig. 1A, each of NAC systems 180 includes cloud-based network access control services at a plurality of geographically distributed points of presence. Typically, the network access control functionality is provided by local devices that are limited by processing power and memory as well as maintenance and upgrade issues. Providing cloud-based network access control services avoids these limitations and improves network management. However, centralized, cloud-based deployment of network access control introduces problems that may prevent delays and failures of client devices accessing the network.

In accordance with the disclosed technology, the NAC system 180 provides multiple points of presence or NAC clouds in several geographic regions. NMS 130 is configured to manage NAC configurations, including access policies for enterprise networks, and push appropriate NAC configuration data or files to the respective NAC clouds 180A-180K. In this way, NAC system 180 provides the same benefits as a centralized, cloud-based network access control service, with lower latency and high availability.

NAC system 180 provides a way to authenticate client devices 148 to access wireless network 106, such as a branch office or campus enterprise network. NAC systems 180 can each include or provide access to an authentication, authorization, and accounting (AAA) server (e.g., a RADIUS server) to authenticate client device 148 before providing access to an enterprise network via NAS device 108. In some examples, NAC system 180 may enable certificate-based authentication of a client device or enable interaction with a cloud directory service to authenticate a client device.

NAC system 180 can identify client devices 148 and provide appropriate authorization or access policies to client devices 148 based on their identity, for example, by assigning client devices to certain Virtual Local Area Networks (VLANs), applying certain Access Control Lists (ACLs), directing client devices to certain registration portals, and so forth. NAC system 180 can identify client device 148 by analyzing the network behavior of the client device (referred to as fingerprinting). The identification of the client device may be performed based on a Media Access Control (MAC) address, a DHCP option for requesting an IP address, a Link Layer Discovery Protocol (LLDP) packet, user agent information, and/or device type and operating system information.

Client device 148 may include a number of different classes of devices for a given enterprise, such as trusted enterprise devices, in-band devices (BYOD) devices, ioT devices, and guest devices. The NAC system 180 may be configured to subject each of the different classes of devices to different types of tracking, different types of grants, and different levels of access rights. In some examples, after a client device gains access to the enterprise network, NAC system 180 may monitor the activity of the client device to identify security issues and, in response, reassign the client device to a quarantine VLAN or another lower-authority VLAN to restrict access by the client device.

NMS 130 is configured to operate in accordance with an artificial intelligence/machine learning-based computing platform that provides comprehensive automation, insight, and assurance (WiFi assurance, wired assurance, and WAN assurance), ranging from "clients" (e.g., client devices 148 connected to wireless network 106 and a wired Local Area Network (LAN) at site 102) to "clouds" (e.g., cloud-based application services that may be hosted by computing resources within one or more data centers).

As described herein, NMS 130 provides an integrated set of management tools and implements the various techniques of the disclosure. In general, NMS 130 may provide a cloud-based platform for wireless network data acquisition, monitoring, activity logging, reporting, predictive analysis, network anomaly identification, and alarm generation. For example, NMS 130 may be configured to actively monitor and adaptively configure network 100 to provide self-driving capabilities. NMS 130 may be implemented by computing resources located in a different location relative to the physical location of the physical devices of site 102 and/or may be implemented by computing resources located in a different network or autonomous system than site 102.

In some examples, AI-driven NMS 130 also provides configuration management, monitoring, and automatic supervision of a software-defined wide area network (SD-WAN) that operates as an intermediary network communicatively coupling wireless network 106 and the wired LAN at site 102 to data centers and application services. In general, the SD-WAN provides a seamless, secure, traffic-engineered connection between "branch" routers (e.g., router 147) of a wired LAN hosting a wireless network 106 (e.g., a branch office or campus enterprise network) to further reach up the cloud stack to a "hub" router of the cloud-based application service. SD-WANs typically operate and manage an overlay network over an underlying physical Wide Area Network (WAN) that provides connectivity to geographically separated customer networks. In other words, the SD-WAN extends Software Defined Networking (SDN) capabilities to the WAN and allows the network(s) to separate the underlying physical network infrastructure from the virtualized network infrastructure and applications so that the network can be configured and managed in a flexible and extensible manner.

In some examples, AI-driven NMS 130 may enable intent-based configuration and management of network system 100, including enabling configuration, presentation, and execution of intent-driven workflows for configuring and managing devices associated with wireless network 106, a wired LAN network, and/or an SD-WAN. For example, declarative requirements express the desired configuration of network components without specifying the exact local device configuration and control flow. By utilizing declarative requirements, it is possible to specify what should be done rather than how. Declarative requirements may be contrasted with imperative instructions describing the exact device configuration syntax and control flow that implements the configuration. By utilizing declarative requirements rather than imperative instructions, the burden on the user and/or user system to determine the exact device configuration needed to achieve the desired results for the user/system is reduced. For example, when utilizing various different types of devices from different vendors, it is often difficult and burdensome to specify and manage precise imperative instructions to configure each device of the network. The type and kind of network devices may change dynamically as new devices are added and device failures occur. Managing a cohesive network of devices from different vendors with different configuration protocols, grammars, and software versions to configure the devices is often difficult to achieve. Thus, by requiring only the user/system to specify declarative requirements that specify desired results applicable to a variety of different types of devices, management and configuration of network devices becomes more efficient. Further example details and techniques of Intent-based network management systems are described in U.S. patent No. 10,756,983 entitled "Intent-based analysis" and U.S. patent No. 10,992,543 entitled "automatically generating Intent-based network models (Automatically generating an Intent-based network model of an existing computer network) of existing computer networks," each of which are incorporated herein by reference.

Although the techniques of this disclosure are described in this example as being performed by NAC system 180 and/or NMS130, the techniques described herein may be performed by any other computing device(s), system(s), and/or server(s), and the disclosure is not limited in this respect. For example, one or more computing devices configured to perform the functions of the techniques of this disclosure may reside in a dedicated server, or be included in any other server other than NAC system 180 or NMS130, or may be distributed throughout network 100, and may or may not form part of NAC system 180 or NMS 130.

Fig. 1B is a block diagram illustrating additional example details of the network system of fig. 1A. In this example, fig. 1B illustrates logical connections 178A through 178N, 182A through 182N, and 184A through 184K between NAS device 108, NAC system 180, and NMS130 at site 102. Further, fig. 1B illustrates NMS130, NMS130 being configured to operate in accordance with an AI-based computing platform to provide configuration and management of one or more NAC systems 180 and NAS devices 108 at site 102 via logical connections.

In operation, NMS130 observes, collects, and/or receives network data 137, network data 137 may take the form of data extracted from, for example, messages, counters, and statistics from one or more APs 142, switches 146, routers 147, edge devices 150, NAC system 180, and/or other nodes within network 134. NMS130 provides a management plane for network 100 that includes management of organization-specific configuration information 139 for one or more NAS devices 108 at site 102 and NAC system 180. Each of the one or more NAS devices 108 and each of the NAC systems 180 may have a secure connection with the NMS130, for example, a RadSec (RADIUS over Transport Layer Security (TLS)) tunnel or another encrypted tunnel. Each of NAS device 108 and NAC system 180 may download the appropriate organization-specific configuration information 139 from NMS130 and implement the configuration. In some scenarios, one or more NAS devices 108 may be third party devices or not support establishing secure connections directly with NMS 130. In these scenarios, the edge device 150 may provide a proxy through which the NAS device 108 may connect to the NMS 130.

According to one specific implementation, the computing device is part of NMS 130. According to other implementations, NMS 130 may include one or more computing devices, dedicated servers, virtual machines, containers, services, or other forms of environments for performing the techniques described herein. Similarly, the computing resources and components implementing VNA 133 may be part of NMS 130, may execute on other servers or execution environments, or may be distributed to nodes (e.g., routers, switches, controllers, gateways, etc.) within network 134.

In some examples, NMS 130 monitors network data 137 (e.g., one or more service level desire (SLE) metrics) received from each site 102A-102N and manages network resources such as one or more APs 142, switches 146, routers 147, and edge devices 150 at each site to deliver high quality wireless experiences to end users, ioT devices, and clients at that site. In other examples, NMS 130 monitors network data 137 received from NAC system 180 and manages organization-specific configuration information 139 for NAC system 180 to implement unconstrained network access control services with low latency and high availability to client devices 148 at site 102.

As shown in fig. 1B, NMS 130 may include a Virtual Network Assistant (VNA) 133, which virtual network assistant 133 implements an event processing platform for providing real-time insight and simplified fault diagnosis for IT operations, and automatically takes corrective measures or provides advice to proactively solve network problems. For example, VNA 133 may include an event processing platform configured to process hundreds or thousands of concurrent network data flows 137 from sensors and/or agents associated with AP 142, switch 146, router 147, edge device 150, NAC system 180, and/or other nodes within network 134. For example, VNA 133 of NMS 130 may include an underlying analysis and network error identification engine and an alarm system according to various examples described herein. The underlying analysis engine of the VNA 133 may apply historical data and models to the inbound event stream to calculate an assertion of an identified anomaly or predicted occurrence of an event, such as an event that constitutes a network error condition. In addition, VNA 133 may provide real-time alarms and reports to notify a site or network administrator of any predicted events, anomalies, trends via administrator device 111, and may perform root cause analysis and automatic or assisted error remediation. In some examples, VNA 133 of NMS 130 may apply machine learning techniques to identify the root cause of the error condition detected or predicted from network data stream 137. If the root cause can be automatically resolved, the VNA 133 can invoke one or more corrective actions to correct the root cause of the error condition, thereby automatically improving the underlying SLE metrics and also automatically improving the user experience.

Additional example details of operations implemented by VNA 133 of NMS 130 are described in the following patents: U.S. patent nos. 9,832,082, 2021, 9, 30, and 10,958,537, respectively, entitled "network system trouble shooting using machine learning model" (Network System Fault Resolution Using a Machine Learning Model, 2021, 11, 28, and entitled "system for virtual network assistance (Systems and Methods for a Virtual Network Assistant)", 2021, 23, entitled "method and apparatus for facilitating failure detection and/or predictive failure detection (Methods and Apparatus for Facilitating Fault Detection and/or Predictive Fault Detection)", 2021, 23, and entitled "method for spatiotemporal modeling (Method for Spatio-Temporal Modeling)", and 2020, 12, 8, entitled "method for transmitting AP error codes on BLE advertisement (Method for Conveying AP Error Codes Over BLE Advertisements)", 10,862,742, all of which are incorporated herein by reference in their entirety.

In addition, as shown in fig. 1B, NMS 130 may include a NAC controller 138 that implements a NAC configuration platform that provides a user interface to create and assign access policies for client devices 148 of enterprise network 106 and to provide appropriate, organization-specific configuration information 139 to respective NAC systems 180A-180K. NMS 130 may have secure connections 184A through 184K with each of NAC systems 180A through 180K, respectively, such as a RadSec tunnel or another encrypted tunnel. NAC controller 136 can receive network data 137 (e.g., NAC event data) from each of NAC systems 180 over secure connection 184, and each of NAC systems 180 can download appropriate configuration information 139 from NMS 130. In some examples, NAC controller 138 may record or map which enterprise networks are served by which of NAC systems 180. In addition, NAC controller 138 can monitor NAC system 180 to identify failures of the primary NAC system and manage failover to the backup NAC system.

The NAC system 180 provides network access control services in a control plane for one or more NAS devices 108 at the site 102. In operation, NAC system 180 authenticates client device 148 to access enterprise wireless network 106 and can perform fingerprinting to identify client device 148 and apply authorization or access policies to client device 148 based on identity. NAC system 180 includes a plurality of geographically distributed points of presence. For example, NAC system 180A may include a first cloud-based system positioned within a first geographic area (e.g., eastern United states), NAC system 180B (not shown) may include a second cloud-based system positioned within a second geographic area (e.g., western United states), and NAC system 180K may include a kth cloud-based system positioned within a kth geographic area (e.g., china).

Deploying multiple NAC clouds in several geographic regions enables network access control services to be provided to nearby NAS devices with lower latency and high availability while avoiding processing limitations and maintenance issues encountered by local NAC devices. For example, NAS device 108A within enterprise network site 102A may connect to one of the physically closest NAC systems (i.e., NAC system 180A) to experience lower latency for network access control services. In some examples, one of the physically closest NAC systems 180 may include a primary NAC system, and the NAS device may also connect to the next closest NAC system of the NAC system 180 as a backup NAC system when the primary NAC system fails. For example, NAS device 108A within enterprise network site 102A may connect to both NAC system 180A and NAC system 108B (not shown) to experience high availability of network access control services.

In the example shown in FIG. 1B, each of the NAS devices 108 has a secure connection, either directly or indirectly, with at least one of the NAC systems 180. For example, each of the APs 142A within station 120A has a direct secure connection 182A (e.g., radSec tunnel or another encrypted tunnel) to the NAC system 180A. Each of the switch 146A and router 147A within site 120A is indirectly connected to NAC system 180A via edge device 150A. In this example, switch 146A and router 147A may not support establishing a secure connection directly with NAC system 180A, but edge device 150A may provide a proxy through which switch 146A and router 147A may connect to NAC system 180A. For example, each of switch 146A and router 147A has a direct connection 178A (e.g., RADIUS tunnel) to edge device 150A, and edge device 150A has a direct secure connection 182A to NAC system 180A. Similarly, for site 102N, each of nas devices 108N has an indirect connection to NAC system 180K via edge device 150N. In this example, the AP 142N, switch 142N, and router 147N may not support establishing secure connections directly with the NAC system 180K, but the edge device 150N may provide a proxy through which the NAS device 108N may connect to the NAC system 180K. For example, each of the AP 142N, switch 146N, and router 147N has a direct connection 178N (e.g., RADIUS tunnel) to the edge device 150N, and the edge device 150N has a direct secure connection 182N to the NAC system 180K.

Through secure connection 182, NAC system 180 can receive network access requests from client devices 148 through NAS devices 108 (and in some cases edge devices 150) at nearby enterprise sites 102. In response to the network access request, NAC system 180 authenticates the requesting client device using the AAA server. NAC system 180 can perform fingerprinting to identify authenticated client devices. NAC system 180 then enforces the appropriate access policy on the identity of the authenticated client device based on the organization specific configuration information 139 downloaded from NMS 130. According to one particular implementation, the computing device is part of each of the NAC systems 180. According to other implementations, each of NAC systems 180A-180K may include one or more computing devices, dedicated servers, virtual machines, containers, services, or other forms of environments for performing the techniques described herein.

In accordance with one or more techniques of this disclosure, NMS 130 and NAC system 180 implement configuration and application of intent-based NAC policies for authentication and authorization of multi-tenant NAS devices 108 to access enterprise network 106 of an organization. In accordance with the disclosed technology, NAC controller 138 of NMS 130 provides a user interface that implements user input indicating network administrator intent to configure intent-based NAC policies for an organization. In some examples, the organization-specific configuration information 139 may include intent-based NAC policies for one or more organizations. A NAC system (e.g., NAC system 180A) that provides NAC services to an organization may apply an appropriate intent-based NAC policy of the one or more intent-based NAC policies in response to receiving an authentication request from a NAS device (e.g., any of NAS devices 108A at site 102A) to access an enterprise network of the organization (e.g., wireless network 106A at site 102A).

The NAC system 180A automatically identifies the vendor of the NAS device 108A based on the authentication request and also identifies the device type (AP, switch, WLC, firewall, router, etc.) of the NAS device 108A. NAC system 180A matches the incoming attributes in the authentication request with a standardized set of matching rules for the intent-based NAC policy and converts the extracted policy result set corresponding to the standardized set of matching rules in the intent-based NAC policy into a vendor-specific set of return attributes based on the vendor and device type of NAS device 108A. The NAC system 180A then sends the vendor specific set of return attributes to the NAS device 108A to enable the NAS device 108A to access the organization's enterprise network 106A.

Existing solutions are quite primitive, standardizing or simplifying only specific authentication procedures. Furthermore, the deployment paradigm of existing solutions relies on separate policies for authentication and authorization rules, largely on matching specific RADIUS or directory attributes, requiring network administrators to have in-depth engineering knowledge. Furthermore, for each policy configuration, the network administrator even needs to switch between different parts or screens of the user interface platform to create a simple set of policies.

Further, the disclosed techniques enable dynamic vendor learning such that a NAC system (e.g., NAC system 180A) can automatically identify the vendor of NAS device 108 based on an authentication request and vendor signature received from NAS device 108. NAC system 180A can automatically configure a first vendor-specific set of return attributes from an intent-based NAC policy based on a first vendor identified for a first NAS device requesting network access (e.g., APs 142A-1). NAC system 180A can also automatically configure a second vendor-specific set of return attributes from the same intent-based NAC policy based on a second vendor identified for a second NAS device (e.g., switch 146A) requesting network access. The disclosed techniques greatly simplify overall NAC policy configuration and operation, especially in large-scale, multi-provider networks. The technique also reduces the requirements on the network administrator so that no in-depth AAA or NAC product knowledge is required.

Fig. 2 is a block diagram of an example Network Access Control (NAC) system 200 in accordance with one or more techniques of the present disclosure. For example, NAC system 200 can be used to implement any of NAC systems 180 in FIGS. 1A, 1B. In such examples, NAC system 200 is responsible for authenticating and authorizing one or more client devices 148 to access enterprise wireless network 106 at a subset of nearby enterprise sites 102A-102N.

NAC system 200 includes a communication interface 230, one or more processors 206, a user interface 210, memory 212, and database 218. The various elements are coupled together via a bus 214, and the various elements may exchange data and information on the bus 214. In some examples, NAC system 200 receives network access requests from one or more client devices 148 through NAS devices 108 (and in some cases edge devices 150) at a subset of nearby enterprise sites 102 of FIGS. 1A, 1B. In response to the network access request, NAC system 200 authenticates the requesting client device. In some examples, NAC system 200 enforces appropriate access policies on authenticated client devices according to organization-specific configuration information 217 downloaded from NMS 130 of fig. 1A, 1B. In some examples, NAC system 200 may be part of another server shown in fig. 1A, 1B, or part of any other server.

The processor(s) 206 execute software instructions, such as software instructions for defining software or a computer program, stored in a computer-readable storage medium, such as a non-transitory computer-readable medium including a storage device (e.g., a magnetic disk drive or optical disk drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, such as memory 212, that stores instructions that cause the one or more processors 306 to perform the techniques described herein.

Communication interface 230 may include, for example, an ethernet interface. Communication interface 230 couples NAC system 200 to a network and/or the Internet, such as any of networks 134 shown in FIG. 1A and/or any local area network. Communication interface 230 includes a receiver 232 and a transmitter 234, and nac system 200 receives/transmits data and information to/from any of APs 142, switch 146, router 147, edge device 150, NMS 130 or servers 116, 122, 128, and/or any other network node, device, or system forming part of network system 100 via receiver 232 and transmitter 234, as shown in fig. 1A, 1B.

The data and information received by NAC system 200 may include, for example, configuration information 217 associated with one or more organizations or enterprise sites 102 downloaded from NMS 130. Configuration information 217 may include tissue specific NAC configuration information, including access policies and associated policy allocation criteria. For example, the configuration information 217 may define a particular Virtual Local Area Network (VLAN), access Control List (ACL), registration portal, etc. associated with a particular class of client devices. The configuration information 217 may further define different types of tracking, different types of authorization, and/or different levels of access rights for each of the different categories of client devices. In accordance with the disclosed technology, the organization-specific configuration information 217 may include intent-based NAC policies for one or more organizations.

In addition, the data and information received by NAC system 200 can include identification information from client device 148 of NAS device 108 that NAC system 200 uses to perform end user device fingerprinting to enforce the access policies defined in configuration information 217. NAC system 200 may further communicate data and information, including, for example, NAC event data, to NMS130 via communications interface 330, which NMS130 may use to remotely monitor the performance of NAC system 200.

Memory 212 includes one or more devices configured to store programming modules and/or data associated with the operation of NAC system 200. For example, the memory 212 may include a computer-readable storage medium, such as a non-transitory computer-readable medium including a storage device (e.g., a disk drive or optical drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions that cause the one or more processors 206 to perform the techniques described herein.

In this example, memory 212 includes an API 220, an authentication manager 240, a fingerprinting module 242, a policy manager 244, and an NMS connector 250.NAC system 200 may also include any other programming modules, software engines, and/or interfaces configured for authentication and authorization of client device 148.

Authentication manager 240 enables authentication of client devices 148 at NAS device 108 to access wireless networks 106 at a subset of enterprise sites 102 in communication with NAC system 200, such as a branch office or campus enterprise network. Authentication manager 240 may perform the functions of an AAA server (e.g., RADIUS server) or provide access to an AAA server to authenticate client device 148 before providing access to enterprise network 106 via NAS device 108. In some examples, authentication manager 240 may participate in a handshake exchange between the client device, the NAS device, and NAC system 200 controlling access at the NAS device. In other examples, authentication manager 240 may enable certificate-based authentication of a client device or enable interaction with a cloud directory service to authenticate a client device.

The fingerprinting module 242 enables identification of a client device 148 that is used to provide appropriate authorization or access policies to the client device based on the identity or classification of the client device. The fingerprinting module 242 may identify the client device 148 by analyzing the network behavior of the client device. The fingerprinting module 242 may receive network behavior data for client devices from the NAS device 108 and/or edge device 150 in communication with the NAC system 200. For example, fingerprinting module 242 may perform fingerprinting of client device 148 based on one or more of a MAC address, a DHCP option for requesting an IP address, an LLDP packet, user agent information, and/or device type and operating system information.

Policy manager 244 enforces authorization or access policies based on the identity or classification of the client device that implements authentication. For example, policy manager 244 may assign authenticated client devices to certain VLANs, apply certain ACLs, direct client devices to certain registration portals, etc., each of which is associated with a different type of tracking, a different type of authorization, and/or a different level of access rights, based on configuration information 217 of the corresponding enterprise of the client device. In some examples, after the client device gains access to the enterprise network, policy manager 244 may monitor the activity of the client device to identify security issues and, in response, reassign the client device to a quarantine VLAN or another lower-authority VLAN to restrict access by the client device.

As shown in fig. 1B, NMS connector 250 manages data and information exchanged between NAC system 200 and NMS 130, for example, via a RadSec tunnel or another encryption tunnel 184. NMS connector 250 may maintain a log or map of which enterprise networks are served by NAC system 200 and corresponding configuration information 217 for those enterprises. NMS connector 250 may also manage any updates or modifications to configuration information 217 received from NMS 130.

In accordance with one or more techniques of the present disclosure, NAC system 200 is configured to authenticate and authorize NAS devices to access an enterprise network of an organization by applying appropriate intent-based NAC policies of the organization. NMS connector 250 of NAC system 200 obtains from NMS 130 one or more intent-based NAC policies of one or more organizations. For example, NMS connector 250 may download configuration information 217 associated with an organization for which NAC system 200 is providing NAC services, and configuration information 217 may include intent-based NAC policies of the organization. In some examples, in response to receiving an authentication request from a NAS device for an enterprise network of an organization, NMS connector 250 may perform a "lazy download" of configuration information 217 for the organization from NMS 130, configuration information 217 including an intent-based NAC policy. An organization's intent-based NAC policy may include one or more standardized matching rules, and a corresponding set of extraction policy results that are not known to the NAS provider. NMS connector 250 may periodically receive or otherwise obtain updates to the intent-based NAC policy of the organization from NMS 130.

In response to receiving an authentication request from the NAS device for the enterprise network of the organization, the vendor learning module 260 of the NAC system 200 identifies the vendor of the NAS device based on the authentication request. For example, the vendor learning module 260 may match one or more characteristics of the authentication request received from the NAS device with a vendor signature of the vendor of the NAS device included in the vendor signature 219 stored in the database 218. In some examples, the one or more characteristics of the authentication request may include one or more incoming attributes included in the authentication request. For example, the incoming attribute contained in the authentication request may be a vendor specific AAA or RADIUS attribute. In other examples, the incoming attributes contained in the authentication request may conform to a vendor specific format or arrangement. NMS connector 250 may periodically receive or otherwise obtain updates to vendor signature 219 from NMS 130.

NAC policy intent compiler 270 then converts the intent-based NAC policies included in the organization's configuration information 217 based on the identified vendor or NAS device requesting access. In some examples, NAC system 200 also identifies the type of NAS device (e.g., AP, switch, WLC, firewall, router, etc.). NAC policy intent compiler 270 then converts the intent-based NAC policy based on the vendor and device type of the NAS device.

NAC policy intent compiler 270 matches one or more incoming attributes included in an authentication request from a NAS device with a standardized set of matching rules for a particular intent-based NAC policy of the organization's one or more intent-based NAC policies. For example, NAC policy intent compiler 270 can convert one or more standardized sets of matching rules for one or more intent-based NAC policies of an organization into one or more vendor-specific sets of incoming attributes based on the vendor of the NAS device. NAC policy intent compiler 270 can then match one or more incoming attributes included in the authentication request from the NAS device with a vendor-specific set of incoming attributes converted from the standardized set of matching rules for the particular intent-based NAC policy. NAC policy intent compiler 270 also converts the set of extracted policy results corresponding to the standardized set of matching rules for a particular intent-based NAC policy into a vendor-specific set of return attributes based on the vendor of the NAS device.

The standardized set of matching rules for a particular intent-based NAC policy may include both authentication rules and authorization rules standardized to be vendor agnostic. For example, a standardized set of matching rules for a particular intent-based NAC policy may include authentication type, identity provider (e.g., user directory and/or certificate), and group name. In response to a match between one or more incoming attributes included in an authentication request from a NAS device and vendor-specific incoming attributes converted from a standardized set of matching rules for a particular intent-based NAC policy, authentication manager 240 may operate as described above to authenticate the NAS device in accordance with the authentication matching rules for the particular intent-based NAC policy. Further, in response to the matching and authentication of the NAS device, policy manager 244 may operate as described above to authorize the NAS device according to the authorization matching rules and the corresponding policy results of the particular intent-based NAC policy. Policy results may include assigning the VLAN and role of the NAS device.

NAC system 200 sends a vendor-specific set of return attributes converted from policy results of a particular intent-based NAC policy to the NAS device. The return attributes may include at least one vendor specific attribute to specify a VLAN and/or role assigned to the NAS device to enable the NAS device to access the enterprise network of the organization with the appropriate level of access rights.

Continuing the above example, assuming the identified vendor of the NAS device is the first vendor, in response to receiving a second authentication request from the second NAS device for the enterprise network of the organization, the vendor learning module 260 of the NAC system 200 identifies the second vendor of the second NAS device based on the second authentication request. The NAC policy intent compiler 270 matches one or more incoming attributes included in a second authentication request from a second NAS device with a standardized set of matching rules in the same particular intent-based NAC policy. The NAC policy intent compiler 270 then converts the extracted policy result set corresponding to the normalized matching rule set for the particular intent-based NAC policy to a second vendor-specific set of return attributes based on the second vendor of the second NAS device. The NAC system 200 sends a second vendor-specific set of return attributes to the second NAS device to enable the second NAS device to access the enterprise network of the organization at the appropriate access permission level. The disclosed techniques greatly simplify overall NAC policy configuration and greatly improve the operational experience when managing NAC systems, especially in large multi-vendor networks.

Fig. 3 is a block diagram of an example Network Management System (NMS) 300 in accordance with one or more techniques of the present disclosure. NMS300 may be used to implement NMS 130 in fig. 1A, 1B, for example. In such examples, NMS300 is responsible for monitoring and managing one or more wireless networks 106A-106N at sites 102A-102N, respectively.

NMS300 includes a communication interface 330, one or more processors 306, a user interface 310, memory 312, and database 318. The various elements are coupled together via bus 314, which may exchange data and information over bus 214. In some examples, NMS300 receives data from one or more client devices 148, AP 142, switch 146, router 147, edge devices 150, NAC system 180, and other network nodes (e.g., routers and gateway devices) within network 134, which can be used to calculate one or more SLE metrics and/or update network data 316 in database 318. The NMS300 analyzes this data for cloud-based management of the wireless networks 106A through 106N. In some examples, NMS300 may be part of another server shown in fig. 1A, or part of any other server.

The processor(s) 306 execute software instructions, such as software instructions for defining software or a computer program, stored in a computer-readable storage medium, such as a non-transitory computer-readable medium including a storage device (e.g., a magnetic disk drive or optical disk drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions that cause the one or more processors 306 to perform the techniques described herein.

The communication interface 330 may comprise, for example, an ethernet interface. Communication interface 330 couples NMS300 to a network and/or the internet, such as any of network(s) 134 shown in fig. 1A and/or any local area network. Communication interface 330 includes a receiver 332 and a transmitter 334, and nms300 receives/transmits data and information to/from any of client devices 148, AP 142, switch 146, router 147, edge device 150, NAC system 180, servers 116, 122, 128, and/or any other network node, device, or system forming part of network system 100 as shown in fig. 1A via receiver 332 and transmitter 334. In some scenarios where the network system 100 described herein includes a "third party" network device that owns and/or is associated with an entity other than the NMS300, the NMS300 does not directly receive, collect, or access network data from the third party network device. In some examples, an edge device, such as edge device 150 from fig. 1A, 1B, may provide an agent through which network data of a third party network device may be reported to NMS 300.

The data and information received by NMS300 may include, for example, telemetry data, SLE related data, or event data received from one or more client devices AP 148, AP 142, switch 146, router 147, edge device 150, NAC system 180, or other network nodes (e.g., routers and gateway devices) used by NMS300 to remotely monitor the performance of wireless networks 106A-106N and application sessions from client devices to cloud-based application servers. NMS300 may further transmit data to any of the network devices (such as client device 148, AP 142, switch 146, router 147, edge device 150, NAC system 180, or other network nodes within network 134) via communication interface 330 to remotely manage wireless networks 106A-106N and portions of the wired network.

Memory 312 includes one or more devices configured to store programming modules and/or data associated with the operation of NMS 300. For example, the memory 312 may include a computer-readable storage medium, such as a non-transitory computer-readable medium including a storage device (e.g., a disk drive or optical drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause the one or more processors 306 to perform the techniques described herein.

In this example, memory 312 includes an API 320, SLE module 322, virtual Network Assistant (VNA)/AI engine 350, radio Resource Management (RRM) engine 360, and NAC controller 370.NMS 300 may also include any other programming modules, software engines, and/or interfaces configured for remote monitoring and management of wireless networks 106A-106N and portions of the wired network, including remote monitoring and management of any of AP 142, switch 146, router 147, edge device 150, NAC system 180, or other network devices (e.g., routers and gateway devices).

SLE module 322 implements thresholds for setting and tracking SLE metrics for each network 106A-106N. SLE module 322 further analyzes SLE-related data collected by, for example, APs, such as any of APs 142 from UEs in each wireless network 106A-106N. For example, APs 142A-1 through 142A-N collect SLE-related data from UEs 148A-1 through 148A-N currently connected to wireless network 106A. This data is transmitted to NMS 300, which is executed by SLE module 322 to determine one or more SLE metrics for each UE 148A-1 through 148A-N currently connected to wireless network 106A. In addition to any network data collected by one or more APs 142A-1 through 142A-N in wireless network 106A, this data is transmitted to NMS 300 and stored in database 318 as, for example, network data 316.

RRM engine 360 monitors one or more metrics for each site 102A-102N to learn and optimize the RF environment of each site. For example, RRM engine 360 can monitor coverage and capacity SLE metrics for wireless network 106 at sites 102 to identify potential problems with SLE coverage and/or capacity in wireless network 106 and adjust radio settings for access points at each site to address the identified problems. For example, the RRM engine may determine the channel and transmission power distribution across all APs 142 in each network 106A-106N. For example, RRM engine 360 may monitor events, power, channels, bandwidth, and the number of clients connected to each AP. RRM engine 360 may further automatically change or update the configuration of one or more APs 142 at station 102 in order to improve coverage and capacity SLE metrics and thereby provide an improved wireless experience for the user.

The VNA/AI engine 350 analyzes data received from the network devices as well as its own data to identify when an unexpected abnormal state is encountered at one of the network devices. For example, the VNA/AI engine 350 can identify the root cause of any undesired or abnormal state, e.g., any bad SLE metric(s) indicative of connectivity problems at one or more network devices. Further, the VNA/AI engine 350 can automatically invoke one or more corrective actions directed to resolving the identified root cause(s) of the one or more bad SLE metrics. In some examples, ML model 380 may include a supervised ML model trained using training data including pre-collected tagged network data received from network devices. The supervised ML model may include one of logistic regression, naive bayes, support Vector Machines (SVMs), etc. In other examples, ML model 380 may include an unsupervised ML model. Although not shown in fig. 3, in some examples, database 318 may store training data and VNA/AI engine 350 or a dedicated training module may be configured to train ML model 380 based on the training data to determine appropriate weights across one or more features of the training data.

Examples of corrective actions that may be automatically invoked by VNA/AI engine 350 may include, but are not limited to, invoking RRM 360 to restart one or more APs, adjusting/modifying the transmit power of a particular radio in a particular AP, adding an SSID configuration to a particular AP, changing channels on an AP or set of APs, and so forth. Corrective actions may also include restarting the switch and/or router, invoking a download of new software to the AP, the switch or router, and so forth. These corrective actions are given for illustrative purposes only and the disclosure is not limited in this respect. If automatic corrective action is not available or is insufficient to address the root cause, the VNA/AI engine 350 can proactively provide notifications that include recommended corrective actions to be taken by IT personnel (e.g., a site or network administrator using the administrator device 111) to address the network error.

NAC controller 370 implements a NAC configuration platform that provides a user interface 310 (e.g., via administrator device 111 of FIG. 1A) displayed to an enterprise network administrator through which access policy information for the enterprise network is received via user interface 310. NAC controller 370 creates tissue-specific configuration information 317 stored in database 318 based on input received via user interface 310. Configuration information 317 may include NAC configuration information for each of one or more enterprise networks managed by NMS 300. Configuration information 317 may include, for each enterprise, access policies and associated policy allocation criteria. For example, the configuration information 317 may define a particular VLAN, ACL, registration portal, etc. associated with a particular class of client device, and may further define different types of tracking, different types of authorization, and/or different levels of access rights for each of the different classes of client devices. In accordance with the disclosed technology, the organization-specific configuration information 317 may include intent-based NAC policies for one or more organizations. Configuration information 317 may be substantially similar to configuration information 139 of fig. 1B.

As shown in fig. 1B, NAC controller 370 manages data and information exchanged between NMS 300 and NAC system 180 (e.g., via a RadSec tunnel or another encryption tunnel 184). NAC controller 370 may maintain a log or map of which enterprise networks are served by which NAC systems 180, as well as corresponding configuration information 317 for those enterprises. NAC controller 370 may also manage any updates or modifications to configuration information 317 to push down to NAC system 180. In addition, NAC controller 370 can monitor NAC system 180 to identify failures of the primary NAC system and manage failover to the backup NAC system.

In accordance with one or more techniques of this disclosure, NAC controller 370 is configured to provide user interface 310 to enable configuration of an intent-based NAC policy for one or more organizations based on user input indicative of network administrator intent. One or more organizations' intent-based NAC policies may be included in configuration information 317, which may be used to download or otherwise be pushed down to NAC system 180. The intent-based NAC policy includes one or more standardized sets of matching rules, and a corresponding set of extraction policy results that are not known to the NAS provider. NAC controller 370 may periodically update the intent-based NAC policy included in configuration information 317.

To configure an organization's intent-based NAC policy based on network administrator intent, NAC controller 370 may receive data from administrator device 111 via user interface 310 indicating a selection of one or more labels representing the organization's authentication rules. Authentication rules may include authentication types and identity providers. NAC controller 370 may also receive data from administrator device 111 via user interface 310 indicating a selection of one or more labels representing authorization rules for an organization. Authorization rules may include group names, VLANs, and roles. NAC controller 370 can then configure one or more standardized sets of matching rules for one or more intent-based NAC policies of the organization based on the selected one or more labels representing authentication rules of the organization and the group names of authorization rules from the organization. Further, for each of the one or more standardized sets of matching rules, NAC controller 370 may configure a corresponding set of one or more extracted policy result sets of one or more intent-based NAC policies of the organization based on one or more tags representing VLANs and roles selected from the authorization rules of the organization.

The intent-based NAC policy configuration provided by NAC controller 370 hides the configuration complexity associated with conventional NAC systems from administrators and other end users, reducing network administrator requirements so that no in-depth AAA or NAC product knowledge is required.

For example, assume that an organization's network administrator needs to create two policies to allow wireless users to authenticate with EAP-TLS and assign specific VLAN and network policy roles based on user group membership in the user directory, and further assume that there are two user groups: employees and contractors. For this example, it is also assumed that an organization owns multi-vendor wireless networks from two different vendors.

An example of a conventional NAC policy configuration may be as follows:

1. an authentication policy specifying the type of authentication (e.g., 802.1X using EAP-TLS) is created and instructed to look up a particular user directory.

2. An authorization policy is created specifying which AAA attributes (i.e., VLAN IDs and network policy roles) need to be sent back to the NAS for each user group.

3. The two steps above are repeated for each new vendor NAS, as both the inbound and return attributes may be different across vendors.

Fig. 6 depicts in more detail the workflow of a conventional NAC policy configuration procedure for two different NAS providers.

The disclosed technology provides a more elegant and simplified configuration process while maintaining flexibility and achieving the same network administrator intent. In accordance with the disclosed technology, an example intent-based NAC policy configuration may be as follows:

1. authentication rules and authorization rules are extracted from the administrator. The disclosed techniques combine or collapse multiple configuration phases (i.e., authentication policy configuration and authorization policy configuration) into a single configuration phase.

2. The administrator simply selects the matching criteria and policy results via the user interface.

3. For both matching conditions and policy results, the user interface provides a reusable tab that specifies only the administrator's intent. In response to an authentication request from the NAS device, the NAC system converts the intent into an incoming or return set of attributes based on the vendor and device type of the NAS device.

Fig. 7 illustrates a more detailed depiction of the workflow disclosed herein for an intent-based NAC policy configuration process.

Although the techniques of this disclosure are described in this example as being performed by NMS 130, the techniques described herein may be performed by any other computing device(s), system(s), and/or server(s), and the disclosure is not limited in this respect. For example, one or more computing devices configured to perform the functionality of the techniques of this disclosure may reside in a dedicated server, or be contained in any other server other than NMS 130, or may be distributed throughout network 100, and may or may not form part of NMS 130.

Fig. 4 is a block diagram of an example Access Point (AP) device 400 in accordance with one or more techniques of this disclosure. The example access point 400 shown in fig. 4 may be used to implement any of the APs 142 shown and described herein with reference to fig. 1A. The access point 400 may comprise, for example, a Wi-Fi, bluetooth, and/or Bluetooth Low Energy (BLE) base station, or any other type of wireless access point.

In the example of fig. 4, access point 400 includes a wired interface 430, wireless interfaces 420A-420B, one or more processors 406, memory 412, and input/output 410 coupled together via bus 414, various elements may exchange data and information over bus 414. The wired interface 430 represents a physical network interface and includes a receiver 432 and a transmitter 434 for transmitting and receiving network communications (e.g., packets). The wired interface 430 couples the access point 400 directly or indirectly to a wired network device, such as one of the switch 146 or router 147 in fig. 1A, 1B, via a cable, such as an ethernet cable.

First wireless interface 420A and second wireless interface 420B represent wireless network interfaces and include receivers 422A and 422B, respectively, each of which includes a receive antenna via which access point 400 may receive wireless signals from a wireless communication device, such as UE148 of fig. 1A, 1B. First wireless interface 420A and second wireless interface 420B also include transmitters 424A and 424B, respectively, each including a transmit antenna via which access point 400 may transmit wireless signals to a wireless communication device, such as UE148 of fig. 1A, 1B. In some examples, the first wireless interface 420A may include a Wi-fi802.11 interface (e.g., 2.4GHz and/or 5 GHz), and the second wireless interface 420B may include a bluetooth interface and/or a Bluetooth Low Energy (BLE) interface. As described above, AP 400 may request network access for one or more UEs 148 from a nearby NAC system, such as NAC system 200 of fig. 2 or one of NAC systems 180 of fig. 1A, 1B.

The processor(s) 406 are programmable hardware-based processors configured to execute software instructions stored in a computer-readable storage medium (such as memory 412), such as software instructions for defining software or a computer program, such as a non-transitory computer-readable medium including a storage device (e.g., a magnetic disk drive or optical disk drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions that cause the one or more processors 406 to perform the techniques described herein.

Memory 412 includes one or more devices configured to store programming modules and/or data associated with the operation of access point 400. For example, the memory 412 may include a computer-readable storage medium, such as a non-transitory computer-readable medium, including a storage device (e.g., a disk drive or optical drive) or memory (such as flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause the one or more processors 406 to perform the techniques described herein.

In this example, memory 412 stores executable software including an Application Programming Interface (API) 440, a communication manager 442, configuration settings 450, a device status log 452, a data store 454, and a log controller 455. The device status log 452 includes a list of events specific to the access point 400. The events may include logs of both normal events and error events, such as memory state, restart or restart events, crash events, cloud disconnect with self-recovery events, low link speed or link speed swing events, ethernet port states, ethernet interface packet errors, upgrade failure events, firmware upgrade events, configuration changes, etc., as well as time and date stamps for each event. The log controller 455 determines the logging level for the device based on the instruction from the NMS 130. Data 454 may store any data used and/or generated by access point 400, including data collected from UE 148, such as data used to calculate one or more SLE metrics, transmitted by access point 400 for cloud-based management of wireless network 106A by NMS 130/300.

Input/output (I/O) 410 represents physical hardware components capable of interacting with a user, such as buttons, displays, and the like. Although not shown, memory 412 typically stores executable software for controlling a user interface with respect to inputs received via I/O410. Communication manager 442 includes program code that, when executed by processor(s) 406, allows access point 400 to communicate with UE 148 and/or network(s) 134 via interface(s) 430 and/or any of 420A-420C. Configuration settings 450 include any device settings for access point 400, such as radio settings for each of wireless interface(s) 420A-420C. These settings may be manually configured or may be remotely monitored and managed by NMS 130 to periodically (e.g., hourly or daily) optimize wireless network performance.

As described herein, AP device 400 may measure network data from status log 452 and report the network data to NMS 130. Network data can include event data, telemetry data, and/or other SLE related data. The network data may include various parameters that indicate the performance and/or status of the wireless network. These parameters may be measured and/or determined by one or more UE devices and/or one or more APs in the wireless network. NMS 130/300 may determine one or more SLE metrics based on SLE related data received from APs in the wireless network and store the SLE metrics as network data 137 (fig. 1B).

Fig. 5 is a block diagram illustrating an example edge device 500 in accordance with one or more techniques of this disclosure. The edge device 500 includes a cloud managed wireless Local Area Network (LAN) controller. The edge device 500 may be used to implement any of the edge devices 150 of fig. 1A, 1B, for example. In such examples, edge device 500 comprises a local device at site 102 that communicates with NMS 130 and one or more local NAS devices 108 (e.g., one or more APs 142, switches 146, or routers 147 from fig. 1A, 1B). The edge device 500 with NMS 130 may operate to extend some micro services from NMS 130 to local NAS device 108 while using NMS 130 and its distributed software architecture for scalable and resilient operation, management, troubleshooting, and analysis.

In this example, the edge device 500 includes a wired interface 502 (e.g., an ethernet interface), a processor 506, input/output 508 (e.g., display, buttons, keyboard, keypad, touch screen, mouse, etc.), and memory 512 coupled together via a bus 514, via which various elements can exchange data and information. The wired interface 502 couples the edge device 500 to a network, such as the network 134 shown in fig. 1A and/or any local area network. Wired interface 502 includes a receiver 520 and a transmitter 522, and edge device 500 receives data and information from, or transmits data and information to, either NAS device 108 and 130 and/or NAC system 180 via receiver 520 and transmitter 522, either NAS device 108 and 130 and/or NAC system 180. Although only one interface is shown by way of example, the edge device 500 may have multiple communication interfaces and/or multiple communication interface ports.

Memory 512 stores executable software applications 532, operating system 540, and data/information 530. The data 530 may include a system log and/or an error log storing event data (including behavior data) for the edge device 500. Tunnel service 544 provides local tunnel termination from APs and other NAS devices. Tunnel service 544 also provides secure tunnel agents to NMS 130 and/or NAC system 180. In one scenario, one or more NAS devices 108 (e.g., switch 146A in fig. 1B) may not support establishing RadSec tunnels directly with NMS 130 and/or NAC system 180. In this scenario, tunnel service 544 of edge device 500 provides a RadSec proxy to enable RADIUS packets received from switch 146A via RADIUS tunnel 178A to be tunneled to NAC system 180A using RadSec tunnel 182A, as shown in fig. 1B.

Fig. 6 is a conceptual diagram illustrating a general NAC policy configuration procedure for two different NAS providers. More particularly, fig. 6 illustrates a NAC policy configuration procedure 610A for NAS provider a and a NAC policy configuration procedure 610B for NAS provider B.

In process 610A, an administrator: (1) defining a policy set for NAS provider a, (2) specifying an authentication type, an authentication protocol, and authentication matching criteria for the NAS provider, (3) defining an authentication policy 620A based on the authentication matching criteria, and (4) specifying an identity provider, (5) defining an authorization policy 622A comprising (6) a first authorization matching criteria specifying a user group = employee and (7) a second authorization matching criteria specifying a user group = contractor, and (8) defining a vendor specific return attribute 624A for each of the authorization policies. For example, in process 610A, for a first authorization matching criteria of user group = employee, the administrator defines VLAN attribute of provider a as Tunnel-Private-GroupId = 100 and role attribute of provider a as Filter-Id = employee. As another example, in process 610A, for a second authorization matching criteria of user group = contractor, the administrator defines VLAN attribute of vendor a as Tunnel-Private-GroupId = 200 and role attribute of vendor a as Filter-Id = contractor.

In process 610B, the administrator: (1) defining a policy group for NAS provider B, (2) specifying an authentication type, an authentication protocol, and authentication matching criteria for the NAS provider, (3) defining an authentication policy 620B based on the authentication matching criteria, and (4) specifying an identity provider, (5) defining an authorization policy 622B comprising (6) a first authorization matching criteria specifying a user group = employee, and (7) a second authorization matching criteria specifying a user group = contractor, and (8) defining vendor specific return attributes 624A for each of the authorization policies. For example, in process 610B, for a first authorization match criteria of user group = employee, the administrator defines VLAN attribute of vendor B as Airespace-Interface-Name = employee and role attribute of vendor B as Airespace-ACL-Name = employee. As another example, in process 610B, for a second authorization matching criteria of user group = contractor, the administrator defines VLAN attribute of vendor B as airgap-Interface-Name = contractor and role attribute of vendor B as airgap-ACL-Name = contractor.

Fig. 7 is a conceptual diagram illustrating an intent-based NAC policy configuration process in accordance with one or more techniques of the present disclosure. More particularly, fig. 7 illustrates a vendor agnostic intent-based NAC policy configuration process 710.

In process 710, an administrator selects matching rules 720, including authentication matching rules (e.g., authentication type and authentication protocol) and authorization matching rules (e.g., user group name). In the illustrated example, the matching rules 720 include a first set of matching rules that includes an authentication type, an authentication protocol, and a group of: employee, and a second set of matching rules, authentication type, authentication protocol, and group: contractors. In process 710, for each set of matching rules, the administrator selects a policy result 724 that includes a VLAN and a network policy role. In the illustrated example, policy results 724 include a first set of policy results corresponding to a first set of matching rules including employee VLANs and employee roles, and a second set of policy results corresponding to a second set of matching rules including contractor VLANs and contractor roles.

In some examples, an administrator may select matching rules 720 and corresponding policy results 724 using tags predefined or created via a user interface provided by NMS 130/300. The NMS 130/300 normalizes the matching rules 720 across different NAS providers and different NAS device types. The NAC system 180/200 can automatically select an identity provider or user director based on the incoming authenticated user domain (e.g., domain name) of the NAS device requesting authentication. NMS 130/300 extracts policy results 724 so that the administrator need only select a VLAN ID/name or role name via the user interface. The NAC system 180/200 automatically replaces policy results 724 with a vendor specific set of return attributes based on the NAS vendor and the NAS device type of the NAS device requesting authentication.

Fig. 8 illustrates an example user interface provided by NMS 130/300 for display on administrator device 111 that implements label-based configuration of intent-based NAC policies in accordance with the techniques of this disclosure. Fig. 8 illustrates an intent-based policy User Interface (UI) 800 that presents a list of organized intent-based NAC policies, the standardized set of matching rules or matching criteria 820 on the left side of the UI 800 and the corresponding set of extracted policy results or allocation policies 824 on the right side of the UI 800.

In the illustrated example, the matching rules or criteria 820 for each of the intent-based NAC policies include one or more tags (such as authentication type or identity provider) that represent the organization's authentication policy rules, and/or the group name of the organization's authorization policy rules. For example, for some intent-based NAC policies, the tags included in the matching rules or matching criteria 820 represent authentication types (e.g., wireless 802.1X, wired, EAP-TLS, EAP-TTLS, MAB, certificates) and/or authorization groups (e.g., printers, employees, contractors). Policy results or allocation policies 824 for each of the intent-based NAC policies include one or more labels that represent the roles of the authorization policy rules for the VLAN and/or organization. For example, for some intent-based NAC policies, the labels included in policy results or assigned policies 824 represent VLANs (e.g., employee VLAN, contractor VLAN, unlimited VLAN, ioT tunnel VLAN, VLAN with web page filtering) and/or roles (e.g., employee role, contractor role, VIP role).

To configure a new intent-based NAC policy, a network administrator using administrator device 111 may select "Add rules" button 826. NMS 130/300 may then receive data indicative of the selection of one or more labels representing one or more authentication policy rules (such as authentication type and/or identity provider) for the new intent-based NAC policy, and data indicative of the selection of one or more labels representing one or more authorization policy rules (such as group name, VLAN, and/or role) for the new intent-based NAC policy, via UI 800 or another user interface. Upon receipt of the selected label, NMS 130/300 may configure a new standardized set of matching rules or matching criteria 820 for the intent-based NAC policy based on the selected label representing the group name of the authentication policy rule and/or authorization policy rule. The NMS 130/300 then configures a corresponding set of extraction policy results or allocation policies 824 for the new intent-based NAC policy based on the selected tags representing the roles of the VLAN and/or authorization policy rules for the standardized set of matching rules.

Fig. 9A and 9B illustrate example user interfaces provided by NMS 130/300 for display on administrator device 111 to implement configuration of new labels, including selecting a label type for a new label and selecting a label value for a new label, in accordance with the techniques of this disclosure. The new label may be used to select via the intent-based policy UI 800 of fig. 8 for inclusion in a set of matching rules or policy results for the intent-based NAC policy.

FIG. 9A illustrates a new tab User Interface (UI) 900A with a tab type area 910, the tab type area 910 illustrating an extended drop-down list of tab type selection options for the new tab. In the example of fig. 9A, the tag type selection options include AAA attributes, certificate attributes, client list, directory attributes, SSID.

Fig. 9B illustrates a new tag UI 900B in which a tag type field 910 indicates a selected tag type "AAA attribute", and a tag value field 915 illustrates an extended drop-down list of tag value selection options for the new tag. In the example of fig. 9B, tag type selection options for the AAA attribute tag type include role, VLAN, realm, username. In some examples, tag value field 915 includes a fillable field to receive the selected tag type and the actual value of the selected tag value.

It presents a list of the organizational intent-based NAC policies, on the left side of the UI 800 is a standardized set of matching rules or matching criteria 820, and on the right side of the UI 800 is a corresponding set of extraction policy results or allocation policies 824.

Fig. 10 is a flowchart illustrating example operations of an application of applying an intent-based NAC policy in response to receiving an authentication request from a NAS device in accordance with one or more techniques of the present disclosure. The example operations of fig. 10 are described herein with respect to NAC system 200 of fig. 2 and NMS 300 of fig. 3. In other examples, the operations of fig. 10 may be performed by other computing systems or devices configured (such as NAC system 180 and NMS 130 from fig. 1A-1B).

NAC system 200 obtains from NMS 300 one or more intent-based NAC policies of one of the one or more organizations, wherein the one or more intent-based NAC policies include a standardized set of matching rules and a corresponding set of extraction policy results that are agnostic to the vendor (1002). NMS 300 generates data representing user interface 310 for display on manager device 111 and configures one or more intent-based NAC policies of the organization based on data received from manager device 111 via user interface 310. NAC system 200 obtains configuration information 317 for the organization from NMS 300 in response to receiving an authentication request from the NAS device for the enterprise network of the organization, wherein configuration information 317 for the organization includes one or more intent-based NAC policies of the organization.

NAC system 200 receives an authentication request from a NAS device for an enterprise network of an organization (1004). The NAC system 200 identifies the vendor of the NAS device based on the authentication request (1006). For example, the NAC system 200 can match one or more characteristics of an authentication request received from a NAS device with a vendor signature of a vendor of the NAS device included in a database of vendor signatures 219 stored at the NAC system 200, where the one or more characteristics of the authentication request include at least one or more incoming attributes.

NAC system 200 matches (1008) one or more incoming attributes included in an authentication request from a NAS device with a standardized set of matching rules for one or more intent-based NAC policies. For example, NAC system 200 can convert one or more standardized sets of matching rules for one or more intent-based NAC policies of an organization to one or more vendor-specific sets of incoming attributes based on a vendor of the NAS device and match one or more incoming attributes included in an authentication request from the NAS device to the vendor-specific sets of incoming attributes converted from the standardized sets of matching rules for intent-based NAC policies of the one or more intent-based NAC policies. NAC system 200 converts the set of extracted policy results corresponding to the standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes based on the vendor of the NAS device (1010). The NAC system 200 sends a vendor specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization (1012).

The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof. The various features described as modules, units, or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices or other hardware devices. In some cases, various features of the electronic circuit may be implemented as one or more integrated circuit devices, such as an integrated circuit chip or chipset.

If implemented in hardware, the present disclosure may be directed to an apparatus such as a processor or an integrated circuit device (such as an integrated circuit chip or chipset). Alternatively or additionally, if implemented in software or firmware, the techniques may be implemented at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, a computer-readable data storage medium may store such instructions for execution by a processor.

The computer readable medium may form part of a computer program product, which may include packaging material. The computer-readable medium may include computer data storage media such as Random Access Memory (RAM), read Only Memory (ROM), non-volatile random access memory (NVRAM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, magnetic or optical data storage media, and the like. In some examples, an article of manufacture may comprise one or more computer-readable storage media.

In some examples, the computer-readable storage medium may include a non-transitory medium. The term "non-transitory" may indicate that the storage medium is not implemented in a carrier wave or propagated signal. In some examples, a non-transitory storage medium may store data (e.g., in RAM or cache) that may change over time.

The code or instructions may be software and/or firmware executed by a processing circuit comprising one or more processors, such as one or more Digital Signal Processors (DSPs), general purpose microprocessors, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the foregoing structure or any other structure suitable for use in implementing the techniques described herein. Furthermore, in some aspects, the functionality described in this disclosure may be provided within software modules or hardware modules.

Claims

1. A system, comprising:

a network management system, NMS, configured to manage a plurality of multi-vendor network access server, NAS, devices associated with one or more organizations; and

at least one cloud-based network access control, NAC, system in communication with the NMS, wherein the at least one NAC system is configured to:

obtaining, from the NMS, one or more intent-based NAC policies of an organization of the one or more organizations, wherein the one or more intent-based NAC policies include one or more standardized sets of matching rules associated with corresponding sets of extraction policy results that are agnostic to a vendor;

Receiving an authentication request from the NAS device for the enterprise network of the organization;

identifying a vendor of the NAS device based on the authentication request;

matching one or more incoming attributes included in the authentication request from the NAS device with a standardized set of matching rules for an intent-based NAC policy of the one or more intent-based NAC policies;

converting, based on the vendor of the NAS device, a set of extraction policy results corresponding to the standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes; and

the vendor-specific set of return attributes is sent to the NAS device to enable the NAS device to access the enterprise network of the organization.

2. The system of claim 1, wherein the standardized set of matching rules for the intent-based NAC policy includes both authentication rules and authorization rules standardized to be vendor agnostic.

3. The system of claim 1, wherein the set of vendor-specific return attributes comprises at least one vendor-specific attribute of the vendor of the NAS device.

4. The system of claim 1, wherein the at least one NAC system is configured to:

identifying a type of the NAS device based on the one or more incoming attributes included in the authentication request; and

the set of extraction policy results is converted to the set of vendor-specific return attributes based on the vendor of the NAS device and the type of the NAS device.

5. The system of claim 1, wherein to identify the vendor of the NAS device based on the authentication request, the at least one NAC system is configured to match one or more characteristics of the authentication request received from the NAS device with a vendor signature of the vendor of the NAS device included in a vendor signature database stored at the at least one NAC system, wherein the one or more characteristics of the authentication request include at least the one or more incoming attributes.

6. The system according to claim 5, wherein the NMS is configured to periodically update vendor signatures included in the vendor signature database at the at least one NAC system.

7. The system of any of claims 1 to 6, wherein to match the one or more incoming attributes to the standardized set of matching rules of the intent-based NAC policy, the at least one NAC system is configured to:

converting the one or more standardized set of matching rules of the one or more intent-based NAC policies of the organization into one or more vendor-specific sets of incoming attributes based on the vendor of the NAS device; and

the one or more incoming attributes included in the authentication request from the NAS device are matched with a vendor-specific set of incoming attributes converted from the standardized set of matching rules of the intent-based NAC policy of the one or more intent-based NAC policies.

8. The system of claim 1, wherein the vendor of the NAS device comprises a first vendor, and wherein the at least one NAC system is configured to:

receiving a second authentication request for the enterprise network of the organization from a second NAS device;

identifying a second vendor of the second NAS device based on the second authentication request, wherein the second vendor is different from the first vendor;

Matching one or more incoming attributes included in the second authentication request from the second NAS device with the standardized set of matching rules in the same intent-based NAC policy of the one or more NAC policies;

converting, based on the second vendor of the second NAS device, a set of extraction policy results corresponding to the standardized set of matching rules for the intent-based NAC policy into a second set of vendor-specific return attributes; and

the second vendor-specific set of return attributes is sent to the second NAS device to enable the second NAS device to access the enterprise network of the organization.

9. The system of claim 1, wherein the NMS is configured to:

generating a data representation of a user interface for display on a computing device of a network administrator of the enterprise network of the organization; and

the one or more intent-based NAC policies of the organization are configured based on data received from the computing device via the user interface.

10. The system of claim 9, wherein to configure the one or more intent-based NAC policies of the organization, the NMS is further configured to:

Receiving, via the user interface, a selected data indication of one or more tag representations of authentication rules of the organization from the computing device, the authentication rules including an authentication type and an identity provider;

receiving, via the user interface, a selected data indication of one or more tag representations of authorization rules of the organization from the computing device, the authorization rules including a group name, a virtual local area network VLAN, and a role;

configuring the one or more standardized set of matching rules for the one or more intent-based NAC policies of the organization based on the selected one or more label representations of the authentication rules of the organization and the set of names of the authorization rules from the organization; and

for each of the one or more standardized sets of matching rules, configuring a corresponding set of the one or more extracted policy result sets of the one or more intent-based NAC policies of the organization based on the selected one or more tag representations of the VLAN and role of the authorization rule from the organization.

11. The system according to any of claims 1, 9 or 10, wherein to obtain the one or more intent-based NAC policies of the organization from the NMS, the at least one NAC system is configured to obtain configuration information for the organization from the NMS in response to receiving the authentication request for the enterprise network of the organization from the NAS device, wherein the configuration information for the organization includes the one or more intent-based NAC policies of the organization.

12. The system of claim 1, wherein the NMS is configured to periodically update the one or more intent-based NAC policies of the organization at the at least one NAC system.

13. A method, comprising:

obtaining, by a cloud-based network access control, NAC, system from a network management system, NMS, one or more intent-based NAC policies of an organization, the NMS configured to manage a plurality of multi-vendor network access server, NAS, devices associated with the organization, wherein the one or more intent-based NAC policies comprise one or more standardized sets of matching rules associated with corresponding sets of extraction policy results that are agnostic to a vendor;

receiving, by the NAC system, an authentication request from a NAS device for an enterprise network of the organization;

identifying, by the NAC system, a vendor of the NAS device based on the authentication request;

matching, by the NAC system, one or more incoming attributes included in the authentication request from the NAS device to a standardized set of matching rules for an intent-based NAC policy of the one or more intent-based NAC policies;

converting, by the NAC system, a set of extracted policy results corresponding to the standardized set of matching rules for the intent-based NAC policy into a set of vendor-specific return attributes based on the vendor of the NAS device; and

The vendor-specific set of return attributes is sent by the NAC system to the NAS device to enable the NAS device to access the enterprise network of the organization.

14. The method of claim 13, further comprising identifying a type of the NAS device based on the one or more incoming attributes included in the authentication request, wherein converting the set of extraction policy results comprises converting the set of extraction policy results to the set of vendor-specific return attributes based on the vendor of the NAS device and the type of the NAS device.

15. The method of claim 13, wherein identifying the vendor of the NAS device based on the authentication request comprises matching one or more characteristics of the authentication request received from the NAS device with a vendor signature of the vendor of the NAS device included in a vendor signature database stored at the at least one NAC system, wherein the one or more characteristics of the authentication request include at least the one or more incoming attributes.

16. The method of any of claims 13-15, wherein matching the one or more incoming attributes to the standardized set of matching rules for the intent-based NAC policy comprises:

17. The method of claim 13, further comprising:

generating, by the NMS, a data representation of a user interface for display on a computing device of a network administrator of the enterprise network of the organization; and

configuring, by the NMS, the one or more intent-based NAC policies of the organization based on data received from the computing device via the user interface.

18. The method of claim 17, wherein configuring the one or more intent-based NAC policies of the organization comprises:

19. The method according to any of claims 13, 17 or 18, wherein obtaining the one or more intent-based NAC policies of the organization from the NMS comprises obtaining configuration information for the organization from the NMS in response to receiving the authentication request for the enterprise network of the organization from the NAS device, wherein the configuration information for the organization comprises the one or more intent-based NAC policies of the organization.

20. A computer-readable storage medium storing instructions that, when executed, cause one or more processors to:

identifying a vendor of the NAS device based on the authentication request;