Systems for providing device-specific access to an e-mail server

Systems and methods herein can provide device-specific access to an e-mail server, including an EWS-based e-mail server. In an example, a management server controlled by a system administrator provides device identification information to a user device and to a tunnel server. The management server also provides a custom request identifier to the tunnel server, and provides instructions to the e-mail server to allow access for requests including that custom request identifier. The tunnel server receives a request from the user device, rewrites the request to include the custom request identifier, and passes the request to the e-mail server.

BACKGROUND

Systems for managing mobile devices, such as Enterprise Mobility Management (“EMM”) and Mobile Device Management (“MDM”) systems, typically rely on the built-in functionality of an e-mail server and its associated communication protocol to control access for enrolled mobile devices.

For example, MICROSOFT's Exchange ActiveSync (“EAS”) is a communications protocol that provides mobile device management, policy controls, and synchronization of e-mail and other information between a server and a mobile device. EAS-based e-mail servers utilize a unique identification number for each device and mail client that connects. Because EAS-based e-mail servers recognize individual devices and mail clients based on a unique identification number, a system administrator can decide to allow or block access to the e-mail server on a device-by-device basis and for particular mail clients. In other words, the system administrator can instruct the EAS-based e-mail server to allow or block requests associated with particular unique identification numbers.

However, this type of device-specific control only exists for certain e-mail clients. Other e-mail clients—such as OUTLOOK for Mac, Mail for Mac, and others—access e-mail servers utilizing protocols that lack device-specific control. For example, OUTLOOK for Mac and Mail for Mac currently leverage MICROSOFT's Exchange Web Services (“EWS”) instead of EAS. Unlike EAS e-mail clients, client requests to an EWS-based e-mail server do not include a unique request identifier that identifies the particular device requesting access. As a result, a system administrator cannot choose to allow or block specific devices. At best, the system administrator can only choose to allow or block a particular type of e-mail client as a whole. This lack of granularity in control is not satisfactory.

For example, a system administrator of an EMM system would like to be able to grant or deny access to an EWS-based e-mail server based on the device's compliance and enrollment statuses. But without a way to uniquely identify the device requesting access to the EWS-based e-mail server, this level of control is unavailable.

A need exists for systems and methods for providing device-specific access to an e-mail server, including an EWS-based type of e-mail server, among others.

SUMMARY

Examples described herein include systems and methods for providing device-specific access to an e-mail server, including an EWS-based e-mail server. Although the discussion herein references EWS and EWS-based e-mail servers, these terms are intended to encompass any e-mail server that does not utilize unique request identifiers for a particular device requesting access to the server. For example, EWS-based e-mail servers use request identifiers for identifying the type of e-mail client requesting access, rather than identifying the particular device requesting access. In the case of EWS-based e-mail servers, the request identifier is a user agent string. The terms “request identifier” and “user agent string” are used interchangeably throughout this disclosure, and the term “user agent string” is intended to refer to any request identifier used by an e-mail server to determine, by default, the type of e-mail client connecting to the e-mail server. Each e-mail client has a unique user agent string known to the EWS-based e-mail server. Based on the user agent string, an EWS-based e-mail server can determine which type of e-mail client (for example, OUTLOOK for Mac) is being used to connect to the server. But the server cannot distinguish particular user devices based on their requests.

Some e-mail servers, including EWS-based e-mail servers, can enforce an “allow list” or a “block list” based on the request identifier or user agent string. In additional to enforcing allow and block lists, those e-mail servers can provide an administrator with the ability to allow or block non-default request identifiers, such that an administrator could create a new user agent string and place it on an allow list or a block list.

In an example, a system is provided for improving the functionality of an EWS-based server to customize the user agent string of outgoing requests from an EWS-enabled client and also place the custom user agent string on an allow list for the server. In that way, the system can provide device-specific access to an EWS-based server.

More specifically, an example system is provided that includes a user device, a management server in electronic communication with the user device, and a tunnel server. The management server can be controlled by a system administrator and can provide device identification information to the user device. The device identification information can allow internal system servers to identify the particular user device. The device identification information can include, for example, an authentication certificate, an expected (default) user agent string, and in some cases a custom user agent string. The tunnel server can provide secure access to or from the user device through a Virtual Private Network (“VPN” or “per-app VPN”). A per-app VPN allows for centralized connections from managed e-mail clients within the system. For example, a VPN connection can be created for each e-mail client.

The tunnel server provides a secure channel to connect with any per-app VPN(s) requesting access to an e-mail server. The tunnel server can also receive, from the management server, the device identification information associated with a user device. The device identification information allows the tunnel server to identify the particular user device upon receiving a request from the user device for access to the e-mail server. The tunnel server can assign, replace, or rewrite a custom user agent string in place of the default user agent string in the request. The tunnel server can also provide the e-mail server with the modified request from the user device, including the custom user agent string.

Because the custom user agent string differs from the default user agent strings associated with known e-mail clients, an EWS-based e-mail server typically would not allow access based on a custom user agent string. This can be solved by identifying the custom user agent string to the EWS-based e-mail server. In one example, the management server provides the custom user agent string to the e-mail server, including instructions to allow access to the server for requests including that custom user agent string. The management server can then also provide the custom user agent string to the tunnel server for association with one or more user devices that are allowed access to the e-mail server. In another example, the tunnel server (rather than the management server) provides the identification and instructions to the e-mail server. The tunnel server can also receive a response from the e-mail server and pass the response back to the user device.

