Access Control Engine Settings

Engine settings provide advanced configuration options for ExtremeControl engines. ExtremeCloud IQ Site Engine comes with a default engine settings configuration. If desired, you can edit these default settings or you can define your own settings to use for your ExtremeControl engines.

Launch the Engine Settings window by selecting the Control > Access Control tab, expanding the Engines left-panel menu, selecting an ExtremeControl engine, and selecting the Engine Settings button. The Engine Settings window contains the following tabs available for configuration:

Credentials
Network Settings
Device Type Detection
IP Address Resolution
Hostname Resolution
Username Resolution
Reauthentication
Miscellaneous
Auditing

	NOTE:	To access status and diagnostic information for an ExtremeControl engine, launch the ExtremeControl Engine administration web page by right-clicking on the ExtremeControl engine in the left-panel tree and selecting WebView. You can also access the administration web page using the following URL: https://<ExtremeControlEngineIP>:8444/Admin. The default user name and password for access to this web page is "admin/Extreme@pp." The username and password can be changed in the Web Service Credentials field on the Credentials Tab in the Engine Setting window.

Credentials

Use this tab to configure various parameters for your network engines including switch configuration, web service credentials, and EAP-TLS configuration.

Switch Configuration

Enter the shared secret that switches uses when communicating with ExtremeControl engines.

Shared Secret: A string of alpha-numeric characters used to encrypt and decrypt communications between the switch and the ExtremeControl engine. The shared secret is shown as a string of asterisks. Select the Eye icon to reveal the Shared Secret.

RADIUS Timeout

The amount of time (in seconds) that a switch waits before re-sending a RADIUS request to the ExtremeControl engine. The default is 15 seconds and the maximum is 60 seconds. Note that the time specified should be long enough to allow the ExtremeControl engine to receive a response from the RADIUS server.

NOTE:

Although this option allows a maximum of 60 seconds, the actual maximum time allowed varies depending on the switch model. If a switch does not support the timeout value specified here, then the value is not set on the switch and an error message displays in the ExtremeControlengine log. Check your switch documentation to verify supported values.

RADIUS Timeout Retry Count: The number of times the switch attempts to contact an ExtremeControl engine with a RADIUS request, when an attempted contact fails. The default setting is 3 retries, which means that the switch retries a timed-out request three times, making a total of four attempts to contact the engine.

Use Primary RADIUS Server for Redundancy in Single Engine Configuration: If your ExtremeControl deployment has only one ExtremeControl Gateway engine, this option allows you to configure redundancy by using the primary RADIUS server as a backup when configuring the switches. This option would not apply to ExtremeControl deployments using advanced AAA configurations with more than one set of RADIUS servers, or if you have configured primary and secondary ExtremeControl Gateways.

SNMP Timeout

The amount of time (in seconds) that ExtremeCloud IQ Site Engine waits before re-trying to contact the ExtremeControl engine. The value for this setting must be between 1 and 60.

NOTE:

When SNMP requests are redirected through the server, all SNMP timeouts are extended by a factor of four (timeout X 4) to allow for the delays incurred by redirecting requests through the server.

Admin Web Page Credentials

ExtremeControl Engine Web Service Credentials

The credentials specified here provide access to the ExtremeControl engine administration web page and the web services interface between the ExtremeCloud IQ Site Engine server and the ExtremeControlengine. ExtremeCloud IQ Site Engine provides default credentials that can be changed, if desired. Changes to the credentials are propagated to the ExtremeControl engines on Enforce.

NOTE:

The Web service credentials are used to communicate between ExtremeCloud IQ Site Engine and ExtremeControl Engine. If you use non-default credentials and add a new ExtremeControl Engine, then you must pre-provision the new ExtremeControl Engine with the new credentials manually by running /opt/nac/configWebCredentials <username> <password>.

Admin Web Page Authentication

