Connect Mobility Configuration

AirWatch

Fiberlink MaaS360

JAMF Capser

MobileIron

Sophos Mobile Control

Citrix XenMobile

AirWatch

The AirWatch integration offers provisioning of mobile devices in the network based on device ownership and also provides assessment data within the network access control process. In addition, data within Extreme Management Center is enriched for each end-system and offers comprehensive reporting capabilities within OneView.

Module Configuration
Server Configuration Description
Username Username used to contact the MDM provider. Must have access rights to the respective API.
Password Password used to contact the MDM provider.
AirWatch Server IP IP or hostname of the MDM server.
AirWatch Webservice URL Base URL to connect to the API of the service.
AirWatch Tenant Code API key provided by AirWatch to access a specific customer configuration.

 

General Module Configuration
Poll interval in seconds Number of seconds between connections to the MDM provider.
Module loglevel Verbosity of the module. Logs are stored in NetSightExtreme Management Control Center's server.log file.
Module enabled Whether or not the server is enabled.
Push update to remote service If this is set to true, data from other modules will be pushed to the service.
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.
Default end-system group The default end-system group name to use if an end-system is not approved yet.
Enable Data Persistence Enabling this option will force the module to store end-system, end-systemGroup 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 service specific incoming data.
End-system group for Managed Business Mobile Devices The default end-system group for corporate mobile devices.
End-system group for Managed Personal Mobile Devices The default end-system group for personal mobile devices.
End-system group for Decommissioned Mobile Devices The default end-system group for decommissioned mobile devices.
Enable Remote Wipe

If this option is enabled, devices will be wiped if they are moved to the MDM Remote Wipe End-system Group.

  • off – disabled
  • enterprise - always perform an enterprise wipe (only deletes corporate data)
  • adaptive - will perform an enterprise wipe if the device was an employee-owned device and a full wipe if it was a company device
  • full - always perform a full wipe regardless of ownership
Enable Quarantine Notification If this is set to “true”, the device will be notified via the selected mode if it is quarantined
Quarantine Notification Text Message sent in the quarantine notification to the user.
Enable Assessment If this is set to “true”, assessment data will be made available to the assessment adapter.

 

Assessment Plugin Map  
Plugin Name The Plugin ID Name.
Data Field The AirWatch Data Field being retrieved in this test
Force Reassessment Force Re-Assessment on content change.
Format of the incoming data

Format of the data that gets stored in the custom data field

SYNTAX
The end-system is currently #mdmManaged#

Available Variables:

  • id
  • udid
  • serialnumber
  • imei
  • assetnumber
  • name
  • locationgroupid
  • locationgroupname
  • username
  • useremailaddress
  • ownership
  • platformid
  • platform
  • modelid
  • model
  • operatingsystem
  • lastseen
  • enrollmentstatus
  • compromisedstatus
  • compliancestatus
  • lastcompliancecheckon
  • lastcompromisedcheckon
  • lastenrolledon
  • macaddress
  • iscompromised
  • dataprotectionenabled
  • blocklevelencryption
  • filelevelencryption
  • ispasscodepresent
  • ispasscodecompliant
Update Kerberos username for end-systems If this is set to “true”, the username will be updated for each end-system and a Kerberos re-authentication is triggered.
Update custom fields for end-systems If this is set to “true”, the custom field data will be updated for each end-system.
Update devicetype for end-systems If this is set to “true”, the device type data will be updated for each end-system.

Variables available for custom field string are defined in the AirWatch API documentation.

Note: Look and feel of the MDM interface may change depending on customer’s customizations.

Create an API User

Under AirWatch user management, all users and administrator users have access to the web services API. The process below explains how to create a generic user with Full Access:

Note: Any user with role ‘API’ can access the API; a new user role can be created that only grants access to the API and restricts all other access.

  1. From the main Dashboard, select Menu > Accounts > Administrators.
  2. From the list of users, click Add > Add User, or edit one of the existing users.
  3. Select Basic next to User Type.
  4. Provide the user credentials.
  5. Add a role, and then click Save.
    The user and password provided in the previous screen must be provided to MDM connect in the corresponding AirWatch plugin configuration file.
  6. An additional parameter to obtain for the connectivity with AirWatch´s servers is the Tenant Code. This can be obtained from AirWatch’s interface in Configuration > System Settings > System > Advanced > API > REST API:
    The API key is the value that must be provided to the AirWatch module as Tenant Code