Based on compliance and enrollment statuses of the managed user devices, the management server can update a whitelist or blacklist at the EWS-based email server or tunnel server to block or allow email access for the user devices.

DESCRIPTION OF THE EXAMPLES

FIG. 1Aprovides an illustration and accompanying description of an example system for providing device-specific access to an e-mail server.FIG. 1Bprovides an example disclosure of system components for device enrollment and compliance monitoring, which can be implemented in various embodiments described throughout the specification.FIG. 2provides a more detailed example of a system for providing device-specific access to an e-mail server, utilizing a tunnel server for additional security and control.FIG. 3provides an example method that can encompass any system or method for providing device-specific access to an e-mail server, including those inFIGS. 1A and 2.FIG. 4provides an example administrator console that can be used by a system administrator to efficiently implement, update, and otherwise change the settings for any system or method for providing device-specific access to an e-mail server. Finally,FIG. 5provides an example method for providing device-specific access to an EWS-based e-mail server using a custom user agent string.

Turning toFIG. 1A, an illustration of an example system100is shown for providing device-specific access to an e-mail server140. In some examples, the e-mail server140ofFIG. 1can be an EWS-based e-mail server. However, the e-mail server140can be any type of e-mail server. For example, the e-mail server140can be any e-mail server that does not utilize unique, per-device request identifiers for incoming server requests by default.

A system administrator110can manage the operations of system100. The system administrator110can also be referred to as a sysadmin or a system operator. In either case, the system administrator110can have the ability to allow or block particular user devices130from accessing the e-mail server140. This can include setting access rights for groups of users, to which many user devices130belong.

User devices130can include any computing device, such as a cell phone, laptop, tablet, personal computer, or workstation. A user device130can include a non-transitory computer-readable medium containing instructions that are executed by a processor. Example non-transitory, computer-readable mediums include RAM and ROM, disks, and other memory and storage that is accessible by a USB port, a floppy drive, CD-ROM, or DVD-ROM drive, and a flash drive, among others. Furthermore, although the term “user devices” is used in its plural form at times when describing system100, the system100can function with just a single user device130. Therefore, the terms “user device” and “user devices” are used interchangeably, as appropriate.

The user devices130can be enrolled with a management server120. The management server120can be part of an overall EMM or MDM system, and can include multiple servers, processors, and computing devices. In some examples, the management server120is a network of servers, some of which can be located remotely from one another. In another example, the management server120is a single server with multiple purposes. In yet another example, the management server120is a server (or group of servers) dedicated to the operations described herein.

The system administrator110can have privileges associated with managing, editing, revising, and otherwise administrating the management server120. These functionalities, along with enrollment and compliance in general, are described in more detail with respect toFIG. 1B. These details will be explained with reference toFIG. 1Bbefore returning to the discussion ofFIG. 1A.

FIG. 1Bincludes a management server120and a user device130. The management server120can monitor and manage the operation of user devices130, through the management server120itself, or more specifically, through a management service or program installed on the management server120. Although one user device130is shown, the management server120can monitor and manage the operation of multiple user devices130enrolled in a device management service. The management server120can also provide access to email, calendar data, contact information, and other enterprise resources to enrolled user devices130.

The management server120can include an enrollment component121and an administrator component122, which can both be used for the process of enrolling user device130. For example, a user device130can communicate with the enrollment component121during the initial stages of enrollment. In some examples, the enrollment component121can provide a token to the user device130indicating that the user device130has been authenticated and is permitted to communicate and enroll with the management server120. The management server120or enrollment component121can provide the user device130with information regarding how to access and communicate with the administrator component122in order to continue the enrollment process.

In some examples, the administrator component122can request a token from the user device130, indicating that the user device130has been authenticated and is permitted to continue the enrollment process with the administrator component122. Upon receiving the token, the administrator component122can continue the enrollment process. The administrator component122can also provide a console for an administrator to configure and monitor the status of the user device120and the enrollment process. In some examples, the administrator component122can be dedicated to a particular enterprise or group of enterprises, while the enrollment component121can be shared across multiple different enterprises.

Management server120can include one or more organizational groups123. An organizational group123can include data representing a group of user devices130managed by the management server120. An organizational group123can correspond to a structure or hierarchy of a business or enterprise. For example, an enterprise can have various groups such as an engineering team, an accounting team, and a marketing team. Each of these teams can correspond to an organizational group123stored on the management server120.

In addition to corresponding to a business team, an organizational group123can correspond to user devices130positioned in a particular geographic location. For example, a business can have different business locations, such as a public waiting room, private conference room, a laboratory, office space, and a parking garage. In this example, separate organizational groups123can be established for each of the public waiting room, private conference room, laboratory, office space, and parking garage. User devices130positioned in one of these locations can be included in the respective organizational group123.

The management server120can also include compliance rules124. A compliance rule124can set forth one or more conditions that must be satisfied in order for a user device130to be deemed compliant. If compliance is broken, the management server120can take steps to control access of the user device130to enterprise files and email. Compliance rules can be assigned differently to the different organizational groups123. For example, a developer group can be assigned different compliance rules124than an executive group. The executive group might be allowed to install different applications than the development group. Similarly, the management server120can assign different compliance rules124based on the different location-based organizational groups123.

