What is AirWatch Cloud Connector (ACC)?
AirWatch Cloud Connector is a network relay component that runs on an organization's internal network and provides the ability for AirWatch to integrate with their back-end enterprise systems through the AirWatch Cloud Messaging (AWCM) service.
What are the use cases for ACC?
ACC is useful for organizations looking to integrate AirWatch with any of the following internal resources:
Email Relay (SMTP)
Directory Services (LDAP/AD)
Microsoft Certificate Services (PKI)
Simple Certificate Enrollment Protocol (SCEP PKI)
Email Management Exchange 2010 (PowerShell)
BlackBerry Enterprise Server (BES)
Third-party Certificate Services
Lotus Domino Web Service
Syslog (Event log data)
How is ACC configured?
ACC can be installed for both SaaS and on-premise AirWatch environments. It can be installed on either a physical or virtual server. It operates from an organization's internal network and can be configured behind any existing web application firewalls (WAF) or load balancers. Organizations can proxy ACC traffic through an outbound proxy.
How does ACC transfer data?
ACC transmits outbound data from an organization's internal resources to the AWCM service.
First, the AirWatch Console (which can be in a SaaS setup or on-premise) sends a request for data to the AWCM.
Next, AWCM holds on to this data until ACC queries for requests.
Last, when ACC queries the AWCM and recognizes a request it sends the appropriate data.
How is data secured in transit?
The requests from the AirWatch server and the ACC queries are SSL encrypted using HTTPS. Requests are encrypted using the unique public key of the ACC instance and only ACC can decrypt the requests. Requests are signed using the private key of the AirWatch server instance that is unique for each group. This means ACC trusts only the requests from the configured AirWatch server. Responses from ACC to the AirWatch server are encrypted with the same key as the request and signed with the ACC private key.
Does ACC replace EIS?
As of AirWatch v6.4, the AirWatch Enterprise Integration Service (EIS) has been divided into two products – ACC and MAG. There are many benefits with the architecture of these new products and the simplicity of integrating them into your enterprise. Both products can be used separately, yet complement each other when used together. However, neither one can be used with EIS. AirWatch will continue to support the existing functionality of EIS for existing users in future releases of the AirWatch Admin Console, but administrators who are planning on utilizing any of the latest integration features will need to use the ACC and MAG.
Does ACC auto update to the newest version?
The auto-update checkbox is selected by default when you install ACC. This lets ACC upgrade automatically to the latest version without any user intervention by querying AirWatch for new versions. This option can be turned off if desired.
Does ACC require its own server?
ACC can be installed on any server on the internal network that has access to the internal infrastructure that is being integrated with, such as the AirWatch MAG or Console server. However, it is recommended to have a separate physical/virtual server.
What is the workflow for ACC communication?
ACC is installed in the internal network and has access to enterprise resources (LDAP, certificate authorities, etc.). ACC also has an outbound connection to the AWCM server.
Both ACC and AWCM have the Secure Channel certificate installed in their respective Java Keystores, which is used to establish trust beween them. All communication between AWCM and ACC is encrypted.
ACC communicates with AWCM via the (configurable) external or internal AWCM URL. This connection is persistent, as ACC will continue to listen for new commands even when idle. The ACC does have retry logic built-in should a connection be terminated prematurely.
When an internal resource needs to be accessed (such as during authentication against an LDAP system), the AirWatch application establishes a session with AWCM. This session contains a unique session ID, along with specific information regarding the requester's Organization Group. AWCM queues this message.
ACC will receive only the messages intended for that configuration based on the session ID and Organization Group Details. This message will be processed by ACC, and the resulting data will be conveyed back to the AirWatch application through AWCM.
How is end-to-end encryption performed for authentication credentials?
The following workflow describes how AirWatch implements end-to-end encryption for authentication credentials:
A user inputs their credentials into an authentication screen (such as the Console, Enrollment, or Self Service Portal pages).
This data is embedded into a message payload and immediately encrypted. Only the configured ACC server has the private key needed to decrypt this payload. The credentials are never stored in the AirWatch database.
The encrypted payload is transmitted to AWCM. AWCM is unable to decrypt the payload. However, AWCM uses CMS detached signatures to guarantee trust, message integrity, identity verification, and protection from replay attacks.
The encrypted payload is transmitted to ACC. ACC uses the configured private key to decrypt the payload. The user credentials are validated against LDAP and are only used in active memory.
Is it possible to get an alert message when ACC is not running?
You can use management tools like vSOM or Microsoft SCOM to do the monitoring of the individual windows service on the respective server to send out alerts.
How is password authentication performed with ACC?
AirWatch/ACC does not directly store the password anywhere. When a user enters their username and password in a device, the account credentials are checked over ACC against the directory to validate the information.