Creating a Compliance Profile

The basic variable provided by the Assessment Adaptor is the compliance status. This variable (TestID 100002) contains whether or not the mobile device with that security profile applied is compliant or not with the security requirements specified by the profile.

This variable can be taken as a global indicator of compliance with the security rules of the enterprise. Other variables can be taken into account to provide fine grained access control to the network. From NAC we may decide to use the variable PASSCODEPRESENT (TestID 100028) to verify if a device has defined a password and quarantine devices that don’t have a password during the grace period allowed by the security policy.

AirWatch differentiates between Compliance Profiles and Device Profiles. Compliance Profiles define security rules that the device must comply with like:

  • Installed applications
  • Cellular use
  • Encryption
  • Version of OS
  • Change of SIM

A Device Profile defines a set of configurations that the device must have in order to be considered compliant like:

  • Password length
  • SSID lists
  • Exchange servers
  • General restrictions in the device like allowing SIRI, allowing Youtube, Screen Capture, iCloud etc…
  • Installed Certificates
  • APNs

Some of these can be configured by the MDM itself when the profile is applied; some of them require user intervention and will probably define a grace period until they trigger a security action if the configuration hasn’t been performed, e.g. the password change mentioned before.

Device and Compliance Profiles are assigned by device type, location group, ownership, etc.

Example: Define a Compliance Profile for an application.

  1. Select Add > Compliance Policy.
    The wizard to create a new policy appears, select application list, the desired operation (contains) and define the name of the application (e.g., verybadapp).
  2. Click Next if you have finished, or click + to add more rules to this profile.
  3. The next screen will offer several remediation options, like removing or changing the device profile, notifying the user, executing a command, etc. Choose to notify the user cc’ing our systems administrator.
  4. Click Next to select the device mapping.
    In the device assignment choose which devices will be checked against this profile. You can choose Platform, Manager, Ownership of the device, etc.
  5. Clicking Next will take us to the summary screen.
    Now you have the chance to give a name to the compliance policy and check how many of the currently enrolled devices will pass or fail our test.
  6. To enable the policy, click Finish and Activate.
Integrating AirWatch MDM in Mobile IAM’s Workflow

Every time a new user is created in AirWatch MDM, the user receives an email or SMS with instructions to register his device

By following the link in the email, the user will be presented with AirWatch’s login screen and the possibility to register his or her device in the MDM system.

To integrate this workflow into Extreme Networks Mobile IAM registration workflow, enable registration in Extreme Networks Mobile IAM and link to AirWatch MDM registration page from Mobile IAM captive portal.

Once registration is enabled in Mobile IAM, the administrator can manage the different messages that the user receives during the registration process.

1. Enable web registration in NAC configuration and go to the Portal Options.

2. Select Common Page Settings > change link next to Message Strings.

3. Look for the string ‘RegistertoObtainAccess’.

To obtain network access, you must complete the Self Registration form.

We will change that string to contain a string similar to:

<h3>BYOD Self-Registration</h3>You can also register your personal device, taping here: <form action="https://apidev-ds.awmdm.com/DeviceManagement/Enrollment" method="GET">
<p></p>
GroupID
<select name="AC">
<option value="SE101">SE101</option>
</select>
<p></p>
<input type="submit" name="submit "value="Register your mobile device"></form>
<p></p>