The determination of whether a user device130is compliant can be made by the management server120, the user device130, or a combination of both. For example, the management component132on the user device130can generate a data object that describes the state of the user device130, including any settings, parameters, applications, or other information regarding the state of the user device130. The data object can be analyzed by the management server120or the user device130to determine whether the user device130is in compliance with compliance rules124. In the case of the user device130analyzing compliance, a management component132installed on the user device130can make the comparison between the data object and compliance rules124.

In one example, a compliance rule124can specify that a particular application is required to be—or prohibited from being—installed on a user device130. In another example, a compliance rule124can specify that a user device130must be located in a secure location in order to comply with the compliance rule124. This can be useful where greater or less access is desired in a particular location, such as allowing secured access while on an enterprise premises. In yet another example, a compliance rule124can specify that a user device130must be locked, such that a passcode or other credential is required, any time the user device130is accessed from a locked, sleeping, or off position.

Compliance rules124can also be based on time, geographical location, or device and network properties. For example, a compliance rule124can be based on the time or date, or both, matching specified values. In another example, the compliance rule124can require the user device130to be located in a particular geographic area. In another example, the compliance rule124can require the user device130to be connected to a particular local area network or wireless network, such as the network(s) located on the premises of an enterprise.

In some examples, a compliance rule124can require that a user device130be turned on, turned off, locked, unlocked, asleep, or awake during a particular time period. In another example, a compliance rule124can prohibit a user device from rendering content that has been designated as confidential relative to that particular user device130. The determination of whether the content is confidential can be made, for example, based on the organizational group123to which the user device130belongs at the time. In fact, the organizational group123to which the user device130belongs can be used as a basis for any compliance rule124, as appropriate.

The management server120can also include management policies125that direct the management of a user device130. For example, a management policy125can specify which resources can be made available to a user device130from the management server120. This can include, for example, specifying that the management server120is permitted to provide an e-mail service to the user device130.

In some examples, the management policies125can specify the compliance rules124with which a user device130is required to comply. A compliance rule124can be assigned to one or more management policies125. In some examples, a compliance rule124can be assigned to a particular organizational group123. The management policy125can specify how the user devices130associated with that organizational group123are to be managed. For example, the management policy125can specify certain activities or functions that are required from, or prohibited by, user devices130associated with a particular organizational group123.

The management component132can be a portion of an operating system for the user device130, or it can operate in the application layer of the user device130. For example, the management component132can be a dedicated application or other software installed on the user device130that can monitor and manage data, software components, and hardware components associated with the user device130. The management component132can monitor and control functionality and other managed applications on the user device130. The management component132can also determine whether a compliance rule124is, or has been, satisfied by the user device130.

In some examples, the management component132can parse a data object describing the state of the user device130, including various settings of the user device130as well as actions it has taken. Based on the data object, the management component132can determine whether various compliance rules124have been satisfied. In some examples, the management component132can communicate with the management server120to determine whether the compliance rules124are satisfied by the user device130. For example, the management component132can cause the data object to be transmitted to the management server120to facilitate that determination.

The management component132can be an application, or portion of an application, that provides functionality beyond simply monitoring and managing resources in the user device130. In one example, the management server120can provide a software development kit (SDK) that a developer can use to insert, for example, security libraries into the application. In another example, a developer can incorporate libraries and other components through a process of “wrapping.” To wrap an application, a developer can decompile the application, insert the libraries or other components, and then recompile the application. When a library is incorporated into an application, the functionality provided by the library can be called by the management component132executing in a user device130. For example, if a security library provides the ability to monitor and enable or disable functionality provided by an application, the management component132can call functions provided by the library to monitor and enable or disable the functionality.

A management policy125can specify that a user device130has permission to perform or access certain functionality by virtue of that user device130being associated with an organizational group123. For example, a management policy125can be created without reference to a particular user device130. Instead, the management policy125can be associated with an organizational group123. The organizational group123can change over time and include different user devices130over time. But because the management policy125is associated with the organizational group123rather than the any particular user device130, the management policy125can apply to all user devices130within the organizational group123at any given time.

In one example, a user device130can become a member of, or become associated with, an organizational group123when an administrator specifies that the user device106should be a member. In another example, a user device130becomes associated with an organizational group123when a membership condition is satisfied, such as through a dynamic evaluation of the membership condition. A membership condition can be created by an administrator110by specifying a condition relating to the user device130that, when satisfied, causes the user device130to be associated with the organizational group123. Similarly, the membership condition can be created such that when a condition relating to the user device130is met (or not met), the user device130is removed from the organizational group123.

Alternatively, a user device130can become disassociated with an organizational group123based on the user of the user device130. For example, an administrator110or dynamic evaluation can identify an individual for additional to, or removal from, an organizational group123. If the user operates multiple user devices130, all of the user's user devices130can be added to, or removed from, the organizational group123of interest. In this way, all of the user's user devices130can be made subject to a uniform set of management policies125and compliance rules124.

In some examples, a management policy125can be associated with a compliance rule124. More specifically, a compliance rule124can specify a compliance condition and an action that should be taken by the management server120if the compliance condition is either met or not met. In one example, a compliance rule124can include a rule condition for an attempt by a user to access confidential resources. The compliance rule124can be configured to recognize this attempt to thwart a management policy125, and can cause remedial action to be taken. For example, the compliance rule124or management policy125can cause the user device130to be locked or otherwise blocked from accessing particular information.

