AirWatch Relay Server FAQ

Q: What sort of data should we use caution with on an FTP server in the public cloud?

A: The FTP protocol commands are sent in plain text. FTP username and password is all that is required to access files on basic system. FTP is an RFC standard and is supported by nearly every OS platform. Modern FTP servers support a variety of methods to increase the security around the data connections. The most common solution is the introduction of FTP over TLS to encrypt FTP sessions.  The AirWatch Console and agent are compliant with FTP RFC 959 and the FTP over TLS RFC 4217.

 

Q: What are the following file types that I find stored on my relay servers? And elaborate on what information it contains.

A: The file types are:

  • *.apd – Dynamic Application file.  The .APD is a legacy file manifest that allows mobile devices to install content by examining the contents of the .APD file in the root of an FTP file folder. A sub folder will contain the files used by the .APD and will have the same folder name as the filename.apd
  • *.bdl – Bundle file.  The bundle is an instruction file used to direct a device to a given .APD. The name of the bundle is contained in the staging profile and directs the device to the agent and settings.
  • *.bin – Binary file.  The credential .BIN holds the username and password required to enroll via barcode staging or side load.

 

Q: How are enrollment credentials protected?

A: These credentials are in a .BIN binary file format and is not human readable.

 

Q: Are enrollment credentials stored on the relay server in any form?

A: These credentials are in a .BIN binary file format and is not human readable.

 

Q: Does AirWatch push enrollment data to all relay servers, or only the relay servers that are selected during a staging profile setup?

A: You can configure Relay Servers to only receive staging content, production content, or both. All Staging Relay servers receive all staging content, as the UUID of the device is not known yet to direct individualized content. Production servers can be more selective. When a device in a child organization group with a Relay server is sent a job, a list of all available relay servers will be included going up the tree toward global. The device will first try the local relay server, and if timeout or failure will try the next FTP entry in the list.

An enrollment package goes to all relay servers up the chain if there are any staging servers in the hierarchy.

 

Q: Are profiles (either standard or product provisioning) stored on the relay server?

A: Profiles do not get stored on the relay server; they directly apply on the device.

 

Q: If I pushed out a profile that contained static Wi-Fi password would this be stored on the relay server?

A: Profiles do not get stored on the relay server; they directly apply on the device.

 

Q: If data is encrypted on the relay server, can you describe the process?

A: We do not encrypt data on the Relay Server explicitly.

 

Q: Can you comment on what exposure we might have if an FTP server were breached?

A: Generally, these are hosted on-premises. If a breach occurs, it will give access to the files on the Relay Server. These would typically be job files, which are instructions and not sensitive information. Additionally, they may find proprietary applications that client deploys to devices.

 

Q: What is the time out value for the relay server in minutes/seconds?

A: Once the URL is entered, if the connection is idle (i.e. not pulling 10bytes /sec), the connection will abort after 120 sec (2min).

  • If we have multiple relay servers, and device is trying connecting to the child relay server, what would be the timeout value?
    • 2 Minutes
  • How long will the device try to connect to the relay server, before heading to the parent relay server?
    • If the device can connect but cannot perform the operation specified in the manifest list, the device will attempt the action 5 times to contact the Relay server and then move to the next RS in the list.

 

Q: After how many attempts will the device try the next relay server?

A: The retry logic is as follows: 

  • The FTP retry count for each relay server entry is 5 and it is not configurable.
  • The FTP retry count from the AW Server to the FTP/FTPS server is 3 and is configurable.
  • The SFTP retry count from the AW server to the SFTP server is currently not set but defaults to 3.

 

Q: After how many tries does the server attempt the Device Services server?

A: After all the Relay servers in the Manifest list are attempted, the device will then change protocols to HTTPS and attempt to pull the file from the DS endpoint.

  • If the device fails to get the file from all the relay servers in the hierarchy, how many times will the device try to obtain the file from the device services server?
    • Devices access the DS Endpoint access using a Webrequest class. The framework does not have a defined retry count. It is up to the caller of httpost within the awwebrequest to define the retry

 

Q: Does the device perform multiple attempts on the Device Services server before marking the product as failed?

A: Devices access the DS Endpoint access using a Webrequest class. The framework does not have a defined retry count. It is up to the caller of httpost within the awwebrequest to define the retry.

 

Q: Are there any specific versions of centOS we support, or do we extend support to all of their versions?

A: We do not validate against any specific OS. It’s the FTP server that matters. It must adhere to the public FTP standards. However, for the Pull Service which works in conjunction with the FTP servers, we are in the process of qualifying it for different Linux OSes.

Have more questions? Submit a request

0 Comments

Article is closed for comments.