This code will create a button that will connect to AirWatch registration page. Make sure that the url (https://apidev-ds.awmdm.com/DeviceManagement/Enrollment) is the same url being used in your deployment.

This code creates a selection for the user to select the location groups he’s been assigned in case that there are several to choose.

In the example above, the option is SE101. If there is only one location group in your deployment, you can hide this content with the following code:

<h3>BYOD Self-Registration</h3>You can also register your personal device, taping here: <form action="https://apidev-ds.awmdm.com/DeviceManagement/Enrollment" method="GET">
<p></p>
<input type=”hidden” name="AC" value="SE101">
<p></p>
<input type="submit" name="submit "value="Register your mobile device"></form>
<p></p>

The new look of the mobile registration page is changed to reflect this new code.

In this situation, the user can provide their data in the standard Mobile IAM registration form and register as a guest to the network without control of the MDM. Or they can register the mobile device tapping in the new button and being redirected to AirWatch registration page.

  1. When the device has been successfully registered with AirWatch, the Extreme Connect MDM plugin will import its data into Mobile IAM. Devices classified in MDM as Corporate owned will be place in the end-system group ‘Mobile Devices Business’ and the devices classified as Personal will be added to the group ‘Mobile Devices Personal’ (or the group defined to that end during installation or the plugin configuration, see above in installation and post installation tasks).
  2. The Mobile IAM ruleset must be adapted to reflect those groups and act accordingly depending on the newly registered devices.

Note: Devices registered by an MDM system may have an important lag until they are added to the corresponding groups. This behavior is not a malfunction of the MDM itself or the Extreme Connect MDM plugin. Due to the diversity of OSes and connectivity profiles, there is no way to know in advance when a newly registered device will provide all the data needed by the MDM software to complete the registration. It may take up to several minutes from the registration to the final landing in one of the above-mentioned groups and obtaining full access to the network.

Policy Configuration

To support the previous workflow, the device in unregistered state must be able to communicate via HTTPS with AirWatch servers and via the apple push service with Apple. Android devices require downloading an agent to be registered by AirWatch so Google Play access must be provided as well in this state.

The following policies (or more generic ones) are needed to allow Airwatch registration:

  • Allow HTTPS to 12.150.127.0/24 AirWatch network
  • Allow TCP 5223 to 17.0.0.0/8:TCP:5223, Apple Push service
  • Allow HTTPS to 74.125.0.0/16, Google Play Downloads
  • Allow TCP/UDP 5228 to 173.194.0.0/16, Google Play login

Fiberlink MaaS360

The Fiberlink MaaS360 integration requires Fiberlink authentication credentials and other account settings. This information is used in the Fiberlink MaaS360 module tab.

Module Configuration
Configuration Option Description
Username MaaS360 web service username
Password MaaS360 web service password
API URL MaaS360 web service URL, use https://services.fiberlink.com unless told otherwise by Fiberlink
Billing/Account ID MaaS360 billing/account ID
Application ID Application ID used to contact MaaS360 web service, use com.networks.extreme unless told otherwise
Application Version Use 1.0 unless told otherwise
Platform ID Use 3 unless told otherwise
Access Key Do not edit this value unless told otherwise
Server Set value to localhost

Account Billing ID: the account billing ID is used to identify the Fiberlink MaaS360 account. To find the account billing ID, log into the Fiberlink MaaS360 management page.

Service Configuration
Configuration Option Description
Poll interval Time period between queries to the MaaS360 web service
End system group for managed business mobile devices Mobile IAM end-system group that corporate owned devices will be part of
End system group for managed personal mobile devices Mobile IAM end system group that personal owned devices will be part of
Default end system group for managed mobile devices Mobile IAM end-system group that unknown devices will be part of
Remote wipe end system group Mobile IAM end-system group that will be used to remotely wipe a mobile device
Enable remote wipe Enable/disable remote wipe option
Update Kerberos username Enable/disable option to update end-system username
Update device type Enable/disable option to update end-system device type
Notify user when quarantined Enable/disable option to notify user when end-system is quarantined based on assessment scoring
Enable assessment Enable/disable option to use Mobile IAM assessment agent
Verification
  1. Enroll new device with MaaS360.
  2. Verify device is now being managed by MaaS360.
  3. Connect to test SSID, wait for re-synchronization poll to occur, and verify end system in Mobile IAM has device information from MaaS360.
Policy Configuration

To support the previous workflow, the device in unregistered state must be able to communicate via HTTPS with MaaS360 servers and via the Apple push service with Apple.

Some configurations require downloading an agent to be registered by MaaS360 so Google Play and Apple appStore access must be provided as well in this state. If this is the case, policies must be adapted to provide connectivity to the Agent.

The following policies (or more generic ones) are needed to allow MaaS360 registration:

  • •Allow HTTPS to MaaS360 network
  • •Allow TCP 5223 to 17.0.0.0/8:TCP:5223, Apple Push service
  • •Allow TCP/UDP 5228 to 173.194.0.0/16, Google Play login
  • •Allow HTTPS to 74.125.0.0/16, Google Play Downloads

JAMF Capser

The JAMF Casper integration offers provisioning of mobile devices in the network based on Casper group membership and also provides assessment data within the network access control process. In addition, data within Extreme Management Center is enriched for each end-system and offers comprehensive reporting capabilities within OneView.

Module Configuration
Service Configuration Description
Username Username used to contact the MDM provider. Must have access rights to the respective API.
Password Password used to contact the MDM provider.
Server IP IP or hostname of the MDM server.

 

General Module Configuration
Poll interval in seconds Number of seconds between connections to the MDM provider.
Module loglevel Verbosity of the module. Logs are stored in NetSightExtreme Management Control Center's server.log file.
Module enabled Whether or not the server is enabled.

 

Service Specific Configuration
Custom field to use The number of the custom data field for each end-system to store the service specific incoming data.
Full Re-Sync Interval The time after which a full data re-sync will be performed. This will also update data on devices, which are already synchronized.
Format of the incoming data for iPhones Format of the data that gets stored in the custom data field

SYNTAX EXAMPLE:
OS Version=#osVersion#; Last Inv.
Update=#lastInventoryUpdate#; Is
Managed=#isManaged#; User=#userName#; Real
Name=#realName#; Email=#email#

Available Variables:
ipAddress, mac, osVersion, lastInventoryUpdate,
isManaged, modelDisplay,
userName, realName, email,
isSecurityDataProtection, isSecurityBlockLevelEncryptionCapable, isSecurityFileLevelEncryptionCapable, isSecurityPasscodePresent, isSecurityPasscodeCompliant, isSecurityPasscodeCompliantWithProfile
Format of the incoming data for computers Format of the data that gets stored in the custom data field

SYNTAX EXAMPLE:
OS=#osName# (#osVersion#);
User=#userName#;
Real Name=#realName#;
Email=#email#;
Phone=#phone#

Available Variables:
macAddress, alternateMacAddress, osName, osVersion, ipAddress, userName, realName, email, phone
Default end-system group for all iPhones The default end-system group name to use if it is not set dynamically for all iPhones.
Default end-system group for all computers The default end-system group name to use if it is not set dynamically for all computers.
End-system group for decommissioned devices The default end-system group for decommissioned devices.
Overwrite the existing username for iPhones/iPads with the one acquired from CASPER If set to "true" the username for iPhones/iPads retrieved from CASPER will overwrite the username that is already in NAC. If no username could be retrieved from CASPER for a given end-system, then no change is performed in NAC. Be aware that this might conflict with existing NAC processes if you are already retrieving and using the username through some other mechanism like 802.1X or Kerberos snooping --> this will be overwritten.
Overwrite the existing username for MACs with the one acquired from CASPER If set to "true" the username for MACs retrieved from CASPER will overwrite the username that is already in NAC. If no username could be retrieved from CASPER for a given end-system, then no change is performed in NAC. Be aware that this might conflict with existing NAC processes if you are already retrieving and using the username through some other mechanism like 802.1X or Kerberos snooping --> this will be overwritten.
Overwrite the existing device type for iPhones/iPads with the one acquired from CASPER If set to "true" the device type (iOS) retrieved from CASPER for iPhones/iPads will overwrite the device type which is already in NAC. If no operating system could be retrieved from CASPER for a given end-system, then no change is performed in NAC. Be aware that this might conflict with existing NAC processes if you are already retrieving and using the device type through some other mechanism like DHCP snooping --> this will be overwritten. This feature should improve your current method for end-systems managed by CASPER.
Overwrite the existing device type for MACs with the one acquired from CASPER If set to "true" the device type (iOS) retrieved from CASPER for Macs will overwrite the device type that is already in NAC. If no operating system could be retrieved from CASPER for a given end-system, then no change is performed in NAC. Be aware that this might conflict with existing NAC processes if you are already retrieving and using the device type through some other mechanism like DHCP snooping --> this will be overwritten. This feature should improve your current method for end-systems managed by CASPER.
Overwrite the existing device type for Advanced Search computers with the one acquired from CASPER If set to "true" the device type (operating system) retrieved from CASPER for Advanced Search computers will overwrite the device type which is already in NAC. If no operating system could be retrieved from CASPER for a given end-system, then no change is performed in NAC. Be aware that this might mess up existing NAC processes if you are already retrieving and using the device type through some other mechanism like DHCP snooping --> this will be overwritten. This feature should improve your current method for end-systems managed by CASPER.
Import data on iPhones and iPads from CASPER If set to "true" the module will retrieve data on all iPhones and iPads managed by Casper and push it into NAC. You must set this option to “true” if you want the MDM assessment adapter to work since this data is delivered to the assessment adapter via a file.
Import data on computers (MACs) from CASPER If set to "true" the module will retrieve data on all MACs managed by Casper and push it into NAC.
Max number of days that the last inventory update for iPhones is allowed to be old For example: If set to "5" the module will alarm (if assessment is enabled) if an iPhone's last inventory update is older than 5 days.
Write assessment relevant data to an external file or not If this is set to “true”, assessment data for iPads/iPhones will be made available to the assessment adapter

 

Assessment Map Entry #
Plugin Name The Plugin ID Name
Data Field The MDM Data Field being retrieved in this test.
Force Reassessment Force Re-Assessment on content change.
Verification

To verify proper functionality validate the data within the custom field configured to use for the Casper integration in your end-system list (in NAC Manager or OneView). For each iPhone, iPad or MAC you should see information which is retrieved from Casper: If you have enabled the feature to automatically assign Casper devices (iPhones/iPads/MACs) to end-system groups in NAC based on the group name in Casper matching the end-system group name in NAC you can simply verify this functionality by opening one of the groups in OneView and validate whether the correct end-systems (=MAC addresses) are listed there.

As the Casper integration is a one-way integration there is nothing to verify on the Casper server since this integration is neither pushing data to Casper nor modifying any configuration there.

MobileIron

The MobileIron integration offers provisioning of mobile devices in the network based on device ownership and also provides assessment data within the network access control process. In addition, data within Extreme Management Center is enriched for each end-system and offers comprehensive reporting capabilities within OneView.

Module Configuration
Service Configuration Description
Username Username used to contact the MDM provider. Must have access rights to the respective API.
Password Password used to contact the MDM provider.
MobileIron Server IP IP or hostname of the MDM server.
MobileIron Webservice URL Base URL to connect to the API of the service.

 

General Module Configuration
Poll interval in seconds Number of seconds between connections to the MDM provider.
Module loglevel Verbosity of the module. Logs are stored in NetSightExtreme Management Control Center's server.log file.
Module enabled Whether or not the server is enabled.
Push update to remote service If this is set to “true”, data from other modules will be pushed to the service.
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.
Default end-system group The default end-system group name to use if an end-system is not approved yet.
Enable Data Persistence Enabling this option will force the module to store end-system, end-systemGroup 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 service specific incoming data.
End-system group for Managed Business Mobile Devices The default end-system group for corporate mobile devices.
End-system group for Managed Personal Mobile Devices The default end-system group for personal mobile devices.
End-system group for Decommissioned Mobile Devices The default end-system group for decommissioned mobile devices.
Enable Remote Wipe

If this option is enabled, devices will be wiped if they are moved to the MDM Remote Wipe End-system Group.

  • off – disabled
  • enterprise - always perform an enterprise wipe (only deletes corporate data)
  • adaptive - will perform an enterprise wipe if the device was a employee owned device and a full wipe if it was a company device\
  • full - always perform a full wipe regardless of ownership
Enable Quarantine Notification If this is set to “true”, the device will be notified via the selected mode if it is quarantined
Quarantine Notification Text Message sent in the quarantine notification to the user.
Enable Assessment If this is set to “true”, assessment data will be made available to the assessment adapter.

 

Assessment Map Entry #
Plugin Name The Plugin ID Name.
Data Field The MDM Data Field being retrieved in this test.
Force Reassessment Force Re-Assessment on content change.
Format of the incoming data Format of the data that gets stored in the custom data field SYNTAX The end-system is currently #mdmManaged# Available Variables: Please refer to the MobileIron API Documentation for a full list of all available keywords.
Update Kerberos username for end-systems If this is set to “true”, the username will be updated for each end-system and a Kerberos re-authentication is triggered.
Update custom fields for end-systems If this is set to “true”, the custom field data will be updated for each end-system.
Update devicetype for end-systems If this is set to true, the device type data will be updated for each end-system.

See MobileIron documentation for keywords available to use in custom field string.

Note: Look and feel of the MDM interface may change depending on customer’s customizations.

Creating an API User

MobileIron provides a predefined user role for API access. Assigning the API role to a user automatically enables it to access the MDM API. A user with API access must be created to access MobileIrons API from the Extreme Management Center’s interface.

  1. From MobileIron’s main interface select User Management and Add Local User.

Note: This step is not required if you plan to use an existing user or a user previously synchronized from a LDAP database.

  1. Fill in the required fields and note the user ID and password for later use in Extreme Management Center configuration.
  2. After creating a user, select it and click Assign Roles.

Once registration is enabled in Mobile IAM, the administrator can manage the different messages that the user receives during the registration process.

  1. 1. To perform this configuration, enable web registration in NAC configuration and go to Portal Options.
  2. 2. In Portal Options, select Common Page Settings and then click the ‘change’ link next to Message Strings.
  3. 3. Look for the string ‘RegistertoObtainAccess’.
    To obtain network access, you must complete registration using the self registration form.
    We will change that string to contain something like:

<h3>BYOD Self-Registration</h3>You can also register your personal device, taping here: <form action="https://<Mobileironserver>/<customername>/ireg" method="GET"><input type="submit" name="submit "value="Register with MobileIron"></form>

This code will create a button that will connect to MobileIron’s registration page. Make sure that the url https://<Mobileironserver>/<customername>/ireg is the same being used in your deployment.

  1. The new look of the mobile registration page is changed to reflect this new code.
    In this situation, the user can provide his or her data in the standard Mobile IAM registration form and register as a guest to the network without control of the MDM. Or they can register the mobile device tapping in the new button and being redirected to MobileIron’s registration page.
  2. After providing the required credentials, the user will be prompted to install a configuration profile granting the MDM software the required permissions to manage the device.
  3. After completing the registration, several profiles will be installed under General > Profiles.
    When the device has been successfully registered with MobileIron, the Extreme Connect MDM plugin will import its data into Mobile IAM. Devices classified in MDM as Corporate owned will be place in the end-system group ‘Mobile Devices Business’ and the devices classified as Personal will be added to the group ‘Mobile Devices Personal’ (or the group defined to that end during installation or the plugin configuration, see above in installation o post installation tasks).
  4. The Mobile IAM ruleset must be adapted to reflect those groups and act accordingly depending on the newly registered devices.

Note: Devices registered by an MDM system may have an important lag until they are added to the corresponding groups. This behavior is not a malfunction of the MDM itself or the Extreme Connect MDM plugin. Due to the diversity of OSes and connectivity profiles, there is no way to know in advance when a newly registered device will provide all the data needed by the MDM software to complete the registration. It may take up to several minutes from the registration to the final landing in one of the above-mentioned groups and obtain full access to the network.

Policy Configuration

To support the previous workflow, the device in unregistered state must be able to communicate via HTTPS with MobileIron servers and via the apple push service with Apple.

Some configurations require downloading an agent to be registered by MobileIron so Google Play and Apple appStore access must be provided as well in this state. If this is the case, policies must be adapted to provide connectivity to the Agent.

The following policies (or more generic ones) are needed to allow MobileIron registration:

  • Allow HTTPS to MobileIron network
  • Allow TCP 5223 to 17.0.0.0/8:TCP:5223, Apple Push service
  • Allow TCP/UDP 5228 to 173.194.0.0/16, Google Play login
  • Allow HTTPS to 74.125.0.0/16, Google Play Downloads
Other Integration Options

The integration described in the previous section is one of many possible ways. The different methods will vary depending on specific requirements of the enterprise deploying the MDM-IAM integration.

Sophos Mobile Control

The Sophos Mobile Control integration requires authentication credentials and other account settings. This information is used in the Sophos MDM module tab and supports Mobile Control version 4.0.

Module Configuration
Configuration Option Description
Customer Customer name
Username Web service username
Password Web service password
Server Server hostname or IP address. The server value is used to create the web service URL: https:<server>/mdmWebService
Service Configuration
Configuration Option Description
Poll interval: Time period between queries to the Sophos web service
End system group for managed business mobile devices Mobile IAM end-system group that corporate owned devices will be part of
End system group for managed personal mobile devices Mobile IAM end system group that personal owned devices will be part of
Default end system group for managed mobile devices Mobile IAM end-system group that unknown devices will be part of
Remote wipe end system group Mobile IAM end-system group that will be used to remotely wipe a mobile device
Enable remote wipe Enable/disable remote wipe option
Update Kerberos username Enable/disable option to update end-system username
Update device type Enable/disable option to update end-system device type
Notify user when quarantined Enable/disable option to notify user when end-system is quarantined based on assessment scoring
Enable assessment Enable/disable option to use Mobile IAM assessment agent

Verification

  1. Enroll new device with Sophos.
  2. Connect to test SSID and wait for re-synchronization poll to occur.
  3. Verify end system in ExtremeControl has device information from Sophos.
Policy Configuration

To support the previous workflow, the device in unregistered state must be able to communicate via HTTPS with Sophos server and via the Apple push service with Apple.

Some configurations require downloading an agent to be registered by Sophos so Google Play and Apple appStore access must be provided as well in this state. If this is the case, policies must be adapted to provide connectivity to the Agent.

The following policies (or more generic ones) are needed to allow Sophos registration:

  • Allow HTTPS to Sophos network
  • Allow TCP 5223 to 17.0.0.0/8:TCP:5223, Apple Push service
  • Allow TCP/UDP 5228 to 173.194.0.0/16, Google Play login
  • Allow HTTPS to 74.125.0.0/16, Google Play Downloads

Citrix XenMobile

The XenMobile integration requires authentication credentials and the XenMobile server base URL. This information is used in the XenMobile module tab.

Module Configuration
Configuration Option Description
Username Web service username
Password Web service password
Server Base URL of XenMobile server. Base URL is used to create the web service URL i.e. <base URL>/xenmobile/api/v1/device/filter
Service Configuration
Configuration Option Description
Poll interval Time period between queries to the XenMobile web service
End system group for managed business mobile devices Mobile IAM end-system group that corporate owned devices will be part of
End system group for managed personal mobile devices Mobile IAM end system group that personal owned devices will be part of
Default end system group for managed mobile devices Mobile IAM end-system group that unknown devices will be part of
Remote wipe end system group Mobile IAM end-system group that will be used to remotely wipe a mobile device
Enable remote wipe Enable/disable remote wipe option
Update Kerberos username Enable/disable option to update end-system username
Update device type Enable/disable option to update end-system device type
Notify user when quarantined Enable/disable option to notify user when end-system is quarantined based on assessment scoring
Enable assessment Enable/disable option to use Mobile IAM assessment agent
Format of the incoming message Format of the custom data string. Available fields are:
id
serialnumber
imei
username
ownership
devicename
devicemodel
devicetype
operatingsystem
lastseen
enrollmentstatus
compliancestatus
macaddress
jailbroken
Verification
  1. Enroll new device with XenMobile.
  2. Connect to test SSID, wait for re-synchronization poll to occur.
  3. Verify end system in ExtremeControl has device information from XenMobile.
Policy Configuration

To support the previous workflow, the device in unregistered state must be able to communicate via HTTPS with the XenMobile server and via the Apple push service with Apple.

Some configurations require downloading an agent to be registered by XenMobile so Google Play and Apple appStore access must be provided as well in this state. If this is the case, policies must be adapted to provide connectivity to the Agent.

The following policies (or more generic ones) are needed to allow XenMobile registration:

  • Allow HTTPS to XenMobile network
  • Allow TCP 5223 to 17.0.0.0/8:TCP:5223, Apple Push service
  • Allow TCP/UDP 5228 to 173.194.0.0/16, Google Play login
  • Allow HTTPS to 74.125.0.0/16, Google Play Downloads