As part of the enrollment or management of a user device130, an administrator110can create a device record for the user device130. The device record can be stored on the management server120, and can include data related to the management of the user device130. For example, the device record can include data describing one or more of: the identity and type of the user device130; components of the user device130; the state of the user device130; organizational groups123to which the user device130belongs; compliance rules124with which the user device130must comply; and management policies125that specify if, when, and how the user device130is permitted to function.

For example, data describing the identify and type of the user device130, as well as the components of the user device130, can include at least one or more of: a unique identifier associated with the user device130; a device type of the user device130(e.g., a smartphone, a tablet computing, a laptop computer, a desktop computer, a server computer, or a virtualized instance of any of such computer types); and various software and hardware components of the user device130(e.g., operating system (or kernel or bios) type and version, processor type and speed, memory type and size, network interface types, various I/O component types such as camera, touchscreen, keyboard, mouse, printer).

With respect to data describing the state of the user device130, such data can include can specify, for instance, various settings that are applied to the user device130, various applications that are installed on or being executed by the user device130, and various files that are installed on or are accessible to the user device130. Additionally, the data describing the state of the user device130can specify information related to the management of the user device130, such as the last time the user device130provided data describing its state to the management server120. The data can also describe whether the user device130is in a state of compliance with any applicable compliance rules124, and whether any remedial actions have been (or are to be) taken as a result of a noncompliance with any applicable compliance rules124.

The data describing organizational groups123to which the user device130belongs can, for example, include any organizational groups123of which the user device130is a member, either by virtue of a hard-coded relationship between the user device130and the organizational group123, or by virtue of a dynamic evaluation of a membership condition associated with the organizational group123.

The data describing compliance rules124with which the user device130must comply can, for instance, specify one or more remedial actions that should be performed in the event that an associated rule condition occurs. Data describing management policies125can include permissions of the user device130, such as access rights, and settings that are being enforced upon the user device130. In some examples, the data describing compliance rules124and the data describing management policies125can be obtained from an organizational record associated with an organizational group123to which the user device130is a member.

In some examples, an administrator110can manually input data into the administrator component122in order to generate a device record for a user device130. In other examples, the administrator component122can obtain a data object, such as an electronic spreadsheet, extensible markup language (XML) file, or comma separated values (CSV) file. The administrator component122can extract information describing the user device130from the data object to create a corresponding device record. The device record for each user device130can include information identifying each user device130and its respective device record.

In some examples, after the administrator component122creates a device record for a user device130, the management server120can detect whether the user device130is enrolled. For example, the management server120can determine whether a flag is set, indicating that the user device130is enrolled.

If the user device130is not yet enrolled, the management server120can automatically transmit information identifying the user device130to the enrollment component121. For example, the user device130can transmit a device identifier, such as its media access control (MAC) address, to the enrollment component121. In some examples, when the enrollment component121receives the device identifier, the enrollment component121can determine whether a corresponding device record exists. If there is no corresponding device record, the enrollment component121can determine that the user device130is not authorized to enroll.

Turning back toFIG. 1A, the management server120can track each enrolled user device130and distinguish particular actions, or inactions, among the various enrolled user devices130. For example, the management server120can store a registry with information relating to each enrolled user device130. The registry can include additional information assigned by the management server120. An example of additional information would be an authentication certificate or token. The management server120can provide the authentication certificate or token to the user device130and to other components of the system100, thereby identifying requests to or from a user device130as being associated with that particular device.

The management server120can also provide information to an e-mail server140within the system100. For example, the management server120can provide the e-mail server140with information regarding a custom user agent string to be placed on an allow list. In some examples, the management server120first confirms that a particular user device130is enrolled with the system. This can be accomplished by, for example, accessing a data object associated with the enrollment component121or the administrator component122(shown inFIG. 1B) of the management server120. The management server120can also confirm that the user device130is complying with all applicable compliance rules124(shown inFIG. 1B) relevant to the user device130. This can be accomplished by, for example, accessing a data object associated with the compliance rules124or management policies125(shown inFIG. 1B). In some examples, the management server120can request a new or updated data object reflecting the current state of the user device130, to ensure that enrollment and compliance are up to date.

Although the e-mail server140is shown as part of system100, it may be a third-party server, or group of servers. For example, e-mail server140can be an EWS-based server provided by MICROSOFT. In another example, e-mail server140can be an EWS-based server run by the entity implementing the management server120. E-mail server140need not be EWS-based. For example, e-mail server140can be an e-mail server utilizing a communication protocol (other than EWS) that lacks the default functionality to provide or recognize unique request identifiers on a per-device level.

The system administrator110can provide instructions and other information to both the e-mail server140and the management server120. For example, the system administrator110can instruct the e-mail server140to enforce an allow list and a block list. In one example, the allow list includes one or more request identifiers. That is, the allow list includes a request identifier that would typically be associated with, and included in, a certain type of request. In the case of an EWS-based e-mail server, the request identifier can be a user agent string. In one example, the request identifier corresponds to a particular e-mail client installed on a user device130. For example, all requests coming from an OUTLOOK for Mac e-mail client can have the same request identifier, and that request identifier can be placed on an allow or block list by the system administrator110.

The system administrator110can also place custom request identifiers on an allow or block list at the e-mail server140. For example, the system administrator110can cause the management server120to generate and assign a custom request identifier to a particular user device130. As discussed in more detail below, the management server120can cause all requests from a single user device130to the e-mail server140to include the custom request identifier. In the example of an EWS-based e-mail server140, the custom request identifier can be a custom user agent string. If the custom request identifier is on an allow list at the e-mail server140, the request is allowed access to the e-mail server140.

