WorkZone Mobile requirements to Microsoft Enterprise Mobility Suite infrastructure

Some configuration of an organization's infrastructure actions must take place to allow WorkZone Mobile access to on-premise WorkZone through Microsoft Enterprise Mobility Suite,

The diagram below shows a conceptual overview of the components in the infrastructure and how they are set up to support WorkZone Mobile with Microsoft Enterprise Mobility Suite (EMS). The number of real servers, firewalls, load balancers, and so on varies depending on how the environment is set up for a specific organization.


Syncronization of internal users to Azure Active Directory

You can do this in several different ways but to be able to use Multifactor Authentication Multi-factor authentication (MFA) is an authentication method that requires the use of at least two verification methods at user login, for example user name and pasword and a client certificate., and thereby also conditional access, the only supported solutions is to federate your internal domain using an on-premises ADFS Active Directory Federation Services solution. This means that user login requests are forwarded to an internal ADFS service. Furthermore, it means that there are no passwords or password hashes in Azure. This is also the only solution that offers users the full single sign-on experience across internal systems, for example Microsoft Office 365 apps.


Azure Application Proxy with a Proxy Connector service installed

Azure Application Proxy pre-authenticates users in Azure Active Directory and provides access to underlying applications, in this case the internal WorkZone web service. A Proxy Connector service is installed on an internal server, which is in the same domain as the resources that are to be exposed, in this case the internal WorkZone web server.

When the Azure Application Proxy service approves a request, it connects to the internal Proxy Connector, and requests it to access the internal resource (the WorkZone web server) on behalf of the current user, and send data back to the user/device on the other side of the Azure Application Proxy service.


Azure Web App publication of internal WorkZone services

The internal WorkZone web site must be published using Azure Application Proxy as a Web App/API type, so that it can be accessed externally with the same URL as the internal clients use on the domain. Furthermore, it requires that WorkZone is set up to use the HTTPS.

You set it up so that it is required that users are pre-approved with Azure Active Directory before they get access to the internal resources. As a second factor, besides user name and password, you can add a so-called Conditional Access Policy in Azure that only allows access if the user uses a device, which is managed by Intune. This means that you can use the actual device as the second factor.

It is also possible to use other built-in two-factor features in Azure Active Directory, for example sms code or voice call. This will, however, add an extra step to the user's login process.


InternalWorkZone must run with HTTPS

To publish a web service using Azure Application Proxy, HTTPS is required and as WorkZone does not support HTTPS off-loading,the underlying WorkZone server must also use HTTPS.


Flexible management of security

Because you use Azure Active Directory, you also have access to all the options for managing access. When Microsoft releases new features, you will also be able to use these features to manage the access to the WorkZone Mobile app.


Intune deployment of WorkZone Mobile and Microsoft Office 365

To get the full benefit of WorkZone Mobile, it must be deployed along with Office 365, which offers the possibility to edit Office documents.