ExtremeConnect Security Configuration
ExtremeXOS/Switch Engine Identity Manager
ExtremeXOS/Switch Engine Identity Manager
The ExtremeXOS/Switch Engine Identity Manager solution provides the network administrator with end-system visibility in Mobile IAM. This visibility will give insight on who, when, and where the user is connected to the network.
Module Configuration
| Configuration Parameter | Value |
|---|---|
| Server | < IP Address(es)of ExtremeControl Engine(s )> (semi-colon delimited) |
| Password | < ExtremeControl Engine Shared Secret > (default is ETS_TAG_SHARED_SECRET) |
| Module Enabled | True |
ExtremeCloud IQ Site Engine NAC Manager Configuration
- Using a web browser access the ExtremeCloud IQ Site Engine launch page at the following URL: http://<ExtremeCloud IQ Site Engine Server IP>:8080
- Select “NAC Manager” to launch the NAV Manager application and login using an ExtremeCloud IQ Site Engineadministrator credential.
- Select the “Switches” tab and select “Add Switch”.
- If the ExtremeXOS/Switch Engine switch has not previously been added as a device in the ExtremeCloud IQ Site Engine Console, select “Add Switch”. Otherwise go to step 8.
- In the “Add Device” window enter IP address of switch and select a SNMP profile from the drop down list, or create a new profile by selecting “New” if needed. Enter a nickname for the device (optional) then select “OK”.
- From the device list select the switch and using the drop-down list, select a primary NAC gateway for the switch, set “Gateway RADIUS Attributes to Send” to “Extreme Netlogin – VLAN ID” and ‘RADIUS Accounting’ to ‘Enabled”. Leave remaining configurations set to their default setting. Select “OK”.
- Select the “Enforce All” icon to open the “ExtremeControl Engine Enforce” window.
- Select the configured ExtremeControl Engine from the list and select “Enforce”.
- When enforce is finished select “Close” to close the window
Note: ExtremeControl configurations are used to manage end user connection experience and can control network access based on authentication, time and location. The following section is a basic sample configuration that will authenticate all devices and place them in the same VLAN for devices connected to the switch. Production configuration should be customized based on business needs and security requirements. Refer to ExtremeCloud IQ Site Engine ExtremeControl User’s Guide for additional information on creating custom rules. - Select the “Configuration” tab and select “NAC Configuration: Default”
- In the “NAC Configuration: Default” window select the “Add new rule” icon
- Enter a name for the rule, then using the pull down menu Select “MAC” for Authentication Method.
- Using the pull down menu Select “New” to create a new location group.
- In the “Add Location Group” window enter a Name for the location group then select the “Add Item” icon
- In the “Add Location Entry” window enter an entry description and select the switch using the selection button . Leave “Interface” to “Any” (all ports), then select OK.
- Select OK to close the “Add Location Group” window, then select OK to close the “Edit Rule” window.
Note: The newly created rule displays in the ordered list of rules. If needed, move the rule up or down the list. Rules will be applied to an end-system based on the first rule it matches. - Select OK to close the “NAC Configuration” window.
- Select the “Enforce All” icon to open the “ExtremeControl Engine Encorce” window.
- Select the configured ExtremeControl engine from the list and select “Enforce”.
ExtremeXOS/Switch Engine Configuration
Specific Network Login, IDM related and XML Notification Client configurations are required on the ExtremeXOS/Switch Engine switch. Identity Management with ExtremeXOS/Switch Engine and ExtremeCloud IQ Site Engine/NAC use only a subset of ExtremeXOS/Switch Engine IDM features. These features including Kerberos and LLDP identity detection. ExtremeXOS/Switch Engine FDB, IPARP, IPSecurity DHCP Snooping and Netlogin detection methods are not used.
Note: SSH module must be installed on the ExtremeXOS/Switch Engine switch to use the XML notification feature on HTTPS. If the SSH module is not currently installed you must first download and install the separate Extreme Networks SSH software. When the SSH module is installed, a server certificate is created that the HTTPS server can use.
Refer to Secure Socket Layer section of the ExtremeXOS/Switch Engine Concepts Guide for configuration guidelines of the HTTP server and to generate the secure certificate on the ExtremeXOS/Switch Engine switch.
RADIUS Netlogin Configuration
- Set the ExtremeControl engine server as the primary RADIUS server and configure the shared-secret. Shared-secret must match shared-secret configured on the ExtremeControl engine for this device.
- configure radius netlogin primary server <ExtremeControl IP> client-ip <switch IP address> vr <vr>
- configure radius netlogin primary shared-secret <shared secret>
- Configure ExtremeCloud IQ Site Engine server as the primary RADIUS server and shared-secret for netlogin. Shared-secret must match shared-secret configured on ExtremeCloud IQ Site Engine for this device.
- configure radius-accounting netlogin primary server <NAC IP> client-ip <switch IP address> vr <vr>
- configure radius-accounting netlogin primary shared-secret <shared secret>
- Enable RADIUS and RADIUS accounting on switch
- enable radius netlogin
- enable radius-accounting netlogin
Network Login (Netlogin) Configuration
- Create authentication vlan required for netlogin and configure it the netlogin authentication vlan.
- create vlan nvlan
- configure netlogin vlan nvlan
- Enable MAC-based netlogin on the switch and on the edge ports where users and devices will connect.
- enable netlogin mac
- enable netlogin ports <ports> mac
- Configure the netlogin port mode for MAC-based vlan. This enables support for devices on the netlogin same port to be assigned to different vlans using MAC-based vlans.
- configure netlogin ports <ports> mode mac-based-vlans
- Configure netlogin to accept and authenticate all client MAC addresses. Only MAC addresses that have a match are sent for authentication and the “default” authenticates all MAC addresses.
- configure netlogin add mac-list default
Identity Management Configuration
- Enable Identity Management on switch and add edge ports where users and end system devices will connect.
- enable identity-management
- configure identiy-management add ports <ports>
- Disable the identity-management detection methods that are not used on the edge ports where users and end system devices will connect.
- configure identity-management detection off fdb ports <ports>
- configure identity-management detection off iparp ports <ports>
- configure identity-management detection off ipsecurity ports <ports>
- configure identity-management detection off netlogin ports <ports>
LLDP Configuration
Enable LLDP on the edge ports where users and end system devices will connect.
- enable lldp ports <ports>
XML Notification Configuration
The ExtremeXOS/Switch Engine XML Notification feature is used to send IDM events to ExtremeCloud IQ Site Engine server.
- Create and configure a XML notification target.
- Create xml-notification target
- create xml-notification target ExtremeCloud IQ Site Engine url https://<ExtremeCloud IQ Site Engine IP>:8443/fusion_jboss/XosIDM vr <VR>
- Configure credentials that XML notification will use to access the web services on ExtremeCloud IQ Site Engine. (After entering the command you will be prompted for password)
- configure xml-notification target ExtremeCloud IQ Site Engine user <ExtremeCloud IQ Site Engine admin username>
- Add ExtremeXOS/Switch Engine IDM module (idMgr) to the XML notification target in order to receive events from IDM and send them to the configured url (ExtremeCloud IQ Site Engine server web service)
- configure xml-notification target ExtremeCloud IQ Site Engine add idMgr
- Enable the XML notification target.
Verification
Verify that the configuration is complete by connecting a domain client or LLDP-enabled device to the switch. The device should be identified by ExtremeCloud IQ Site Engine MAC manager and displayed End-System view in NAC managers and in Oneview.
Fortinet FortiGate
The Fortinet FortiGate integration provides a single sign-on solution and network access to end-systems by updating the FortiGate local user table and the use of RADIUS accounting.
Module Configuration
For the sso-Attribute key, profile is the default value. This field must match with the value set in the FortiGate CLI
FortiGate RADIUS server name: add the value configured for RADIUS server
| Configuration Option | Description |
|---|---|
| FortiGate IP address | IP address or FQDN of the FortiGate firewall. Destination IP address of radius accounting packages. |
| RADIUS shared secret | Shared Secret for RADIUS communication from ExtremeCloud IQ Site Engine to FortiGate. |
| SSO Attribute Key | RADIUS attribute key (default value: profile). |
| ExtremeControl appliance | IP address of the Access Control Engine that sends accounting to the FortiGate IP address. This value is optional. |
Extreme Control Configuration
- Using a web browser access the ExtremeCloud IQ Site Engine launch page at the following URL:
http://<ExtremeCloud IQ Site Engine Server IP>:8443 - Navigate to Control → Access Control → Configurations → Profiles to open the list of NAC profiles.
- Create a profile you want to match to the firewall to group users.
- The RADIUS attribute Value references the RADIUS User Group. The group is defined by the NAC Profile.
- Connect to the FortiGate interface.
- Navigate to System → Network → interfaces. Enable "Listen for radius accounting messages"
- Navigate to System → Feature Visibility → Security Features. Enable "Endpoint Control".
- Go to User & Device → Authentication → RADIUS Server.
- Create a new server and add Extreme Control server as RADIUS Server.
- Enter the IP address and Shared Secret.
- Check the Include in every user group box.
- Select Single Sign-on. Add an RSSO_AGENT type RADIUS SSO.
- Go to Authentication → Single Sign-on and create a new agent.
- Check on the web interface that the RADIUS Server is configured correctly.
- Configure RSSO_AGENT through the CLI.
-
For RADIUS attributes expected by the FortiGate firewall, modify the default values for the attributes required by the Connect module: Execute "config user radius" and "get RSSO\ Agent", check that "sso-attribute-key" has value profile and "rsso-endpoint-attribute" has value User-Name.
- In User & Device → User → User Group, create a User Group.
iBoss Web Security
The iBoss integration provides a single sign-on solution and web content filtering capabilities based on the end system’s active directory membership and network location.
Module Configuration
| Configuration Options | Description |
|---|---|
| Server | IP address of the iBoss appliance |
| Port | iBoss web service port, default is 8015 |
| Password | iBoss authentication key |
| Delimiter | Delimiter used to specify a location in the Mobile IAM rule name |
| Max calls | Maximum calls to iBoss appliance per second, default is 5 |
| Max threads | Maximum active processes/calls to the iBoss appliance, default is 8 |
| Strip username | Remove Windows or email domain from the username |
| Module enabled | True |
This section details the steps necessary to install, configure, and test integration between Active Directory, iBoss, and Mobile IAM in a hypothetical K-12 educational environment.
The installer must have technical understanding of the Extreme Networks Mobile IAM solution and the skills required to implement a typical LDAP-integrated deployment of Mobile IAM.
Integration of iBoss and Mobile IAM is accomplished by:
- Defining needed user groups in Active Directory
- Defining the various locations requiring differentiated access
- Configuration of the iBoss appliance
- Installation and configuration of the Extreme Connect Integration services
- Configuration of NAC
Defining Groups in Active Directory
When considering an integration project, first determine the various user populations for which you want to define access, and then place those populations into separate AD groups.
Defining Locations
When you have determined the various end user populations and created/populated the AD groups, next determine what locations require differentiated access for each group.
Listing this location information by user group in a table is most helpful for visualization. Example of listing location by user group in the table below:
| AD Group | Location |
|---|---|
| All Students | Instructional Areas |
| All Students | Cafeteria |
| All Students | Gym |
| All Staff | Instructional Areas |
| All Staff | Everywhere Else |
Configuring the iBoss Appliance
There are three areas to configure on the iBoss appliance to integrate with Active Directory and Mobile IAM beyond the standard configuration needed for standard iBoss operation.
Part A – Configure LDAP Settings
- Open a web browser and go to https://<IP address of appliance > to present the appliance logon screen. Provide the necessary credentials and select the ‘Login’ button.
- Select ‘LDAP Settings’ under Network Settings to configure the Active Directory settings. The LDAP settings page is divided into three sections. The top section contains global settings for the appliance. The default settings should work fine and do not need to be edited.
- The middle section of this page is where you define the AD domain controller iBoss will use by specifying the LDAP parameters required for communication to that domain controller. Complete this section and then select the ‘Add’ button to save the server definition.
- Select 'Done' to save the changes and complete the LDAP configuration.
Part B – Configure AD Plugin
- Select the ‘AD Plugin’ screen from the home page.
- Navigate to the bottom half of the screen where it says ‘Registered AD Servers/NAC Agents’. In this screen, add a description of the ExtremeCloud IQ Site Engine server and its IP address so the iBoss server will listen to updates sent by the NAC servers.
- The default settings can be used for Filtering Group and subnets unless told differently by support. When these settings are saved, this section is complete.
Part C – Configure Filters
A filter group is a set of network controls that define what website content categories, programs, QoS settings, and more are allowed or not allowed to pass through the engine for a given connection. Filter groups are applied to end system traffic on an individual basis.
- Access the Filter Group definition pageby selecting ‘Users’ in the navigation menu on the left hand side of the page, then select the ‘Groups’ submenu link. There are five pages of definitions available for defining filter groups and each page section contains five filter group definitions, for a total of 25 available filter groups.
Note: Filter group #1 is the default filter group and should remain unchanged. - Define a filter group for each AD Group/Location combination by specifying a name for each filter group using the format ADGroupName@Location. The @ symbol acts as a delimiter, so iBoss can separate the AD group name from the location name. The specified group name must be identical to the name of AD group as specified in Active Directory, and the location must be identical to the location name as defined in NAC. Spaces are allowed in both the AD group name and the name of the location.
- Define the three AD group/location combinations for students. As there are only five filter group definitions on each page, each page of definitions must be saved separately before moving on to the next page.
- When you have defined the first five filters, select the ‘Save’ button at the bottom of the page to save changes. Navigate to the next page of filter group definitions by selecting the arrow to the left of the drop-down list at the top of the page.
- Add the remaining student group/location definition.
- When this definition is added, be certain to select the ‘Save’ button at the bottom of the page to save your changes.
Configuration of NAC
The final step in configuring the integration of iBoss and Mobile IAM is to create the location definitions, set up NAC for Active Directory access via LDAP, and configure access rules for each AD group/location combination.
Recall our example table of groups and locations from Defining Locations:
| AD Group | Location |
|---|---|
| All Students | Instructional Areas |
| All Students | Cafeteria |
| All Students | Gym |
| All Staff | Instructional Areas |
| All Staff | Everywhere Else |
The first step is to create an LDAP user group in NAC to represent each AD group used for assigning access. Next create locations in NAC to represent the locations listed.
For this exercise we will create three NAC locations: Cafeteria, Gym, and Instructional Areas. We will not need a specific NAC location for everywhere else but instead will create a general rule to assign access for those end systems.
The name of the rule is significant and must be specified using this particular syntax. Name the rule by putting the AD group name this rule refers to on the left side of the “@” symbol, and the location this rule applies to on the right side. Since this rule applies to All Students in the Instructional Areas location, the rule name becomes “All Students@Instructional Areas”.
Note: Failure to name your rules in this manner will prevent the integration from working properly.
Next, create the rule for All Students in the Cafeteria and All Students in the Gym using the same syntax.
Note: In all three cases we are assigning the same NAC profile to members of All Students.
Finally, create the two Staff access rules. The rule for All Staff in Instructional Areas follows the same format as the student rules. The final rule is different in how it is named; because there is no specific location information provided, we name the rule using just the name of the AD group itself.
Recall when we configured the filter groups in iBoss that we created a filter group with just the AD group name of All Staff. Because there is no location specified iBoss applies that filter group to any end system registered to AD accounts that are members of All Staff that are not otherwise in a defined location. Naming the rule without the @ symbol or location name tells Extreme Connect to omit the location when making the call to iBoss. Using this naming syntax enables filter groups to be assigned to end systems based solely on AD group membership.
Because this rule is more general than the previous staff access rule, it must be located below the All Staff@Instructional Areas rule in the NAC configuration in order to work correctly.
Verification
- Using two wireless clients, connect to a test SSID and authenticate using two different accounts.
- Ensure each account is a member of different active directory groups.
- Configure two iBoss filtering groups that match the AD groups that each test account are part of.
- iBoss can display information about the filter groups it assigns to end systems from its web interface. Use both NAC Manager and the iBoss management interface to confirm our integration configuration.
- Locate both end systems so they connect from the Instructional Areas location. From the Identity and Access tab of OneView we can see that the correct rules have been applied to each end system.
- To see the corresponding information in iBoss, open the management interface and select ‘Users’ from the navigation menu on the left hand side of the page, then select the ‘Computers’ submenu item. Our information is listed in the ‘Detected Computers’ section of this page.
Note that both NAC and iBoss list the same end system IP address, filter set name, and AD user name for each end system. This indicates that integration is working and our configuration is correct.
Lightspeed Rocket Web Filter
The Lightspeed integration provides a single sign-on solution and web content filtering capabilities based on the end system’s active directory membership.
Module Configuration
| Configuration Option | Description |
|---|---|
| Server | IP address of the Rocket Web Filter appliance |
| Password | RADIUS Shared Secret |
| Module Enabled | Enables and Disables Module |
| RADIUS interim message interval | Send a RADIUS interim message to keep the session active, in minutes |
| Include Calling-Station-ID | Include the Calling-Station-ID RADIUS attribute, calling station is set to the end system’s MAC adding |
| Include Called-Station-ID | Include the Called-Station-ID RADIUS attribute, called station is set to the switch IP address |
| Ignore usernames that contain | Ignore usernames that contain the entered value, multiple values can be entered with a semi-colon delimiter |
| Ignore NAC profiles | Ignore end system’s that are assigned a NAC profile, multiple values can be entered with a semi-colon delimiter |
Configuring the Rocket Appliance
In addition to the standard configuration of the Rocket Web Filter appliance, steps are required to integrate with Active Directory and Mobile IAM. Only the steps necessary for integration will be covered in this document.
Configure LDAP Settings
- Log in to the Rocket appliance, https://<IP address of Rocket Appliance>. This presents the appliance login screen. Provide the necessary credentials and select the Login button.
- Select the Administration menu in the top right corner of the dashboard.
- Scroll down to the Authentication Sources to configure the Active Directory settings.
- Select + Add Authentication Source, within this menu to add the required fields.
- When the Active Directory server is saved, verify it is listed in the Authentication Sources section.
- Select the Test button to verify the Active Directory configuration.
- Use a known valid domain username and password, select “Test User Login.” A Success message will appear upon a successful query.
Configure RADIUS Accounting
- The RADIUS Shared Secret is a configurable field within the Rocket appliance.
- The Shared Secret can be found by accessing the Web Filter menu and scrolling to the bottom of the page.
- Input the desired Shared Secret to be used between the Lightspeed Systems Rocket Web Filter appliance and the Extreme Connect Lightspeed Systems module. Note the Shared Secret value for later configuration steps.
Configure Policy Management
The next items to configure are the Rule Sets that the Rocket Web Filter appliance assigns to end-systems. Rule Sets are lists of web site categories, keywords, and actions that control how users access the Internet.
- A pre-defined Rule Set (Block All) is assigned to an Organizational Unit (OU=Solutions Eng,DC=testing,DC=local) that is defined in the previously added Active Directory Server.
- To access the Policy Management section of the Rocket Appliance, select Web Filter then select Policy Management from the left column.
- Verify that the Rule Set exists in the Rule Set section of Policy Management.
- After verifying the Rule Set exists, a new Assignment is created to assign the Rule Set to an object. Navigate to Assignments then select New Assignment.
- In the New Assignee window, select the Type of object to be used. To browse the Authentication Source, the Search feature can be used to list all OU’s available on the server.
- Verify the Web Filter Rule in this new assignment at the bottom of the window.
McAfee ePO
| IMPORTANT: | McAfee ePO connect module has been deprecated due to API changes on the ePO. |
The McAfee ePO integration offers end-system assessment via ePO, automatic anti-virus signature file update via ePO and quarantining end-systems via NAC.
Module Configuration
The table below describes the configuration options available for the McAfee ePO OFConnect module
(config file: McAfeeEPOHandler.xml)
| Service Configuration | Description |
|---|---|
| Username | Username used to connect to the ePO API. |
| Password | Password used to connect to the ePO API. |
| Server | ePO Server IP |
| Port | ePO Server Port |
| General Module Configuration | |
|---|---|
| Poll interval in seconds | Number of seconds between connections to the adapter running on the SCVMM server. |
| Module loglevel | Verbosity of the module. Logs are stored in ExtremeCloud IQ Site Engine's server.log file. |
| Module enabled | Whether or not the module is enabled. |
| Update local data from remote service | If this is set to “true”, data from the remote service will be used to update the internal end-system table. It is recommended to set this option to “true”. You will also need to set this to “true” if you want to populate the username and device type from McAfee in NAC (see additional options below). Default: true. |
| Default end-system group | The default end-system group name where we assign all McAfee devices to in NAC. If you don't want end-systems from McAfee to be assigned to this default group, configure a group name which doesn't exist in NAC. |
| Enable Data Persistence | Enabling this option will force the module to store end-system, end-system group and VLAN data to a file after each cycle. If this option is disabled, the module will forget all data after a service restart, but in order to clean already existing data, the corresponding .dat files have to be deleted. |
| Service Specific Configuration | |
|---|---|
| Custom field to use: | The number of the custom data field for each end-system to store the data retrieved from ePO. Available values are: 1, 2, 3 or 4. Default: 1. |
| Format of the incoming data: | Format of the data that gets stored in the custom data field. You can chose and combine any of the available variables: ipAddress, macAddress, osType, osServicePackVersion, nodeName, userName, datVersion, lastUpdate. But be aware that ePO might update the “lastUpdate” value for each device very regularly and OF Connect is calling ExtremeCloud IQ Site Engine’s web services to refresh that value in all end-systems custom fields. Depending on your poll interval this might put a lot of stress onto the ExtremeCloud IQ Site Engine server and it is thus recommended to _NOT_ use this variable here. It should only be used if the poll interval is very low (like one time per day) and the number of end-systems isn’t too high (below 1000). Dfault: NodeName=#nodeName#; OS=#osType# (#osServicePackVersion#); User=#userName#; DAT Version=#datVersion# |
| End-system group for decommissioned devices: | The default end-system group for devices that existed in ePO but have been deleted. If you want to explicitly identify those devices and even authorize them differently (since they are no longer managed by ePO and that could pose a threat) you can configure the group they should automatically be moved to here and enable the corresponding feature below. Make sure you manually create this end-system group in NAC |
| Remove device from other groups on decommission: | Enable this to move devices which have been deleted from ePO to the NAC end-system group configured by the corresponding option above. If disabled, devices won't be automatically move to this group but rather stay with their existing group membership(s). Default: false |
| Delete custom data in EMC for decommissioned devices: | If a device is deleted in ePO the end-system's custom data field in ExtremeCloud IQ Site Engine will be cleared as well. Default: false. |
| Overwrite the existing username with the one acquired from McAfee ePO: | If set to "true" the username for devices retrieved from ePO will overwrite the username that is already in IAM. If no username could be retrieved from ePO for a given end-system, then no change is performed in IAM. Default: false. |
| Overwrite the existing device type for devices with the one acquired from McAfee EPO: | If set to "true" the device type (operating system) retrieved from ePO will overwrite the device type that is already in IAM. If no operating system could be retrieved from ePO for a given end-system, then no change is performed in IAM. Default: false. |
| Max DAT version difference between ePO and client before triggering client update task: | Max DAT version difference between ePO and client before triggering client update task: Setting this value to 0 will disable this feature. Default: 1. |
| Max DAT version difference between ePO and client before generating a ExtremeCloud IQ Site Engine event | This feature can be used to create ExtremeCloud IQ Site Enginet alarms based on these events. These alarms could be configured to alarm the via Email or trigger other mechanisms. Setting this value to 0 will disable this feature. Default: 4. |
| Max DAT version difference between ePO and client before quarantining client via NAC: | For example: If set to "7" and the difference between the DAT version on ePO's controller catalog and the client's DAT version is at least 7 then the value for the corresponding assessment test result will be set to 10 and “HIGH”. You can use your IAM assessment configuration to automatically push those end-systems to a quarantine role if required. Setting this value to 0 will disable this feature. Default: 0. |
| Name of the ePO client task that OFConnect uses to trigger a DAT version update for individual devices: | Use the exact name as defined in ePO. Ddefine a client task in ePO that will update a client's DAT file (and maybe even more like the agent version, etc.). It will also find any client tasks where the configured name is part of. Default: Update Agent. |
| Time before client update task is aborted by EPO | Number of minutes after which the EPO server should abort the client update task. This value is sent to the EPO server when running the "clienttask.run" web service call as an addtional parameter ("abortAfterMinutes"). Setting this value to 0 disables this feature - the parameter won't be used when making the web service call. Default: 10 minutes. |
| Max number of client update tasks triggered per client per day | To avoid triggering too many EPO client update tasks you can set this limit to a non-zero value. We will stop triggering EPO client update tasks after the configured maximum number of retries has been reached for the current day. As soon as the next day starts (first run after midnight), the count of retries per MAC address is automatically reset to zero and client update tasks will be triggered again as long as the device is still out of date (see dat_file_max_difference_before_trigger_update_task) or the maximum for that day has been reached again. Setting this value to 0 disables this feature the code will trigger a client update task on each cycle as long as the device is out of date. Default: 1 update task per client per day |
| Max number of ExtremeCloud IQ Site Engine events generated per client per day | To avoid generating too many events you can set this limit to a non-zero value. We will stop generating ExtremeCloud IQ Site Engine events after the configured maximum number of retries has been reached for the current day. As soon as the next day starts (first run after midnight), the count of retries per MAC address is automatically reset to zero and events will be generated again as long as the device is still out of date (see dat_file_max_difference_before_generating_netsight_event) or the maximum for that day has been reached again. Setting this value to 0 disables this feature the code will generate a event on each cycle as long as the device is out of date - no matter how many cycles/triggers per day. Default: 1 event per day |
| Enable Assessment: | If this is set to “true”, assessment data for all devices managed by ePO will be made available to the assessment adapter. The data will be updated on each cycle. Default: false. |
| Request an immediate re-assessment of an end-system if its DEVICEOUTOFDATE value changed: | If this is set to “true”, a re-assessment of each end-system where its DEVICEOUTOFDATE value changed (either from "true" to "false" or the other way round) will be requested from IAM. This will ensure that if, for example, an end-system has been pushed to Quarantine since its DAT file version was out-of-date but now it has updated the DAT version, it will immediately be re-assessed and authorized properly. If this feature is disabled, it might take hours/days for the end-system to update its NAC policy/authorization depending on the IAM assessment configuration for this end-system. This feature is only used if the assessment feature is also enabled. Default: true. |
| Use XAPI to trigger a reauth and thus also a re-assessment of an end-system: | If this is set to true, a re-assessment of an end-system will not be performed via a web service call but rather executed directly on the access switch of the end-system. This will be executed via XAPI so "enable web http(s)" needs to be configured on eachExtremeXOS/Switch Engine switch. This will execute the command 'clear netlogin state mac-address' with the MAC of the end-system to immediately trigger a re-auth. The re-auth then triggers a re-assessment of the end-system which should then immediately change its authorization state from ACCEPT to QUARANTINE or vise versa. This feature is only used if the reassess_endsystem feature is also enabled. |
| Use HTTPS for XAPI calls: | Enable this to use HTTPS instead of HTTP for any XAPI communication with all ExtremeXOS/Switch Engine switches. If enabled, you will also need to install the SSH mod on all ExtremeXOS/Switch Engine switches and configure "enabled web https". This option is only used if the reauthenticate_endsystem_using_xapi feature is also enabled. |
| Username to connect to any ExtremeXOS/Switch Engine switch if no CLI credentials are provided within ExtremeCloud IQ Site Engine: | If the feature reauthenticate_endsystem_using_xapi is enabled, the solution will need to authenticate on all ExtremeXOS/Switch Engine switches to perform re-authentication of end-systems. It will try to retrieve the corresponding username and password from the configured CLI credentials fromExtremeCloud IQ Site Enginebut if there aren't any for a particular switch, then this default value will be used |
| Password to connect to any ExtremeXOS/Switch Engine switch if no CLI credentials are provided within ExtremeCloud IQ Site Engine: | If the feature reauthenticate_endsystem_using_xapi is enabled, the solution will need to authenticate on all ExtremeXOS/Switch Engine switches to perform re-authentication of end-systems. It will try to retrieve the corresponding username and password from the configured CLI credentials fromExtremeCloud IQ Site Enginebut if there aren't any for a particular switch, then this default value will be used. |
| Name of the ePO client task that Connect uses to trigger an agent wake up: | Use the exact name as defined in ePO. Define a client task in ePO that will wake up a client's agent. This is required to Connect to wake up the agent on quarantined end-systems for which a client update task has been triggered. By default, ePO agents only report their DAT version to the ePO server one time per hour. Therefore, Connect will only realize that an end-system has updated to the latest DAT Version after quite a long time and thus that end-system might be quarantined for quite a long time. Sending the latest DAT version to the ePO server through an agent wake up task will improve the behavior and get end-systems out of their quarantine state quicker |
| Time before the agent wake up client task is triggered after a quarantine event and update task trigger: | In case an end-system was quarantined by NAC the code is triggering an ePO client update task. This task will try to update the DAT version on the end-system through the ePO agent. This process might take a few minutes. After a successful update, the ePO agent is not immediately reporting the current client DAT version back to the ePO server - it will only report this using its standard poll interval which is typically set to run one time per hour. Setting this value to 0 disables this feature. Default: 0. |
Verification
Any data (including assessment data) will only be updated during the configured update intervals. Any data retrieved from ePO and any action triggered in direction to ExtremeCloud IQ Site Engine are handled by the ExtremeControl Handler, which has its own update interval and needs to pickup any changes/updates from ePOHandler and push it to ExtremeCloud IQ Site Engine. Depending on the number of changes/actions during one cycle and the number of end-systems managed, you will need to provide some time before you validate the data in ExtremeCloud IQ Site Engine.
Data Import to IAM
There are multiple areas to verify when data on all devices managed by ePO is imported to IAM.
The first option is to use OneView’s end-system table under the “Identity and Access” tab and display the custom data field which you have configured for the McAfeeEPOHandler. If you enabled the corresponding features you should also see the username retrieved from ePO and a more detailed Device Type also retrieved from ePO.
Another option is to use the general “Search” tab and search for an end-system which is managed by ePO. It should find the end-system and display ePO data as shown below.
Assessment
If it its DAT file is running out-of-date and the corresponding assessment features are enabled, a healthy device did not update to the latest ePO DAT version and is thus running a DAT version which is older than X versions configured in the ePO handler config file. When Extreme Connect recognizes the outdated DAT file it will populate that fact to the assessment adapter and also try to trigger the corresponding client update script on the EPO server. That update task will only be triggered for end-systems that are in ACCEPT or QUARANTINE state to avoid trying to update end-systems that are disconnected, rejected or in error state. If IAM triggers an assessment for this end-system before the device could be updated, it will recognize that the device is out-of-date and needs to be quarantined.
At this stage, the device has a policy (or VLAN) so it is unable to harm other network devices or services but still allows the ePO server to contact and update it.
After ePO has successfully updated the device and the next OF Connect update cycle has run, the assessment adapter will receive the updated info (from OF Connect) that the device is no longer out-of-date. OF Connect will then immediately trigger a re-assessment within IAM which will lead to re-authorizing the device into its proper policy (VLAN) since the new assessment result showed that the device is compliant and the DAT is not out-of-date anymore.
End-systems which contain the keyword “Server” in their operating system name (as retrieved from EPO) will receive a test score of 6.0 instead of 10.0 for the DEVICEOUTOFDATE test and thus won’t be quarantined. This is due to the fact that most customers don’t want to quarantine server systems and EPO offers a solution called MOVE which protects virtual servers without applying a DAT file to each server ( DAT version will always be 0 although these systems are protected by EPO).
Handling Deleted ePO Devices
To test this workflow remove/delete a device from ePO and wait for the next OF Connect synchronization. Then verify that:
- The device’s custom field has been emptied (if this feature has been enabled in the config file)
- The device is now member of the IAM end-system group for decommissioned devices (if this feature has been enabled in the config file)
- The device does not appear in the end-system list that is displayed at the bottom of the OF Connect management web site (tab: McAfee ePO). This means that the device has been deleted in the internal list as well
Palo Alto Networks
The Palo Alto integration consists of multiple solutions. The user ID solution notifies Palo Alto of IP to username mapping. The distributed IPS solutions monitor a log file and can take action on an end-system based on the severity of the log message. It is recommended to use the Distributed IPS instead of the Palo Alto Distributed IPS moving forward.
Module Configuration
| Configuration Option | Description |
|---|---|
| Username | Palo Alto username |
| Password | Palo Alto password |
| Server | Palo Alto IP address |
| Version | Palo Alto software version |
| User-ID (UID) enabled: | Enable user-ID integration |
| User-ID server: | User-ID agent IP address(es) |
| User-ID port: | User-ID agent port, default is 5006 |
| User-ID domain: | Default username domain or NAC profile to domain mapping(s) |
| User-ID concurrent message: | Send concurrent User-ID messages to Palo Alto, this option should be disabled for lower end Palo Altos |
| User-ID vsys: | Palo Alto vsys to update, default is vsys1 |
| User-ID multi-user message: | Send multiple User-ID mappings in 1 message. It is recommended to enable this option to lessen processing load on the Palo Alto |
| User-ID multi-user timer: | Time to queue User-ID mappings before sending Palo Alto User-ID message, increasing the timer will increase the number of User-ID mappings |
| User-ID strip email domain: | Remove email domain from the username |
| User-ID strip domain name: | Remove Windows domain from the username |
| User-ID strip domain username delimiter: | Remove all characters after the delimiter in the username |
| User-ID append to domain username: | Append string to username |
| User-ID timeout: | Palo Alto User-ID timeout |
| User-ID ignore usernames that contain: | Ignore usernames that contain the entered value, multiple values can be entered with a semi-colon delimiter |
| User-ID ignore NAC profiles: | Ignore end system’s that are assigned a NAC profile, multiple values can be entered with a semi-colon delimiter |
| Distributed IPS (DIPS) enabled: | Enable distributed IPS integration |
| Distributed IPS syslog regular expression: | Regular expression match before action can be taken on an end-system |
| Distributed IPS syslog file | Syslog file path |
| Distributed IPS blocked list severity | Severity level needed to add an end-system to the blocked list |
| Distributed IPS SNMP authentication type | SNMPv3 authentication type |
| Distributed IPS SNMP authentication password | SNMPv3 authentication password |
| Distributed IPS SNMP privacy type | SNMPv3 privacy type |
| Distributed IPS SNMP privacy password | SNMPv3 privacy password |
| Module enabled: | Enable the Palo Alto solution |
Distributed IPS
The distributed IPS solution monitors log files for events or opens a port on the ExtremeCloud IQ Site Engine server and listens for events. When an event is received, action can be taken to add the threat to an end system group.
Module Configuration
| Configuration Option | Description |
|---|---|
| Name | Event name, this is the default threat name used in the end system group description |
| Regex | Event regular expression string |
| File | File, full path, to monitor for events |
| Port | Port number to open and listen for events on, opening a port can increase vulnerability on the ExtremeManagement server |
| Protocol | Port number protocol |
| Sender filter | Process events only from specific IP addresses to prevent spoofing, this field is used in conjunction with the port and protocol |
| End system group | End system group to add the threat to |
| End system group type | End system group type, MAC or IP |
| MAC address regular expression | MAC address regular expression, it is recommended to not change this value |
| IP address regular expression | IP address regular expression, it is recommended to not change this value |
| Threat name regular expression | Threat name regular expression, the default regular expression will match a group of words surrounded by double quotes or a group of words without spaces.
Example formats that will match the regular expression: “This is a threat 123” This_is_a_threat_123 This-is-a-threat-123 ThisIsAThreat123 This_is_a_Threat(123) |
It is recommended to find keywords in the regular expression string and use those keywords as unique identifiers.
The event must contain either the MAC or IP address of the threat. When a MAC address based end system group is used and the threat MAC address is not in the event, a lookup will be done to resolve the threat’s IP address and vice versa for an IP based end system group.
Common wildcards that will be used are:
\w = match a character
\d = match a number
\s = match a space
. = match any character
* = match 0 or more
+ = match 1 or more
Examples of event messages and their regular expression:
Example 1. Checkpoint event message
loc=4220 filename=fw.log fileid=1402093147 time= 6Jun2014 16:01:57 action=block orig=r77 i/f_dir=outbound i/f_name=eth1 has_accounting=0 product=Anti Malware web_client_type=Chrome resource=http://sc1.checkpoint.com/za/images/threatwiki/pages/TestAntiBotBlade.html src=Winsvr2012 s_port=49600 dst=23.203.225.174 service=http proto=tcp session_id=<53924865,00000002,b17361d1,c0000001> Protection name=”Check Point - Testing Bot” malware_family=Check Point Confidence Level=5 severity=2 malware_action=Communication with C&C site rule_uid={AE831485-A9C8-4681-BE8F-0E2E66904BDB} Protection Type=URL reputation malware_rule_id={27CC0EC6-7CBE-F54E-AFE0-F46162CEB057} protection_id=00233CFEE refid=0 log_id=9999 proxy_src_ip=Winsvr2012 scope=Winsvr2012 __policy_id_tag=product=VPN-1 & FireWall-1[db_tag={8119E2B3-79E5-4747-80E6-6756E42EE86D};mgmt=r77;date=1402094422;policy_name=Standard] origin_sic_name=cn=cp_mgmt,o=r77..pcfxuu Suppressed logs=1 sent_bytes=0 received_bytes=0 packet_capture_unique_id=192.168.10.189_maildir_sent_new_time1402095718.mail-4230074710-508316721.localhost packet_capture_time=1402095718 packet_capture_name=src-192.168.10.189.eml UserCheck_incident_uid=80E6C145-7AB6-D2C5-1DC5-A500F1473A70 UserCheck=1 portal_message= Your computer is trying to access a malicious server. It is probably infected by malware. For more information and remediation, contact your help desk. Select here to report an incorrect classification. Activity: Communication with C&C site URL: http://sc1.checkpoint.com/za/images/threatwiki/pages/TestAntiBotBlade.html Reference: F1473A70 UserCheck_Confirmation_Level=Application frequency=1 days
In the above example, “Check Point - Testing Bot” is the threat name and 192.168.10.189 is the threat IP address.
Regular expression:
Protection name=$threatName malware_family.* packet_capture_name=src-$threatIpAddress
The regular expression contains unique identifiers to avoid ambiguity or incorrect matches. “Protection name=” precedes the threat name and “malware_family” follows the threat name. A wildcard (.*) is used to match against multiple characters after “malware_family.”
Simulating an event with the above message will generate the following log message in the ExtremeManagement server:
Regular expression match -> {$threatIpAddress=192.168.10.189, $threatName="Check Point - Testing Bot"}
Example 2. Watchguard event message
Jun 13 13:42:18 10.148.1.254 local1.info Jun 13 13:42:18 QA_LAB_FB 80BE052F336C0 http-proxy[1631]: msg_id="1AFF-0034" Deny 1-Trusted 0-External tcp 192.168.10.180 21.37.51.86 33444 80 msg="ProxyDrop: HTTP APT detected" proxy_act="HTTP-Client.Anti-X" host="fishherder.dyndns.org" path="/tmp/lastline-demo-sample.exe" md5="dd0af53fec2267757cd90d633acd549a" task_uuid="235ee8f1185e4337986a0a46eb370595" threat_level="high" (HTTP-Proxy-00)
In the above example, “ProxyDrop: HTTP APT detected” is the threat name and 192.168.10.180 is the threat IP address.
Regular expression:
External tcp $threatIpAddress .* msg=$threatName proxy_act
Simulating an event with the above message will generate the following log message in the ExtremeManagement server:
Regular expression match -> {$threatIpAddress=192.168.10.180, $threatName="ProxyDrop: HTTP APT detected"}
Example 3. Palo Alto event message
Aug 25 15:51:28 PA-5060-1 -PaloAlto: -threatIpAddress 192.168.10.179 -threatName "Apache Wicket Unspecified XSS Vulnerability(36041)" –severity critical
In the above example, “Apache Wicket Unspecified XSS Vulnerability(36041)” is the threat name and 192.168.10.180 is the threat IP address.
Regular expression:
PaloAlto: -threatIpAddress $threatIpAddress -threatName $threatName
Simulating an event with the above message will generate the following log message in the ExtremeManagement server:
Regular expression match -> {$threatIpAddress=192.168.10.179, $threatName="Apache Wicket Unspecified XSS Vulnerability(36041)"}
Check Point User ID
The Check Point user ID integration updates the Check Point gateway with the username IP mapping of end systems that connect to the ExtremeControl engine(s).
Module Configuration
| Module Configuration | Description |
|---|---|
| Server | Check Point IP address |
| Password | Check Point shared secret |
| Ignore usernames that contain | Ignore usernames that contain the entered value, multiple values can be entered with a semi-colon delimiter |
| Ignore NAC profiles | Ignore end system’s that are assigned an ExtremeControl profile, multiple values can be entered with a semi-colon delimiter |
| Session timeout | API user mapping timeout, in hours |
Sample server log output:
2017-02-16 12:32:41,937 DEBUG [com.enterasys.fusion.modules.CheckPointHandler] Sending -> https://10.224.1.252/_IA_MU_Agent/idasdk/add-identity post
{"shared-secret":"mysharedsecret","requests":[{"ip-address":"192.168.10.181","user":"doe, john","session-timeout":3600}]}
2017-02-16 12:32:42,278 DEBUG [com.enterasys.fusion.modules.CheckPointHandler] Response -> {
"responses" : [
{
"ipv4-address" : "192.168.10.181",
"message" : "Association sent to PDP."
}
]
}