Several options can be used to provide a custom request identifier for a request from a user device130to the e-mail server140. InFIG. 1, the management server120can generate a custom request identifier and assign it to a particular user device130. The management server120can also send instructions to the e-mail server140, instructing the e-mail server140to place the custom request identifier on an allow list.

In order to utilize the custom request identifier, a request from a user device130needs to be modified in some way to replace the default request identifier with the custom request identifier. In the example ofFIG. 1, the management server120provides the user device130with the capability to implement the custom request identifier at the device level. For example, the management server120can provide the user device with instructions to replace the default request identifier with a custom request identifier selected by the management server120. The user device130can accordingly alter each of its request identifiers as directed by the management server120. In some examples, this can be accomplished by a management component132(as shown inFIG. 1B) installed on the user device130. The management component132can parse data flowing to or from the user device130, identifying and modifying requests as desired. Due to the potential security risk of providing the user device130with a whitelisted custom request identifier, the management server120can use an encryption algorithm or service to prevent unwanted discovery of the custom request identifier.

Continuing the example ofFIG. 1, the user device130can receive a custom request identifier from the management server120and incorporate it into any outgoing requests to the e-mail server140. The e-mail server140can recognize the custom request identifier, based on previous instructions obtained from the management server120, and therefore authorize access. The e-mail server can then return a response to the user device130.

If a user device130is later un-enrolled from the system100, the management server120can prevent the user device130from continuing to use the custom request identifier. For example, the management server120can wipe the custom request identifier from the user device130. In some examples this can be done as part of removing any EMM or MDM software associated with enrollment in the system100. The management server120can also remove or disable access for the custom request identifier at the e-mail server140.

FIG. 2provides a representation of a system200for providing device-specific access to an e-mail server140with an added layer of security relative to the system100ofFIG. 1. As inFIG. 1, the e-mail server140ofFIG. 2can be any type of e-mail server, including an EWS-based e-mail server. More particularly, the e-mail server140can be any e-mail server that does not utilize unique, per-device request identifiers for incoming server requests by default.

A system administrator110can manage the operations of system200, and can have the ability to allow or block particular user devices130from accessing the e-mail server140. The user devices130ofFIG. 2can include any computing device, such as a cell phone, laptop, tablet, personal computer, or workstation. Regardless of whether the user devices130are referred to in a singular or plural manner, the terms are intended to be used interchangeably, as appropriate. System200can function with just a single user device130, or with many user devices130.

The user devices130can be enrolled with a management server120in the same manner described above with respect toFIG. 1. That is, the management server120can be part of an overall EMM or MDM system, and can include multiple servers, processors, and computing devices. In some examples, the management server120is a network of servers, some of which can be located remotely from one another. In another example, the management server120is a single server with multiple purposes. In yet another example, the management server120is a server (or group of servers) dedicated to the operations described herein.

The system administrator110can have privileges associated with managing, editing, revising, and otherwise administrating the management server120. For example, the system administrator110can determine which devices130to enroll or un-enroll. The system administrator110can also make determinations regarding which applications an enrolled user device130is allowed to download or utilize while enrolled with the management server120. For example, the system administrator110can allow a new employee to enroll his or her device130and download EMM-related applications providing access to secure document storage locations and a secure e-mail server140.

The management server120can track each enrolled user device130and distinguish particular actions, or inactions, among the various enrolled user devices130. For example, the management server120can store a registry with information relating to each enrolled user device130. The registry can include additional information assigned by the management server120. An example of additional information would be an authentication certificate or token. The management server120can provide the authentication certificate or token to the user device130and to other components of the system200, thereby identifying requests to or from a user device130as being associated with that particular device.

The management server120can also provide information to an e-mail server140within system200. For example, the management server120can provide the e-mail server140with information regarding a custom user agent string to place on an allow list. Although the e-mail server140is shown as part of system200, it may be a third-party server, or group of servers. For example, e-mail server140can be an EWS-based server provided by MICROSOFT. In another example, e-mail server140can be an EWS-based server run by the entity implementing the management server120. E-mail server140need not be EWS-based. For example, e-mail server140can be an e-mail server utilizing a communication protocol (other than EWS) that lacks the default functionality to provide or recognize unique request identifiers on a per-device level.

As depicted inFIG. 2, the management server120can also connect to a tunnel server250. Although the tunnel server250is depicted and discussed as a single server, it can include multiple servers, processors, and computing devices. In some examples, the tunnel server250is a network of servers, some of which can be located remotely from one another. The tunnel server250can provide a centralized connection between the user devices130and the e-mail server140. The user devices130can establish a secure connection to the tunnel server250using, for example, a per-app VPN. In some examples, the tunnel server250is dedicated to handling traffic between the user devices130and the e-mail server140.

The management server120can connect to the tunnel server250and provide various types of information regarding the user devices130, e-mail server140, and expected requests. For example, the management server120can provide device identification information for one or more of the user devices130. The device identification information can include, for example, an authentication certificate for the user device130that, when compared to an authentication certificate provided by the user device130itself, identifies the particular user device130to the tunnel server250. Any other type of authentication may be used as well, such as tokens, certificates, or passwords. The device identification information can also include an expected or default request identifier; for example, a default user agent string for the e-mail client installed on the user device130. The device identification information can also include a custom request identifier, such as a custom user agent string, to be used for requests originating from a particular user device130.