By default, the ExtremeControl engine administration web page (https://<ExtremeControlEngineIP>:8444/Admin/) uses the above Web Service Credentials for authentication. However, you can configure the web page to use the AAA Configuration assigned to that engine for authentication as well. This allows you to use LDAP or RADIUS authentication for the web page.

There are three steps for setting up the web page to use LDAP or RADIUS authentication:

Verify that the ExtremeControl Configuration assigned to the engine has LDAP or RADIUS authentication configured in its AAA Configuration.
Create a local user account on the ExtremeControl engine that matches the user name of the user logging in. Use the useradd command on the ExtremeControl engine CLI to create the local user account.
Select the Use ExtremeControl AAA Configuration for Admin Web Page authentication option here on the Credentials tab. Select OK. Enforce the change to the engine.

The ExtremeControl engine begins using the AAA configuration for the administration web page authentication. Note that it may take the Linux operating system on the ExtremeControl engine up to two minutes to recognize that the new user is valid.

EAP-TLS Configuration

Server Private Key Passphrase: The Server Private Key Passphrase is used to encrypt the private key created during certificate request generation of server certificates for use by ExtremeControl engines during Local EAP-TLS Authentication. The passphrase must be identical for all ExtremeControl engines, and must be configured properly, or Local EAP-TLS Authentication does not operate successfully.

Network Settings

Use this tab to configure the following network services for the ExtremeControl engine: DNS, NTP, SSH, and SNMP.

Manage DNS Configuration

Select the Manage DNS Configuration checkbox and enter a list of search domains and DNS servers.

Search Domains: A list of search domains used by the ExtremeControl engine when doing lookups by hostname. When an attempt to resolve a hostname is made, these domain suffixes are appended to the hostname of the device. For example, if someone does a ping to server1, ExtremeControl appends the search domains in an attempt to resolve the name: server1.domain1 server1.domain2, and so on.

DNS Servers: A list of DNS servers the ExtremeControl engine sends DNS lookups to for name resolution. The list is used by both hostname resolution and by the DNS proxy. You can enter multiple servers for redundancy. Use the Up and Down arrows to list the servers in the order they should be used.

Manage NTP Configuration

NTP (Network Time Protocol) configuration is important for protocols such as SNMPv3 and RFC3576 which incorporate playback protection. In addition, having accurate time configured on the ExtremeControl engine is essential for event logging and troubleshooting. Select the Manage NTP Configuration checkbox, specify the appropriate time zone, and create a list of NTP servers.

Time Zone: Select the appropriate time zone. This allows ExtremeControl to manage all date/time settings.

NTP Servers: A list of NTP servers. You can enter multiple servers for redundancy. Use the Up and Down arrows to list the servers in the order they should be used.

Manage SSH Configuration

SSH configuration provides additional security features for the ExtremeControl engine. Select the Manage SSH Configuration checkbox and provide the following SSH information.

Port: The port field allows you to configure a custom port to be used when launching SSH to the engine. The standard default port number is 22.

Disable Remote root Access: Select this option to disable remote root access via SSH to the engine and force a user to first log in with a real user account and then su to root (or use sudo) to perform an action. When remote root access is allowed, there is no way to determine who is accessing the engine. With remote root access disabled, the /var/log/message file displays users who log in and su to root. The log messages looks like these two examples:
sshd[19735]: Accepted password for <username> from 10.20.30.40 port 36777 ssh2
su[19762]: + pts/2 <username>-root

Enabling this option does not disable root access via the console. Do not disable root access unless you have configured RADIUS authentication or this disables remote access to the ExtremeControl engine.

RADIUS Authentication: This option lets you specify a centralized RADIUS server to manage user login credentials for users that are authorized to log into the engine using SSH. Select a primary and backup RADIUS server to use, and use the table below to create a list of authorized RADIUS users.

Authorized Users Table: Use the toolbar buttons to create a list of users allowed to log in to the ExtremeControlengine using SSH. You can add Local and RADIUS users and grant the user Administrative privileges, if appropriate. A user that is granted administrative rights can run sudo commands and commands that only a root user would be able to run. For example, some commands that require administrative rights to run would be:
     sudo nacctl restart
     sudo reboot
     sudo nacdb
If a user is not granted administrative rights, they can log in, view files, and run some commands such a ping and ls.

SNMP Configuration

The SNMP configuration section allows you to deploy SNMP credentials for the ExtremeControl engine. The credentials can include different read/write credentials, for example, the read credential can be "public" and the write credential can be "private". In addition, basic host traps can be enabled from the ExtremeControl engine. Select the Manage SNMP Configuration checkbox and provide the following SNMP information.

Profile: Use the drop-down list to select a device access profile (or multiple profiles) to use for the ExtremeControl engine.

Trap Mode: Set the trap mode.

Trap Community Name: Supply the trap community name.

System Contact: Allows you to specify contact information for the person maintaining the device. Additionally, enter a backslash "\" between contacts to create a device group in a tiered tree structure. For example, to move the device into a device group called "John's Devices" within a device group called "Quality Assurance Testing", enter Quality Assurance Testing\John's Devices in this field.

System Location: The physical location of the device. Additionally, enter a backslash "\" between locations to create a device group in a tiered tree structure. For example, to move the device into a device group called "London" within a device group called "Europe", enter Europe\London in this field.

Device Type Detection

The device type detection settings are advanced settings with complex requirements. Before editing these mappings, contact your Extreme Networks representative or Extreme Networks Support for information and assistance.

Device Type Detection: When the device type detection option is selected, ExtremeControl determines the end-system's device type using the selected detection methods below. Device type can be an operating system family, an operating system, or a hardware type, such as a printer or a smartphone. ExtremeControl uses the selected methods in the order configured in the detection source precedence. When this option is deselected, all device type detection functionality on the ExtremeControl engine is disabled.

Use Agent-Based Assessment: This option causes the ExtremeControl engine to query connected agents for the end-system device type. This is the most accurate method of device type detection.

Use Agent-less Assessment: This option allows the ExtremeControl engine to use the results of an agent-less scan to determine the end-system's device type.

Use DHCP Fingerprinting: This option enables passive device type detection by fingerprinting DHCP packets snooped from an end-system. Select the Edit button to change the mapping of the DHCP packet properties to map to a different operating system or physical hardware type.

Utilize Hostname When Using DHCP Fingerprinting: This option allows the end-system hostname to be used to fine-tune device type detection results using DHCP fingerprinting. With certain device types, if DHCP fingerprinting does not result in a unique device type match, the hostname can be used as one possible tie-breaker. For example, with Apple iOS devices, the hostname can be a good indicator of the device type.

Use Captive Portal Data: This option allows the ExtremeControl engine to detect the end-system's device type by using the agent string returned from the end-system's browser. This is the least secure method for device type detection, since it can be faked by the end-system. However, this option should be enabled if you have configured agent-based assessment with the "Allow Agent Unreachable for Unsupported Operating Systems" option enabled, so that the operating system can be detected when the end-system gets the Remediation web page when it is quarantined.

Allow Device Type Overwrite When Device Type Family Changes: This option allows the device type to be changed by a lower precedence detection method, if the device type family has changed. This option is required if you are supporting dual boot systems and have configured agent-based assessment with the "Allow Agent Unreachable for Unsupported Operating Systems" option enabled. For example, let's say Microsoft Windows XP SP3 was detected by an agent running on a dual boot end-system. If the system is rebooted and switched to Red Hat Linux 4.4, and the end-system is quarantined for not running the agent, the device type detection using captive portal data (a lower precedence method) would yield the device type family of Linux instead of Windows. The device type would be updated and would now pass the unsupported operating system test, and be allowed onto the network.

Source Precedence Order: This list specifies the precedence for the source of information used to determine end-system device type, with the highest precedence listed first. Select an item in the list and use the Move Up and Move Down arrows to change its position in the list. Manual Set refers to device type information that has been hard-coded via ExtremeCloud IQ Site Engine Web Services. Typically, Manual Set (Accurate) has the highest precedence because the exact device type is known and the remaining sources of detection aren't needed, while Manual Set (Best-Guess) has the lowest precedence because it is a best-guess of the device type and should be used only when the other detection methods cannot provide a device type.

IP Address Resolution

The IP Address Resolution tab is used to define how and when ExtremeControl resolves an end-system's MAC address to an IP address for the end-system. These parameters are applicable for ExtremeControl Gateways and L2 ExtremeControl Controllers, but not L3 ExtremeControl Controllers.

Resolve IP Address

Specify when an ExtremeControl engine resolves the IP address for end-systems:

Always - (Default) Resolve the IP address for every end-system that ExtremeControl sees.
Only for Assessment - Resolve the IP address for end-systems that need to be assessed (scanned).

IP Address Resolution Timeout: Enter the maximum time an ExtremeControl engine waits trying to resolve an IP address from an end-system's MAC address before giving up and returning the Error state (MAC to IP Resolution Timed Out) for that end-system.

Allowed Retries on Failure: The number of attempts made to resolve the IP address after the first attempt fails. The default setting is 2 retries, which means that ExtremeControl retries a timed-out request two times, making a total of three attempts to resolve the IP address. Enter the amount of delay time in seconds that ExtremeControl waits before retrying to resolve the IP address.

Delay Between Failures: Enter the amount of time an ExtremeControl engine waits after failing to resolve an IP address before attempting again.

DHCP Resolution Delay Time

The number of seconds an ExtremeControl engine should wait after learning about an end-system before attempting to resolve the end-system's IP address. This delay is used to allow the end-system to negotiate its DHCP IP address. If Port Link Control is enabled, this delay is used after the ExtremeControl engine links down/up the port to force the end-system to request a new IP address on the new VLAN.

NOTE:

If the delay time specified here is less than the amount of time the end-system needs to renew its IP address, then the ExtremeControlengine may resolve the end-system's IP address incorrectly. This is a problem when assessment is enabled and may cause the engine to scan the incorrect IP address. Be sure to take into account the amount of time required for an end-system to get a new IP address when setting the delay time value.

Use DHCP Request IPs

Specify when, if ever, an IP address learned from a DHCP request packet could be used when resolving an end-system's IP address. This option is applicable only for ExtremeControl Gateways, since an inline ExtremeControl Controller should always hear the DHCP response as well.

Always - Always consider the IP address learned from a DHCP request for an end-system's IP, after all more reliable methods have been exhausted.
Never - Never consider an IP address learned from a DHCP request when resolving an end-system's IP address. In a situation where the ExtremeControl Gateway receives DHCP packets from both the client and server, the gateway uses this IP when these packets are received during the IP resolution process. With subsequent authentications for which there is no additional DHCP exchange, ExtremeControl uses the enabled resolution options to resolve the IP address but does not use any previously learned DHCP information to resolve the IP.
For Non-VLAN Switches Only - (Default) Only consider IP addresses learned from DHCP request packets when the NAS switch the end-system was authenticated for does not use VLANs for access control. The IP addresses from request packets in a VLAN environment is always incorrect, because as an end-system transitions through VLANs, it always requests the IP from the previous VLAN.

Rediscover IP on DHCP Request: When this option is selected, ExtremeControl re-runs IP resolution on an authenticated end-system if a DHCP request causes its IP address to change. In this instance, the ExtremeControl policy applies to the new IP address and removed from the old IP address, and assessment scans and port resolution are not performed.

Always Use Fully Trusted DCHP IPs: When this options is selected, the ExtremeControl engine runs a DHCP table lookup to see if DHCP IP address is fully trusted for the end-system. If the address is fully trusted in the table, ExtremeControl resolves the IP address for the end-system without attempting additional resolution processes. If the address is not fully trusted or not found, the ExtremeControl engine attempts to resolve the IP address as normal. When this option is not selected, there is no fast IP resolution using DHCP IP packets.

Use Agent-based Assessment IPs

Specify when, if ever, an IP address reported by a connected agent could be used when resolving an end-system's IP address. This process looks for the end-system’s MAC address in the list of MAC addresses from known connected agents. If an agent is connected and heartbeats during the IP Resolution process, then ExtremeControl uses the IP address of that agent.

Always - Always consider the IP address reported by a connected agent for an end-system's IP, after all more reliable methods have been exhausted.
Never - (Default) Never consider an IP address reported by a connected agent when resolving an end-system's IP address.
For Non-VLAN Switches Only - Only consider IP addresses reported by a connected agent when the NAS switch the end-system was authenticated for does not use VLANs for access control.

Use RADIUS Accounting Packets (IPv4 address)

When this option is selected, if the ExtremeControl engine receives a RADIUS accounting packet with a Framed-IP-Address in it, the engine skips IP resolution and uses the IP address in the RADIUS accounting packet.

Use RADIUS Accounting Packets (IPv6 address)

When this option is selected (ExtremeControl engine enforce required), the Framed-IPv6-Address attributes learned from the RADIUS accounting packet are shown in the IPv6 Address column.

NOTE:

IPv6 address resolution by SNMP is not used if enabled, (even when the ‘Enable IPv6 Addresses for End-Systems’ is enabled in Options> Access Control> Advanced).

Clear Duplicate IPs on Switches: Select this option to have an ExtremeControl engine clear out duplicate entries in the node alias and ARP tables of the NAS switch the end-system was authenticated for, if duplicates are found while trying to resolve the IP address of an end-system. The ExtremeControl engine then tries to re-read the IP address from the table to find the most recent entry.

Re-Read Delay: Specify the amount of time in seconds that an ExtremeControl engine waits after clearing duplicate IPs on a switch or a router before re-reading the node alias or ARP tables.

NetBIOS IP Filtering: This option causes the ExtremeControl engine to make NetBIOS requests to a list of IP addresses, if multiple IP addresses are found when trying to resolve the IP address of an end-system. See NetBIOS Timeout and NetBIOS Timeout Retry Count on the Miscellaneous tab.

Enable Router IP Discovery: This option causes ExtremeControl to make requests to an end-system's gateway router ARP table to try to resolve the IP address for an end-system, if the ExtremeControl engine was unable to resolve the IP address by querying the NAS switch. The gateway router for an end-system can be discovered by the relay router field of a DHCP packet or by using the gateway router defined for an IP subnet for the VLAN an end-system is put into by ExtremeControl. See IP Subnets.

Clear Duplicate IPs on Routers: This option causes an ExtremeControl engine to clear out duplicate entries in the ARP tables of an end-system's gateway router, if duplicates are found while trying to resolve the IP address of an end-system. The ExtremeControl engine then tries to re-read the IP address from the table to find the most recent entry. See Clear Duplicate IP Re-Read Delay.

Default Router Profile: The profile used to make SNMP requests to the gateway router for an end-system, if one is not defined for a specific router's interface IP address as part of an IP subnet. Use the Edit button to open the Profiles/Credentials tab in the Authorization/Device Access window where you can define authentication credentials and create the profiles that use those credentials.

Default Router SNMP Context: The SNMP context used when making requests to the router, if the credentials used for the router are SNMP v3 and the specific router's interface IP address has not been defined as part of an IP subnet.

IP Subnets

IP subnets are used to assist in IP resolution in the following three scenarios:

If a switch is using RFC3580 (VLAN enforcement of access control), the process for determining an IP address is much more difficult. In this scenario, IP subnets can be defined for each VLAN to provide an IP range filter, which can be used to filter the list of IPs discovered on the switch. IP subnets also provide a way to specify a gateway router for the VLAN's subnet, which can be used for doing SNMP reads on a router if DHCP snooping did not capture the relay router.
When VRRP or HSRP is used, and you want ExtremeControl to query the router if needed, ExtremeControl needs to know the primary/secondary router relationship. This order of precedence can be defined in the IP subnet and ensures that ExtremeControl queries the primary router first to get the most accurate data. This is needed in a VRRP or HSRP environment, because both routers send out a DHCP inform message, and it is most likely that the ExtremeControl Gateway gets the secondary router's message last causing it to query the incorrect router.
When DHCP snooping is used, the router SNMP credentials are not the same for all routers. In this scenario, if you want ExtremeControl to query the router for IP resolution, the IP subnets can be used to define the mapping between the relay router IPs and the correct SNMP credentials to use for them.

You can add, edit, or delete IP subnets using the toolbar buttons at the top of the table. There is also a File Import button that lets you import a file of IP subnets; see the File Import window for the file format that must be used.

The Global IP subnets option is used to create a global list of IP ranges used for the purpose of IP Resolution. The IP Resolution process ignores any IP address outside the configured ranges. The checkbox is disabled unless there is at least one subnet configured.

Hostname Resolution

The tab is used to define how and when ExtremeControl resolves an end-system's hostname and an end-system's username. These parameters are engine for ExtremeControl Gateways, L2 ExtremeControl Controllers, and L3 ExtremeControl Controllers.

Hostname Resolution: Use this checkbox to enable or disable hostname resolution for ExtremeControl engines. Hostname resolution is only performed for end-systems for which ExtremeControl has an IP address.

DNS Hostname Resolution: This option allows the use of reverse DNS lookup on the ExtremeControl engine to resolve an end-system's hostname. In order for this option to work, a valid DNS server IP address must have been specified when the ExtremeControl engine was installed. Use the DNS Timeout field to specify the amount of time in seconds that the ExtremeControl engine waits after making a reverse DNS lookup prior to giving up and moving on to the next hostname resolution mechanism.

NetBIOS Hostname Resolution: This option allows the ExtremeControl engine to make a NetBIOS request to the end-system to query the end-system for its hostname. See NetBIOS Timeout and NetBIOS Timeout Retry Count on the Miscellaneous tab.

Kerberos Hostname Resolution: This options allows the ExtremeControl engine to do a lookup in the table of data learned from Kerberos snooping, to resolve the end-system's host name.

DHCP Hostname Resolution: This options allows the ExtremeControl engine to do a lookup in the table of data learned from DHCP snooping, to resolve the end-system's host name.

Username Resolution

Username Resolution: Use this checkbox to enable or disable username resolution, which allows the ExtremeControl engine to try resolve the name of a user currently on an end-system when the username was not part of the authentication request. MAC authentication and L3 ExtremeControl Controller authentication are the two cases where username resolution can currently be used.

Registration Username Resolution: This options causes ExtremeControl to use the username used for authenticated registration or the user's full name for unauthenticated registration in the format: Last Name, First Name.

Kerberos Username Resolution: This options allows the ExtremeControl engine to do a lookup in the table of data learned from Kerberos snooping, to resolve the name of the user currently logged into the end-system.

Ignored Kerberos Usernames: The table is used to define usernames for which Kerberos data is ignored. This is useful when applications running on an end-system use a global user over the Kerberos protocol to pass information for a program. Two known cases of this would be Sophos Anti-Virus software and the IBM Rational ClearCase source control system. You can add, edit, or delete entries using the toolbar buttons at the top of the table.

Reauthentication

This tab is used to define global session-timeout behavior for L2 ExtremeControl Controllers and ExtremeControl Gateways, and how ExtremeControl Gateways reauthenticates end-systems on various NAS switches. This tab is not applicable for L3 ExtremeControl Controllers.

Set Reauthentication Time for Accepted End-Systems to Assessment Interval: This option allows the ExtremeControl engine to set session-timeouts for accepted end-systems, causing the end-system to be reauthenticated the next time a scan needs to be performed. This option is required for networks using 802.1X authentication on wireless switches that do not support the IEEE 802.1X Port Reauthenticate MIB. It is also required for networks using MAC or Web-Based authentication on third-party switches. These switches do not have a mechanism to force re-authentication on end-systems when assessment is complete. This checkbox does not apply for Layer 3 ExtremeControl Controller engines.

Accept Session Timeout

If enabled, this timeout applies to all end-systems that are accepted, but not considered by ExtremeControl to be unregistered end-systems. If both this option and the "Set Reauthentication Time For Accepted End-Systems to Assessment Interval" option are enabled, ExtremeControl uses the lower value. The timeout can be either:

Enabled For Session-Timeout Switches - (Default) The timeout only applies to accepted end-systems authenticated for a NAS switch where ExtremeControl cannot reauthenticate sessions on demand via SNMP or RFC3576.
Enabled for All Switches - The timeout is applied to any accepted end-system (not considered by ExtremeControl to be unregistered) on any switch.

Quarantine Session Timeout

If enabled, this timeout applies to all end-systems quarantined by ExtremeControl. The timeout can be either:

Enabled For Session-Timeout Switches - (Default) The timeout is only applied to quarantined end-systems that were authenticated for a NAS switch where ExtremeControl cannot reauthenticate sessions on demand via SNMP or RFC3576.
Enabled for All Switches - The timeout is applied to any quarantined end-system on any switch.

Unregistered Session Timeout

If enabled, this timeout applies to all end-systems determined to be unregistered by ExtremeControl. The timeout can be either:

Enabled For Session-Timeout Switches - (Default) The timeout only applies to unregistered end-systems authenticated for a NAS switch where ExtremeControl cannot reauthenticate sessions on demand via SNMP or RFC3576.
Enabled for All Switches - The timeout is applied to any unregistered end-system on any switch.

Assessing Session Timeout

If enabled, this timeout applies to all end-systems being scanned by ExtremeControl. The timeout can be either:

Enabled For Session-Timeout Switches - (Default) The timeout applies to end-systems being assessed authenticated for a NAS switch where ExtremeControl cannot reauthenticate sessions on demand via SNMP or RFC3576.
Enabled for All Switches - This option tells ExtremeControl to apply the session timeout for end-systems being assessed on any switch.

Session Deactivate Timeout

This option can be used to provide more up-to-date information about which end-systems are still active on the network. When it is enabled, ExtremeControl checks periodically to determine if an authentication request is received from an end-system within the specified time. If a user is still on the network, then the user is reauthenticated and a new event is generated stating the user is still active on the network. If the user is no longer on the network, the session is removed on the switch and the end-system is displayed in ExtremeControl with the Disconnected state. (Note that when a user leaves the network within the period of time specified, ExtremeControl does not display them as "Disconnected until the specified time has passed.) While this option does provide a more up-to-date list of active end-systems, RADIUS accounting should be used to provide real-time connection status. This option is useful when RADIUS accounting is not desired or is not supported on certain network devices.

NOTE:

The timeout process could be off by approximately 60 seconds from the specified time, depending on when ExtremeControl runs the check for authentication requests.

Switch Reauthentication Configuration: This table is used to configure the reauthentication method an ExtremeControl engine uses on a switch. For example, you may want to add support for another wireless switch. In this case, you would add an entry for the new switch by selecting the Add button, entering the sysObjectId of the switch, and setting the Reauthentication Type to either RFC3576 (if the switch supports it) or Session Timeout. This table is also where you can disable port link control for switches by selecting the switch, selecting the Edit button, and setting the Port Link Control option to disabled.

If you've deleted or edited any of the default configurations, the Restore Defaults button restores them to their original state and add back any that are missing. Any custom entries you added are retained unless they have the same sysObjectId as a default configuration. Following a restore, you need to save the configurations.

Miscellaneous

Use this tab to configure various parameters for your network engines including port link control, NetBIOS, Kerberos, and Microsoft NAP.

Port Link Control

Enable Port Link Control: Use this checkbox to enable or disable port link control. Port link control is required if you are using VLAN only (RFC 3580) switches or if you are using policy with VLANs on EOS policy-enabled switches. When a VLAN is assigned to a switch port, the end-system needs to get a new IP address for the assigned VLAN. To do this, the ExtremeControl engine links down the port, waits the configured amount of time, and then links up the port, causing the end-system to make a new DHCP request and get a new IP address.

NTLM Health Check

Windows provides an authentication protocol called New Technology LAN Manager (Windows NTLM). NTLM is a challenge-response authentication protocol used to authenticate a client to a remote on an Active Directory. NTLM Health Check is an Access Control test that can be enabled in LDAP configurations using NTLM Authentication, and actively used in Access Control AAA configuration rules.

When enabled, the health check runs at regular intervals and test the current domain controller for the specified domain. The test domain is specified in the LDAP configuration. The interval and a timeout can be configured in the Miscellaneous section of ExtremeControl settings (Control > Access Control > Configuration > Global Engine Settings > Engine Settings > Default > Miscellaneous).

Interval (in seconds): This value tells Access Control how often to run the health check.

Timeout (in seconds): This value tells Access Control how long to wait for an authentication response from the Active Directory. If the timeout threshold is exceeded, the failover occurs and the Access Control Lost Partial Contact with LDAP Service alarm is generated.

To complete the health check setup, refer to the documentation sections on NTLM Authentication and Advanced. To configure these additional settings in Access Control, go to Control > Access Control > Configuration > AAA > LDAP Configuration.

NetBIOS

This section controls the timeout and retries that an ExtremeControl engine uses when making NetBIOS requests for IP resolution, MAC resolution, or hostname resolution.

NetBIOS Timeout: The amount of time in seconds that an ExtremeControl engine waits for a response to a NetBIOS request to an end-system, before giving up on that request and retrying.

NetBIOS Timeout Retry Count: The number of times an ExtremeControl engine retries making a NetBIOS request to an end-system, if the end-system does not respond.

Kerberos

Controls how an ExtremeControl engine deals with data it receives from Kerberos snooping.

Allow Use of MAC Resolution for Kerberos Data Processing: When end-systems are behind a router, the ExtremeControl engine uses MAC resolution to resolve an end-system's MAC address from its IP address. This is because when end-systems are behind a router (not in the local network), the Kerberos packets carry the MAC address of the router instead of the end-system. This option allows you to turn off the use of MAC resolution for Kerberos processing, if desired.

Allow Use of Data from Kerberos Request Packets: This option allows the use of data such as username and hostname, from Kerberos request packets. The data in the request packet is provided by the user, and is not guaranteed to be accurate, since it is not authenticated.

Reauthenticate Users on Kerberos Username Change Detected: This option causes the ExtremeControl engine to reauthenticate a user if the username in the Kerberos packet changes.

Reset Authentication Type on Kerberos Login for MAC and IP Authentication: This option is supported for ExtremeControl deployments with inline ExtremeControl Controllers that can capture the end user login. When a user logs in via Kerberos, (for example, a user logs into a Windows domain,) the ExtremeControl Controller resets the authentication type from MAC (for an L2 ExtremeControl Controller) or IP (for an L3 ExtremeControl Controller) to Kerberos. The Kerberos authentication type can then be used by rules to give elevated access to users that have successfully logged into a Windows domain.

Kerberos Age Out Time

This option provides a way to disable the aging out of Kerberos authentication data. This authentication data is used by ExtremeControl to provide elevated access to end-systems. By default, the authentication data is automatically aged out every 12 hours. During that 12-hour period, any time the end-system reauthenticates with ExtremeControl, the user would receive their elevated access privileges. After the 12 hours is exceeded and the authentication data is aged out, the end-system must log in again to get their elevated access. You can use this option to change the age out time or disable the aging altogether. For example, you might want to change the 12 hours to 8 hours, based on a shorter 8-hour workday.

WARNING:

Keep in mind that disabling the age out would create a potential security hole. Elevated access is tied to the end-system, so if it isn't aged out, the elevated access is always available. For example, if a user leaves their laptop and someone logs them out and then logs in as a local user, that person continues to have the elevated access privileges of the original user. Also, a person could spoof someone else's MAC address and receive their elevated access, if the access isn't aged out.

Microsoft NAP

This section provides options related to Microsoft NAP for Windows.

Reset Authentication Type for NAP Enabled End-Systems: When this option is enabled, the ExtremeControl engine resets the authentication type from 802.1x to MS NAP (Microsoft NAP), if the end-system authenticating is NAP-enabled (Windows XP SP2 or higher) and the 802.1x authentication request was proxied to a NAP-enabled server. The MS NAP (Microsoft NAP) authentication type can then be used by rules to assign a different ExtremeControl profile. To configure ExtremeControl to perform as it did in ExtremeControl version 3.1.x, you can create a rule that maps the MS NAP (Microsoft NAP) authentication type to the Pass Through ExtremeControl Profile. With this profile, ExtremeControl does not assess the end-system, and uses the NAP determination of whether or not to quarantine a user.

Override Quarantine Policy for NAP Enabled End-Systems: This option allows ExtremeControl to replace the quarantine policy for NAP-enabled end-systems, using the quarantine policy defined in the profile's Use Quarantine Policy field. Be aware that when this NAP option is enabled, the Use Quarantine Policy checkbox becomes active for all ExtremeControl profiles, even if assessment is disabled. However, you can deselect the checkbox for an individual profile, in which case the policy from the RADIUS attributes is applied.

Proxy NAP Attributes to Switch

This option is disabled by default. When disabled, the following attributes are not proxied to the switch if they are present in the response from the backend RADIUS server:

MS-Machine-Name
MS-Extended-Quarantine-State
MS-RNAP-Not-Quarantine-Capable
MS-Quarantine-State

If the option is enabled, the attributes are proxied to the switch.

Auditing

Use this tab to enable auditing of users connected to the ExtremeControl engine CLI via SSH.

Enable Auditing: Selecting the Enable Auditing option enables the Auditing Rules field, where you can configure ExtremeCloud IQ Site Engine to store all commands entered by a user connected to the ExtremeControl engine CLI via SSH in the engine's local syslog file.

Auditing Rules: Remove the # symbol from the beginning of a command line to enable the command and store user commands entered using the ExtremeControl engine CLI.