In an example, the management server120provides a custom user agent string to both the tunnel server250and the e-mail server140, along with instructions for the tunnel server250to rewrite outgoing requests from a user device130to include the custom user agent string. When the tunnel server250receives a request from the user device130, it can first authenticate the user device130by comparing an authentication certificate, token, or other authentication information received from the user device130to the authentication information provided by the management server120.

Once the user device130has been authenticated, the tunnel server250can search for the custom user agent string assigned to that user device by the management server120. The tunnel server250then rewrites the mail request originating from the user device130, replacing the default user agent string with the custom user agent string. The custom user agent string matches the custom user agent string sent to the e-mail server140by the management server120.

As a result, the tunnel server250receives the request originating from the user device130, authenticates the request, modifies the request with a custom user agent string, and passes the request to the e-mail server140. The e-mail server140, in turn, compares the custom user agent string to the user agent strings listed in an allow list, and if the user agent string matches an allowed entry, allows the connection and provides an appropriate response to the request. For example, the e-mail server140sends a response back to the tunnel server250. The tunnel server250then passes that response to the user device130through, for example, a per-app VPN connection established between the tunnel server250and the user device130.

In the example described above, the management server120provides information regarding the custom user agent string to both the e-mail server140and the tunnel server250. However, in some examples the information regarding the custom user agent string can be provided to the e-mail server140by the tunnel server250, rather than the management server120.

The administrator110can set e-mail access at the management server120for groups of user devices130. Upon doing so, the management server120can communicate custom user agent strings to the e-mail server140. The management server120can further update a whitelist of allowable user devices130and pairings with custom user agent strings at the tunnel server250to reflect the updated access permissions set at the management server120. When a whitelisted user device130contacts the tunnel server250, the custom user agent string can be provided to the e-mail server140.

The management server130can also update the whitelist based on whether the user device is up to date on enrollment and compliance. For example, the management server120can confirm that a particular user device130is currently enrolled by accessing a data object associated with the enrollment or administrator components121,122(shown inFIG. 1B). The management server120can confirm compliance of the user device130by access a data object associated with the compliance rules124or management policies125(shown inFIG. 1B) relevant to that user device130. If the user device130is enrolled and compliant, it can be added to the whitelist. But if the user device130is not enrolled or compliant, the management server130can remove it from the whitelist.

In this way an administrator can set the management server130to deny email access even in an EWS setting when particular compliance rules are broken. The user device130will not have access to e-mail on the e-mail server140when not enrolled or compliant. If the user device130falls out of compliance because it, for example, becomes jailbroken, moves to an untrusted geographic area, or fails to check in with a server for a while, then the management server120can instruct the e-mail server140to take the custom user agent string off the whitelist.

In another example, the tunnel server250can be responsible for updating user agent strings at the e-mail server140. The tunnel server250can receive a request from a user device130and authenticate the user device130. In this example, after authentication, the tunnel server250can instruct the e-mail server140to add a custom user agent string to the allow list at the e-mail server140. After the custom user agent string is placed on the allow list at the e-mail server140, the tunnel server250can modify the request from the user device130, using the custom user agent string, and send the modified request to the e-mail server140. If the user device130is not enrolled or compliant, the management server120can instruct the tunnel server250to rewrite user agent strings from the non-compliant user device130to a user agent string that is on a blacklist.

FIG. 3is an exemplary method of providing device-specific access to an e-mail server, using a system similar to the system200ofFIG. 2. However, many of the stages ofFIG. 3can also apply to other systems, such as the system100ofFIG. 1. At stage305, an administrator110can send e-mail settings to an e-mail server140to configure the e-mail server140as necessary for carrying out the remaining stages of the method. The e-mail settings can include, for example, instructions for the e-mail server140to enforce an allow list, such as an EWS allow list. In another example, the e-mail settings can include instructions to disable access to the entire organization. In some examples both of these instructions can be provided at stage305, thereby allowing access only to users on the allow list.

At stage310, the administrator110can send configuration settings to a management server120. The configuration settings can include, for example, EMM configuration items such as a Managed E-mail configuration. The configuration settings can also include compliance rules124or management policies125to be put in place for a particular user, user device130, or organizational group123. For example, a compliance rule124can require that all user devices130connect through a secure tunnel server250when using certain e-mail clients. The configuration settings can also cause the user devices130to connect to the tunnel server250through a per-app VPN. Creation of a Managed E-mail configuration can cause the management server120to determine which default user agent string is expected from a user device130. For example, the management server120can determine which e-mail client a user device130can use for e-mail access, and thereby determine the default user agent string associated with that user device130. Stage310can also include providing instructions to the management server120to create device identification information, such as an authentication certificate or token place on a user device130.

At stage315, the management server120provides device identification information to the user device130when the device is enrolled and compliant with any compliance rules established by administrator110. In one example, the device identification information includes an authentication certificate or token to be used for authentication purposes. In another example, the device identification information provides information to a user device130regarding the particular e-mail client to be used to access the e-mail server140, the per-app VPN to be used with that e-mail client, and any other information needed to carry out the stages ofFIG. 3.

At stage320, the management server120can provide device identification information and custom settings to the tunnel server250. In one example, the management server120provides information to the tunnel server250regarding the default request identifier (for example, the default user agent string) expected from a particular user device130. In another example, the management server120provides information sufficient to verify an authentication certificate or token to be provided by a user device130. With respect to the custom settings, the management server120can provide instructions to the tunnel server to rewrite an e-mail request from a user device130to include a custom request identifier (for example, a custom user agent string). In some examples, the management server120provides instructions for a plurality of user devices130. The management server120could, for example, provide a table listing various user devices130, their associated authentication information and expected default request identifier, and the desired custom request identifier.

Stage325can occur before, after, or simultaneously with stage320. At stage325, the management server120can provide the e-mail server140with whitelist settings. In one example, the whitelist settings include a custom request identifier, such as a custom user agent string, along with instructions to allow access to a request including that custom request identifier. The term “whitelist” is used to indicate that the custom request identifier is being placed on an allow list. Otherwise, the e-mail server140would deny access to a request lacking a whitelisted request identifier.

At stage330, the user device130can cause an e-mail request to be sent to the tunnel server250. This can be accomplished, for example, by utilizing an e-mail client installed on the device130to connect to the tunnel server250using a per-app VPN. The e-mail request can include a default request identifier, such as a default user agent string, used by the particular e-mail client installed on the device130. The e-mail request can also include the device identification information provided from the management server120to the user device130, in order to identify the particular user device130to the tunnel server250. For example, the e-mail request can include an authentication certificate or token that matches the authentication information stored at the tunnel server250.

Upon authenticating the e-mail request from stage330, the tunnel server250can modify the request and send a modified e-mail request to the e-mail server140at stage335. This stage can include the authentication of the e-mail request from stage330. For example, the tunnel server250can compare the authentication certification or token from the user device130to the authentication information provided to the tunnel server250at stage320. The tunnel server250can also modify the e-mail request by removing or replacing the default request identifier with a custom request identifier. In some examples, this includes replacing the default user agent string with a custom user agent string.

At stage340, the e-mail server140can return a response to the tunnel server250. As part of this stage, the e-mail server140can parse the e-mail request to verify that the request identifier is allowed access to the e-mail server140. For example, the e-mail server140can compare the request identifier to the request identifiers listed on an allowed list. A request identifier may be listed on the allowed list as a result of the whitelist settings sent from the management server120to the e-mail server at stage325. If the request identifier is allowed, the e-mail server140process the request and sends a response to the tunnel server250.

At stage345, the tunnel server250can receive a response from the e-mail server140and pass the response through to the appropriate user device130. For example, the tunnel server250can send the response through a per-app VPN being utilized by an e-mail client installed on the user device130. In some examples, the process involving the tunnel server250is kept invisible to the user device130, such that a user is only aware of their e-mail request and the resulting response received at the user device130.

At stage350, the management server120can optionally send whitelist settings to the e-mail server140. This stage can be made optional, and is intended to reflect action (relative to the e-mail server140) that can be taken when a user device130is unenrolled from the EMM system. This stage can occur automatically, for example, by way of a compliance rule124that requires a user device130to be enrolled with the system. A compliance rule124can specify that a user device130must remain enrolled with system, and can access a data object associated with the enrollment component121or the administrator component122(shown inFIG. 1B) to determine compliance. The un-enrollment process can include alternative or additional stages relating to the management server120and user device130. But with respect to the e-mail server140, the un-enrollment process can include instructions to remove a particular user device130from an allow list or whitelist. As a result, the user device130will no longer be able to access e-mail stored on the e-mail server140. This process can be used, for example, when a user is no longer employed by the enterprise running the EMM system.

FIG. 4provides an exemplary illustration of an administrator's console for providing device-specific access to an e-mail server. More specifically, an administrator e-mail server console410is depicted. The console410can be any type of user interface for use by a system administrator110. For example, the console410can be a window shown on a display of a computing device. In another example, the console410is a screen of a smartphone. The console410can be displayed on any type of device. A system administrator110can utilize the administrator e-mail server console410to control which users have access to a particular e-mail server140.

The console410can include an option to enable or disable device-specific access to the e-mail server, shown inFIG. 4as button420. When button420is set to “ON,” the console410can send instructions (such as those sent at stage305ofFIG. 3) to the e-mail server140to enforce an allow list. Additionally, when button420is set to “ON,” the console410can send configuration settings (such as those sent at stage310ofFIG. 3) to the management server120. The system administrator110can also set button420to “OFF,” which can automatically send instructions to the e-mail server140to stop enforcing the allow list and instead return to allowing default request identifiers (such as default user agent strings).

The console410can also include an option to automatically assign unique e-mail request identifiers for each device130, shown inFIG. 4as button430. As explained above, in some examples a system administrator110can cause the management server120to assign a custom request identifier, such as a custom user agent string, to a particular device. The system administrator110may want each device to use a unique user agent string to increase the security of the e-mail system. In that case, the administrator can simply set button430to “ON,” causing instructions to be sent to the management server120, and potentially also to the tunnel server250, to automatically assign unique request identifiers to each user device130requesting access to the e-mail server140.

A detailed window440can be included in the console410to provide a system administrator110with easy access to view and edit various types of information. For example, the detailed window440can include a column listing the allowed devices, which can include user devices130with authorization to access the e-mail server140. The system administrator110can view all of the authorized user devices130, manually add or delete devices130from the list, and view/edit more detailed information regarding each device130. The detailed information regarding each device130can be tied to other software functions within the EMM system. For example, a system administrator could view the detailed information by way of the three dots to the right of a listed device130, and choose to un-enroll the device130from the entire EMM system. This selection could cause the administrator e-mail server console410to send instructions to the management server120to perform un-enrollment services beyond those related to accessing the e-mail server140.

Similarly, the detailed window440can include a column showing e-mail request identifiers for each user device130listed in the allowed devices column. In the example ofFIG. 4, each device130corresponds with one e-mail request identifier. In this example, the e-mail server140is an EWS-based server, and the e-mail request identifiers are therefore modified user agent strings. For example, Device 1 corresponds to “DevicelUserAgentString,” Device 2 corresponds to “Device2UserAgentString,” and so on. The naming convention is merely exemplary, and is used to show that each device130can include a unique, customized request identifier. Even with button430set to “ON,” the administrator110can further revise the request identifiers by selecting the three buttons to the right of an identifier, or by selecting the “Edit” button with the detailed window440. As with the allowed devices, revisions to the e-mail request identifiers can automatically propagate throughout the EMM system without requiring the administrator110to manually report those changes to the management server120, tunnel server250, or e-mail server140.

The administrator e-mail server console410can be configured to include any other functionality a system administrator110may need to enable access to an e-mail server140in the desired manner. From a more general standpoint, any function that would require sending instructions to a management server120, tunnel server250, e-mail server140, or user devices130can be built into the console410in the form of a button, table, list, or entry. In this manner, the system administrator110can quickly make changes without spending the time and effort to send instructions manually. The console410can also include features for accessing, creating, deleting, or otherwise modifying an enrollment component121, administrator component122, organizational groups123, compliance rules124, or management policies125. For example, the console410can include a feature allowing an administrator110to implement a compliance rule124specifying that a camera component of the user device130must remain off while in a geographic location corresponding with a high-security vault or room. Any other features, instructions, stages, or steps described in any of the examples herein can be incorporated into the administrator console410.

FIG. 5provides an example method for providing device-specific access to an EWS-based e-mail140server using a custom user agent string. At stage510, the method includes sending device identification information from the management server120to a user device130. The device identification information can include information sufficient to identify a particular user device130to other servers within the system, such as a tunnel server250. For example, the device identification information can include an authentication certificate or token.

At stage520, the method includes providing secure access between a user device130and the tunnel server250. The tunnel server250can provide secure access to or from the user device130, for example, through a per-app VPN. In an example, each mail client can be supported by a VPN. As an example, a user device130can use a per-app VPN for handling traffic through an OUTLOOK for Mac application on the user device130.

At stage530, the management server120can send device identification information to the tunnel server250. Stage530may occur before stages520or510. In some examples, stages510and530are carried out simultaneously or in close proximity to one another. The device identification information sent from the management server120to the tunnel server250can include information sufficient to identify a particular user device130connecting to the tunnel server250. For example, the device identification information can include an authentication certificate or token that can be compared to, or otherwise matched with, the authentication certificate or token provided to the user device130at stage510. The user device130can include its authentication certificate or token in its communication with the tunnel server250to allow the tunnel server250to authenticate the user device130. In some examples, the device identification information includes an expected user agent string. For example, the management server120can determine the e-mail client that a user device130utilizes to connect to the tunnel server250. As a result, the management server120can identify to the tunnel server250a default user agent string associated with that e-mail client. The tunnel server250can use the expected default user agent string as authenticating information. The device identification information sent to the tunnel server250at stage530can also include a custom user agent string to be used for requests to the EWS-based server140from that particular user device130.

At stage540, the method includes recognizing a request for access from the user device130to an EWS-based e-mail server140. In some examples, stage540is performed by the tunnel server250. For example, the tunnel server250can receive a request for access from the user device130through a per-app VPN. The request from the user device130can include device identification information. The tunnel server250can compare, or otherwise authenticate, the device identification information based on the matching device identification sent to the tunnel server250by the management server120. For example, the tunnel server250can confirm that an authentication certificate included in the request from the user device130matches the authentication information provided by the management server120with respect to that same user device130. As another example, the tunnel server250can compare the default user agent string included in the request from the user device130to the expected user agent string provided by the management server120.

At stage550, after authorizing or authenticating the user device130, the tunnel server250can assign a custom user agent string for the request from the user device130. In an example, this stage can include the tunnel server250assigning, replacing, rewriting, or otherwise changing the default user agent string to a custom user agent string. This stage can also include providing the EWS-based e-mail server140with the custom user agent string, either from the management server120or the tunnel server250. Alternatively, the custom user agent string can be provided to the EWS-based e-mail server140as part of a separate or independent stage.

At stage560, the method includes providing the request, with custom user agent string, to the EWS-based e-mail server140. For example, the tunnel server250can pass the request for access from the user device130, as modified by the tunnel server250with respect to the user agent string, to the EWS-based e-mail server140. The EWS-based e-mail server140can handle the request similar to a standard request. For example, the EWS-based e-mail server140can compare the user agent string with an allow list to determine whether the user agent string is allowed access to the server140. As mentioned earlier, in an earlier stage (or a separate stage not shown inFIG. 5), the management server120or the tunnel server250can provide the EWS-based e-mail server140with instructions to add the custom user agent string to an allow list. As a result, the server140can handle the customized request without delay.