Good Work Application Product Guide
Transcription
Good Work Application Product Guide
Good Work Product Guide Product Version: 1.3 Doc Rev 3.1.5 Issued: 25-Feb-15 | Last Updated: 25-Feb-15 Good WorkTM Table of Contents Introduction 1 Environment and System Prerequisites 2 Required Versions Configuring the Good Work App in Good Control 2 2 Adding Client Connections 2 Configuring Exchange ActiveSync (EAS) 4 Whitelisting Your EAS Server(s) 4 Adding the JSON Configuration for EAS 5 Adding Applications and Users in Good Control 11 Setting Good Work Application Policies 11 Authentication Delegation 15 Prioritizing Delegation 15 Assigning Authentication Delegates 16 Overriding Short Setup 17 Enabling Exchange ActiveSync (EAS) 19 Implementing KCD for Good Work 20 Environments Supported 21 Additional Requirements 21 Limitations 21 Preparing Your Environment for KCD 21 Creating the IIS Alternate Service Account 25 Configuring Delegation to Good Control 27 Configuring the Good Work App for KCD 31 Device Verification and Testing 33 Device Provisioning and Activation 33 Appendix A – Good Work for Android Wear 35 Appendix B – Good Work Server Configuration: Settings and Definitions 37 Common Guidelines Location Good Work™ 37 37 ii Default Values for Empty Settings 38 Format 38 Global Level 38 Domain Override 38 Settings 39 Override Values "Inheritance" 39 Definitions 39 Value Types 39 Security Settings 40 GEMS Settings 40 Exchange Settings 40 Appendix C – GFE to Good Work Deployment Considerations GFE Material Parity GEMS-Good Work/GFE Feature Disparity Deploying the Good Work Client 42 42 42 42 Phase I: Environment Readiness 42 Phase II: Backend User Update 43 Phase III: Activating the Good Work Client 43 Glossary 46 Good Work™ iii Introduction Introduction Now you no longer have to imagine a world where information is relevant, navigation is natural and actions are immediate. That world is right at your fingertips with Good Work, the cutting edge app from Good that delivers the first truly contextual collaboration experience for mobile. Built on the Good Dynamics™ Secure Mobility Platform, Good Work requires some server-side setup and configuration in Good Control in order to securely connect with Microsoft™ Exchange ActiveSync (EAS), as well as to leverage additional Exchange Web Services (EWS) and efficiently communicate with your Good Enterprise Mobility Server™ (GEMS). This guide is intended for IT planners, managers, administrators, and others possessing equivalent technical knowledge. Its scope takes you step-by-step through setup of the Good Work application in Good Control for client device activation of Good Work. Good Work 1.3.0.x for iOS and GEMS 1.3.x.x introduce a greatly improved end-user experience for new email notifications in the iOS Notification Center. Notifications will now display reliably when Good Work is suspended in the background or even when it is not running at all. This results in an end-user experience wherein they can reliably know which messages they have received without having to enter the Good Work app. In prior versions, new email notifications would only display when Good Work was successfully woken up from the background by iOS after receiving a wake-up push notification from GEMS. In the new design, GEMS will still push a Good Work wake-up notification and will now also push a notification to the iOS Notification Center so that it does not rely on Good Work being woken up by iOS to provide the end-user notification. When permitted by iOS, Good Work will wake up and synchronize in the background as a result of these notifications. Otherwise, the new messages will quickly synchronize after the end user resumes Good Work as a result of seeing Notification Center notifications. For additional information and pertinent documentation on Good Dynamics, refer to the following publications available from the Good Developer Network (GDN): l GD Platform Overview for Administrators and Developers l Good Dynamics Sizing Guide l GD Server Deployment Planning and Installation l GD Server Clustering and Affinities For related documentation on GEMS and supported clients, visit the Good Admin Portal, where the following these publications are available for immediate download: l GEMS Deployment Planning Guide l GEMS Installation and Configuration Guide l Good Work Client User Guide for Android Devices l Good Work Client User Guide for iOS Devices Good Work™ 1 Environment and System Prerequisites Environment and System Prerequisites Detailed in GD Server Installation Guide, your GD infrastructure is composed of three primary server components: a database, Good Control (GC), and Good Proxy (GP). Make sure each of these components is correctly installed and configured before proceeding with your implementation of Good Work. Required Versions Good Work 1.2 requires the following minimum versions of Good Dynamics: l Good Control (GC) Server 1.7.38.19 l Good Proxy (GP) Server 1.7.38.14 For best performance results, the most current software version available is strongly recommended and is available from the Good Developer Network (GDN). Important: The minimum required version of your Good Dynamics server(s) must be operating in order to deploy the Good Work application. Configuring the Good Work App in Good Control Before you can configure an application like Good Work in Good Control it must be registered. For complete instructions on adding Good Work and Good Presence in Good Control, see Registering a New Application in your Good Control online help utility. Once the app is registered, you can configure application use privileges and permissions, using the following instructions in conjunction with your Good Control OLH. A few basic configuration settings are necessary so that Good Control can properly support Good Work application users. These include: l Configuring EAS for the Good Work app l Adding Applications and Users l Device Provisioning and Activation Note: The Good Work application must be published in Good Control. For prerequisite details on setting up Good Control, see GD Server Installation Guide. To learn how to add the application in Good Control, see "Registering a New Application" in the GC console's online help. Adding Client Connections From the Good Control console navigator, select Settings > Client Connections. Good Work™ 2 Configuring the Good Work App in Good Control Next, locate (scroll down to) the Additional Servers section. This is a list of specific servers with which all GD applications can connect. Add servers to this list instead of using the Allowed Domains list if you want to restrict access so that GD applications can only connect to certain servers—like GEMS and Exchange—and not to every machine in a domain. Note: Here, it's important to add an entry for the Exchange ActiveSync server on port 443. To add a new allowed server: 1. Click the Add to add a blank row to the list. 2. Enter the server's fully qualified hostname in the displayed field. 3. Configure a primary and secondary GP cluster for the server, if applicable. Connections through GP servers in the primary cluster are attempted first, and if no responses are received, connections are attempted through GP servers in the secondary cluster. 4. Click Submit . Good Work™ 3 Configuring the Good Work App in Good Control To edit information for an allowed server: 1. Click the Edit icon for the server. 2. Modify the server name or GP cluster configuration. 3. Click Submit to commit the change. To remove a server from the list: 1. Click the Delete icon for the server. 2. Click Submit . Configuring Exchange ActiveSync (EAS) Before the Good Work app can be configured to use PNS, it must first be configured for EAS. This will allow your users to easily enroll in EAS when they activate their Good Work app. This is accomplished from your Good Control console. There are several parts to this procedure: l Whitelisting the EAS server(s) in Good Control l Adding the correct JSON configuration for EAS Instructions for each part are listed in order below. Whitelisting Your EAS Server(s) A whitelist is a list or register of servers and/or applications that are being provided a particular privilege, service, mobility, access or recognition. Those on the list will be accepted, approved or recognized. In other words, whitelisting is the opposite of blacklisting—the practice of identifying servers and applications that are denied, unrecognized, or ostracized. To whitelist your EAS server(s) in Good Control: 1. In the navigator (left-hand panel) under Settings, click Client Connections, then click Add under ADDITIONAL SERVERS. 2. In the new Server row, enter the FQDN of your EAS server and your autodiscover server on port 443. Add additional EAS or Autodiscover servers as appropriate by repeating Steps 1 and 2. Good Work™ 4 Configuring the Good Work App in Good Control 1. Click Submit to save your changes. Adding the JSON Configuration for EAS JSON (JavaScript Object Notation) is a lightweight data-interchange format that's easy for humans to read and write, and for Good Work and its supporting infrastructure to parse and generate. JSON is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition. To add the correct JSON configuration: 1. In the navigator panel on the left, click Manage Apps, then either search for or scroll down to Good Work in the applications list and click it. 2. Click the Servers tab. 3. In the Configuration field, copy-paste or manually enter the following configuration: { "disableSSLCertificateChecking":"true", "<email domain for end users>": { "EASDomain":"<EAS Windows domain for end users>", "EASServer":"<EAS server fully qualified DNS name>", "EASServerPort":"<EAS server port number>", "EASUseSSL":"true", "EASSyncWindow":"<sync window value>" } } If you are using Autodiscover, however, replace the EASServer parameter above with AutodiscoverURL so that "EASServer":"<EAS server fully qualified DNS name>" becomes "AutodiscoverURL":"<https://autodiscover.mydomain.com/autodiscover/autodiscover.xml>" to make the block look more like this: Good Work™ 5 Configuring the Good Work App in Good Control "<email domain for end users>": { "EASDomain":"<EAS Windows domain for end users>", "EASServerPort":"<EAS server port number>", "EASUseSSL":"true", "EASSyncWindow":"<sync window value>", "AutodiscoverURL":"<https://autodiscover.mydomain.com/autodiscover/autodiscover.xml>" } } Note: The EASServer parameter always takes precedence, whether the AutodiscoverURL parameter is present or not. Regardless, if you set EASServer, it's good practice to omit AutodiscoverURL from the JSON block to avoid confusion later. For example, your initial configuration might look something like: This means you'll need to appropriately substitute the highlighted values above with values pertinent to your environment in accordance with these parameter descriptions. Before copying and pasting the configuration into Good Control, please use JSONLint (http://jsonlint.com/) to validate the syntax of your configuration. JSONLint will check and make sure the formatting is correct. Here is an example: Good Work™ 6 Configuring the Good Work App in Good Control If you don’t receive a “Valid JSON” response, then it means there is a formatting issue with the configuration. Please correct it before copying it to Good Control. Parameter Description disableSSLCertificateChecking Disables certificate validation checking for test and POC environments. skipShortSetup When true, takes the user directly to the long setup form, requiring user input of a recognized AD username, password, and domain during device activation. email domain for end users A value, this parameter should be set to your FQDN. Example: good.com The value of <email domain for end users> must match the email suffix of your users in Good Control. For example, if your usernames in Good Control follow the pattern, "[email protected]" then the value for <email domain for end users> is mycorp.com. EASDomain Sets the DOMAIN field for EAS enrollment in the Good Work App. Example: good The value of EASDomain is the Windows Domain name used with user credentials by end users to log in to Exchange ActiveSync. EASServer Sets the Exchange ActiveSync server for EAS enrollment. Example: goodeasserver.good.com EASServerPort Sets the port number that will be used to connect to the EAS server. Example: 443 EASUseSSL Determines if SSL will be used to connect to the EAS server. Example: true EASSyncWindow1 In the Good Work email client, under Sync options for Days of mail to sync, users are offered a number of sync-back window intervals ranging from Last day to Last Month, along with a Use account default option. The factory default is Last two weeks, but you can change it any of the following values: 1Changing of the sync window default is currently only supported for Android devices. Even when EASSyncWindow value is changed, the default for iOS devices will remain "Last two weeks." Good Work™ 7 Configuring the Good Work App in Good Control Parameter Description 1 = Last 2 = Last 3 = Last 4 = Last 5 = Last AutodiscoverURL day three days week two weeks month Sets the Autodiscover endpoint, which will be used to dynamically look up the user’s EAS server. Example: https://autodiscover.good.com/autodiscover/autodiscover.xml If this value is set, do NOT set the EASServer value. useKCD Enable/disables Kerberos Constrained Delegation to Good Control for authenticating Good Work Clients. See Implementing KCD for Good Work below for additional guidance. Important: The value of "<email domain for end users>" must match the email suffix of your users in Good Control or the Good Work client will not be able to retrieve the predefined EAS configuration from Good Control. If you support multiple email suffixes, add an additional “domain block” configuration in the JSON as shown in the example: { "disableSSLCertificateChecking":"true", "domain1.com": { "EASDomain":"domain1", "EASServer":"eas1.domain1.com", "EASServerPort":"443", "EASUseSSL":"true", "EASSyncWindow":"5" }, "domain2.com": { "EASDomain":"domain2", "AutodiscoverURL":"https://autodiscover.domain2.com/autodiscover/autodiscover.xml", "EASServerPort":"443", "EASUseSSL":"true", "EASSyncWindow":"4" } } 4. Click Submit to save your changes. Initially, you should add the Good Work app to the Everyone Application Group. It is also highly recommended at this point in the configuration process that you test and verify EAS communications and functionality. This is best done by provisioning a client device with the Good Work app and giving it a road test. Adding GEMS to the Good Work Application Server List Note: If you haven't yet registered the Good Work app in Good Control, do so now. See the Good Work Application Product Guide, available via the Good Admin Portal, for details. Good Work™ 8 Configuring the Good Work App in Good Control The Good Work client checks the Good Work server list for available GEMS instances hosting the Presence service. Hence, the list must be populated with at least one GEMS machine with the Presence service enabled. If multiple GEMS hosts are listed, you can use the Preferred Presence Server Configuration parameter to set up an affinity association (see Configuring Presence Affinity for Good Work). To add GEMS to the Good Work application server list: 1. From the Good Control console navigator (left-hand panel) under APPS, click Manage Apps. 2. Scroll down or search for Good Work and click it. 3. Click the SERVERS tab. 4. Enter the GEMS host FQDN in the Host Name field, then enter 8443 under Port. Caution: At this stage, you are adding a configuration that will cause devices to connect to GEMS over its secure HTTPS port 8443, which is the only port that is open for remote access by default. Therefore, you should ensure that you have not removed the auto-generated self-signed certificate created during GEMS installation unless you replaced it with a CA-signed certificate. Otherwise, devices will not be able to connect to GEMS. 5. If you have additional GEMS hosts, configure them for the application in the same way, after clicking to add a new row. 6. Click Submit to save your changes. Good Work™ 9 Configuring the Good Work App in Good Control Configuring Presence Affinity for Good Work Presence affinity for Good Work is configured in Good Control's Application Policies. Presence affinity is optional. Be aware, however, that once you set affinity, it takes precedence. Caution: When a distributed computer system is truly load balanced, each request is routed to a different server. This load balancing approach is diminished when server affinity techniques are applied. To enable Presence Affinity for Good Work: 1. In the Good Control console navigator click Policy Sets, then locate the policy you want to apply and click it. 2. Click the Application Policies tab. 3. Scroll down to Good Work and click it, then click the App Settings tab. 4. In the Server Hosts field, enter in the FQDN of your GEMS host, followed by port 8443. 5. Click Update. 6. Now, repeat Steps 1 through 5 for every policy that will use Good Work Presence. Good Work™ 10 Configuring the Good Work App in Good Control Adding Applications and Users in Good Control By default, every user is assigned the “Everyone” group. If you plan to use the default, simply add the Good Work app to the Everyone Application Group. Refer to your Good Control online help utility for complete instructions on adding applications like Good Work and Good Presence, as well as new user accounts, and then modifying policies and permissions. Setting Good Work Application Policies Policy sets contain rules that govern the security of GD applications and rules specific to the devices and OS versions configured in Good Control. To set a specific application policy for Good Work: 1. In the Good Control console navigator (left-hand panel) click Policy Sets, select a policy to clone and/or modify, then click the Application Policies tab and select Good Work from the list by clicking it. Good Work™ 11 Configuring the Good Work App in Good Control The higher level tab opens as pictured above. However, because we've already configured Autodiscover (see Configuring Exchange ActiveSync (EAS) for the Good Work App), as indicated in the onscreen note, no further action is required. 2. Click the Notifications tab and select/deselect the application features you will initially enable for your users. Scroll down to reveal additional settings. You can always change these settings later. 3. Click the Address Book tab and set your user permissions according to your IT policy for synchronizing contacts. Scroll down to reveal additional settings. Again, you can always change these settings later. Good Work™ 12 Configuring the Good Work App in Good Control 4. Click the Interoperability tab, then set your general user access permissions for Native Apps (SMS, browser, maps), File Handling (allowing data sharing to/from outside the Good container), and Camera and Device Photo Gallery. Good Work™ 13 Configuring the Good Work App in Good Control 5. Finally, click the Attachments tab to set your policy governing sending and receiving/opening email attachments. Here, you can block or allow attachments by specifying pertinent file extensions separated by a comma. Good Work™ 14 Authentication Delegation 6. Click Update to save your changes. Note: See Good Control Console Help for the complete list of policy control options. Authentication Delegation The Good Work app can delegate its user authentication to other GD or Good For Enterprise applications running on the same device. An application that handles authentication for other GD applications on a device is called the authentication delegate or authenticator. Prioritizing Delegation A prioritized set of up to three applications can be authentication delegates. This is called "multi-authentication delegation." During authentication, each is tried in turn, starting with the primary and ending with the tertiary application you specify. In addition, you can set a "fallback" delegate when all specified delegates have been tried without successful authentication. The fallback delegate is the app itself. If no authentication delegates have been set, the system default is that the application is its own delegate. Any GD or GFE application can be designated as an authentication delegate. Applications that serve as authenticators must be based on the latest GD SDK for iOS or Android, must be registered (see Adding Good Work™ 15 Authentication Delegation Applications and Users), and must have a native bundle ID. In Android, this is the app’s package name and in iOS the value of the Bundle keyword in the app’s plist file). When authentication delegation is enabled, users included in this policy set must have the authenticator application installed and provisioned on their devices in order to use any other GD applications. If one of these users launches a GD application, the device displays the password screen for the authenticator application instead of the application they are attempting to launch. Only after entering the password for the authenticator is the user allowed to access the application they had originally tried to launch. In essence, the user enters the same password for multiple GD applications, because all the applications pass their authentication to the authenticator application. If the user deletes the authenticator application from a device, the user can no longer access any other GD applications on that device, unless self-authentication fallback by an application itself has been enabled, as described above. To remedy this, the user can reinstall the authenticator application. Assigning Authentication Delegates To assign authentication delegates for a policy set: 1. Click Policy Sets in the navigator, then click the Edit icon for the desired policy set. 2. Click the Security Policies tab, then scroll down to Authentication Delegation. Good Work™ 16 Authentication Delegation 3. Click Add Application to display a list of registered applications. Then, from this list, click the plus sign associated with each app you want to act as an authenticator on the devices of all users assigned the policy set. Back at the list of delegates, use the up and down arrows to change the priority of the delegates, or use the circled, red X to remove an application from the list. In addition, if desired, click the checkbox Allow selfauthentication when no authentication delegate application is detected; this is the fallback authentication mechanism detailed above. 4. When all delegates have been added, click Update. Tip: Although Good does not recommend a one-size-fits-all model—meaning your IT group must implement the scheme most appropriate to your environment—in most cases where GFE is in already in use, Good Work should be set as the primary authentication delegate, Good Access as the secondary authentication delegate, and GFE as the tertiary delegate. Overriding Short Setup If you want to override the short setup for user activations, you can configure the Good Work app in Good Control to take the user directly to the long form; i.e., activation requiring an authorized Active Directory username, password, and domain to activate the user's enterprise email account for Good Work on the device. To override short setup and take users directly to the long form: 1. In the Good Control console navigator, click Manage Apps, then click Good Work. 2. Open the Server tab. Good Work™ 17 Authentication Delegation 3. In the Configuration JSON, add "skipShortSetup":"true" as shown in the example below and reflected in the screenshot. { "disableSSLCertificateChecking":"true", "skipShortSetup":"true", "<email domain for end users>": { "EASDomain":"<EAS Windows domain for end users>", "EASServer":"<EAS server fully qualified DNS name>", "EASServerPort":"<EAS server port number>", "EASUseSSL":"true", "EASSyncWindow":"<sync window value>" } } If you are using Autodiscover, however, replace the EASServer parameter above with AutodiscoverURL so that "EASServer":"<EAS server fully qualified DNS name>" becomes "AutodiscoverURL":"<https://autodiscover.mydomain.com/autodiscover/autodiscover.xml>" to make the block look more like this: "<email domain for end users>": { "EASDomain":"<EAS Windows domain for end users>", "EASServerPort":"<EAS server port number>", "EASUseSSL":"true", "EASSyncWindow":"<sync window value>", "AutodiscoverURL":"<https://autodiscover.mydomain.com/autodiscover/autodiscover.xml>" } } Note: The EASServer parameter always takes precedence, whether the AutodiscoverURL parameter is present or not. Regardless, if you set EASServer, it's good practice to omit AutodiscoverURL from the JSON block to avoid confusion later. Good Work™ 18 Enabling Exchange ActiveSync (EAS) 4. Click Submit to save your changes. Enabling Exchange ActiveSync (EAS) EAS is a protocol designed for the synchronization of email, contacts, calendar, tasks, and notes from a messaging server to a smartphone or other mobile device. The protocol also provides mobile device management and policy controls. Please ensure that Exchange EAS is enabled on port 443 and that connections are permitted to the Good Proxy server. By default, ActiveSync is enabled when you install the Client Access server role on the computer that's running Microsoft Exchange Server 2010. Prerequisites include: l The Internet Information Services (IIS) component ASP.NET is installed. l The ASP.NET Web service extension status is Allowed, not Prohibited. You can verify the status of the ASP.NET Web service extension in IIS Manager by expanding the server name and clicking Web Service Good Work™ 19 Implementing KCD for Good Work Extensions. If the ASP.NET Web service extension isn't set to Allowed, right-click the Web service extension to change its status. Use IIS Manager to enable EAS with the following steps: 1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager. 2. Double-click to expand the server name, then expand the Application Pools folder. 3. Right-click MSExchangeSyncAppPool, and then click Start to enable ActiveSync. Note: If the Start command isn't available, then ActiveSync is already enabled on this server. Implementing KCD for Good Work When correctly configured with the appropriate environmental settings, Kerberos Constrained Delegation (KCD) allows the provisioning of the Good Work application without requiring users to enter their Active Directory password. Very briefly, here's how it works. A Kerberos client (a user or a service) sends requests for tickets to the Key Distribution Center (KDC) in the domain. Requests for ticket-granting tickets (TGTs) are sent to the authentication service of the KDC, and requests for service tickets are sent to the ticket-granting service of the KDC. When a client sends a request to the authentication service with credentials that can be validated, the KDC returns a TGT to the client. This TGT is issued for a specific client and can be reused by the client in requests for additional service tickets for the same service. A client must obtain a new TGT from the authentication service before it can obtain service tickets for another service. Each service ticket issued by the ticket-granting service is for a specific service on a specific host computer. That said, the Kerberos protocol includes a mechanism called delegation of authentication. When this mechanism is used, the client (the requesting service) delegates authentication to a second service by informing the KDC that the second service is authorized to act on behalf of a specified Kerberos security principal—in the case of Good Work, a user that has an Active Directory directory service account. The second service can then delegate authentication to a third service. This is achieved by setting the service account running the Good Control service to be a trusted authenticator within Active Directory. Configuration requires setting appropriate Service Principal Names (SPNs) and configuring the ActiveSync virtual directories on Exchange to accept Kerberos Authentication as an allowed mechanism. For environments where a Layer 7 load balancer is utilized in front of the Exchange servers holding the ActiveSync virtual directories, further configuration is required to set the HTTP service to run as an Alternate Service Account, a separate SPN set for the Active Sync URL FQDN, and mapping this SPN to the Good Control service account under which it will run as a service. Good Work™ 20 Implementing KCD for Good Work Environments Supported Good Work supports the following Exchange environments: l Microsoft Exchange 2010 l Microsoft Exchange 2013 Additional Requirements In addition to one of the supported environments listed above, the following steps must be taken to properly implement Kerberos Constrained Delegation for Good Work: l KCD Authentication must be enabled on all EAS virtual directories in Exchange l KCD must be correctly configured and enabled in Good Control Limitations The following currently comprise the known limitations with respect to implementing KCD for Good Work: l Because Good Work KCD relies on Good Control KCD it is subject to the limitations of Good Control KCD l Good Work KCD is only supported with a hardcoded “EASServer” value in the Good Work JSON configuration l Good Work KCD does not support fallback when KCD authentication fails. For a more extensive description of KCD and its features, benefits, and operating principles, please see Microsoft's Kerberos Constrained Delegation Overview in TechNet. To learn more about how KCD operates with Good Dynamics, consult the official GD guide on Kerberos Constrained Delegation available on GDN. Otherwise, proper setup and configuration of KCD authentication for Good Work consists of three (3) major phases in the following sequence: 1. Preparing your environment for KCD 2. Creating the IIS Alternate Service Account for load balancing 3. Configuring delegation to Good Control. Preparing Your Environment for KCD As you proceed, keep in mind that, as of Exchange 2010, clients no longer connect directly to the Information Store on the Mailbox server role to access mailbox data. Instead, clients connect to a set of services on the Client Access Server (CAS) role, and services within the CAS role then access mailbox data from the Mailbox server on behalf of the connecting user. To set the appropriate environmental parameters that will support KCD, you will need: l the correct domain l a Windows Service Account (goodadmin is recommended) Good Work™ 21 Implementing KCD for Good Work l FQDN of the Good Control server l URL for the ActiveSync Virtual Directory l Client Access Array Name If you are implementing L7 load balancing, you will also need to have ample CAS machines residing behind HWLB. To configure your environment for KCD: 1. Run the following command from a Domain Controller to set the SPN for the Good Control Service (GCS): C:\>setspn –a GCSvc/<fqdn_of_gchost> <your_domain>\goodadmin This should produce a confirmation similar to the following, albeit with your environment-specific substitutions: 2. Next, create the keytab file by running: C:\>ktpass /out gdadmin.keytab /mapuser goodadmin@<your_domain> /princ goodadmin@<your_domain> /pass <password> /ptype KRB5_NT_PRINCIPAL This saves the gdadmin.keytab file to the directory on the server from which you ran the command. Important: <your_domain> name must be in all capitals. The password must be the password for your goodadmin service account, if you change the password for this service account, this keytab file will have to be recreated. In response, you receive output similar to this: 3. Copy the gdadmin.keytab file created in the above over to the C:\good directory on your Good Control server. Good Work™ 22 Implementing KCD for Good Work 4. Now, set the appropriate values in the Good Control console. a. In the navigator under SETTINGS, click Servers. b. Open the Server Properties tab and, for each of the following properties, enter the value indicated. Property Value gc.krb5.enabled gc.krb5.kdc <FQDN of your domain controller> gc.krb5.keytab.file <path to the gdadmin.keytab file> gc.krb5.principal.name <service account name in all CAPS> gc.krb5.realm <domain name in all CAPS> Important: Use forward (tick) slashes for the keytab.file path name; ex: C:/good/gdadmin.keytab. Good Work™ 23 Implementing KCD for Good Work 5. Next, on each CAS machine which holds the ActiveSync virtual directory, open IIS and select the MicrosoftServer-ActiveSync virtual directory, then: a. In the far right panel, click Providers... under Actions. b. In the Providers window, click Add. c. From the list of Available Providers, select Negotiate:Kerberos. d. Click the Move Up button until Negotiate:Kerberos is at the top of the list of Enabled Providers. e. Click OK to save this setting. You are now ready to create the IIS alternate service account for your load-balaced Client Access servers (CAS). Good Work™ 24 Implementing KCD for Good Work Creating the IIS Alternate Service Account In order to use Kerberos authentication with load-balanced Client Access servers (CAS), you need to complete the configuration steps described in this topic. For more detailed guidance from Microsoft on cross-forest scenarios, please see Configuring Kerberos authentication for load-balanced Client Access servers. You use Active Directory Users and Computers (ADUC) to manage recipients. ADUC is an MMC snap-in that is a standard part of Microsoft Windows Server™ operating systems, extended to include Exchange-specific tasks. To create and configure the IIS Alternate Service Account (ASA): 1. From ADUC, create a service account; e.g., mygood\f5service. Note: This account needs no permissions or elevated rights. 2. From an Exchange server within your organization, login as an administration and open Exchange Management Shell, then browse (cd) to the scripts directory located in: C:\Program Files\Microsoft\Exchange Server\V14\Scripts 3. Run the following script: RollAlternateServiceAccountPassword.ps1 –ToArrayMembers <fqdn_of_client_access_array> –GenerateNewPasswordFor mygood\f5service The output will look something like the screen captured below but with information and machine names pertinent to your environment. Good Work™ 25 Implementing KCD for Good Work When complete, ouput ends with "THE SCRIPT HAS SUCCEEDED." 4. Verify this by running the following cmdlet: C:\>Get-ClientaccessServer –IndlueAlternateServiceAccountCredentialStatus | fl name,alter This will produce: Good Work™ 26 Implementing KCD for Good Work 5. Now set the SPN for the FQDN used above by specifying the ASA name with the following command: C:\>setspn –S http/<fqdn_of_client_access_array> mygood\f5service This registers the Service Principal Name. 6. Next, perform a resest on all CAS machines within the organization with this command: C:\Windows\system32>iisreset noforce You are now ready to delegate authentication to Good Control. Configuring Delegation to Good Control As previously discussed, delegation is the act of allowing a service to impersonate a user account or computer account in order to access resources throughout the network. When a service is trusted for delegation, that service can impersonate a user so that it can use other network services. To set up delegation to Good Control, the following conditions must be met: l The account doing the delegation must be set to Trusted for delegation to specified services only. l The account that the service is delegating for must not have the Account is sensitive and cannot be delegated option chosen. l An administrator must have the Enable computer and user accounts to be trusted for delegation privilege on the computer in order to enable delegation. To configure authentication delegation to Good Control: 1. From ADUC, select View, select Advanced Features, then click Users. 2. Double-click the service account running the Good Control service (e.g., goodadmin) and open the Delegation tab. 3. Enable Trust this user for delegation for specified service only. 4. Select Use any authentication protocol. 5. Click Add. Good Work™ 27 Implementing KCD for Good Work 6. Select each CAS server that holds a virtual directory. Or, in the case of a single CAS server select the single CAS server machine name. Pictured in the example below, CAS1, CAS2 and CAS3 machines hold the ActiveSync directories. 7. Next, click Add Services and select all HOST, http, and www services related to each of the CAS servers in your organization. Good Work™ 28 Implementing KCD for Good Work 8. Click Add... again and then input the service account name; in this case, goodadmin , then click Check Names. 9. From the list of Available Services you should see GCSvc with the FQDN of your Good Control server that was created in Step 1 under Preparing Your Environment for KCD above. Good Work™ 29 Implementing KCD for Good Work Note: Steps 10 and 11 below are only applicable if you are using a CAS array. If you are not using a CAS array, skip to Step 12. 10. Click OK, then enter the name of the service account you created in Step 1 of Creating the IIS Alternate Service Account above. 11. When presented with the Service Type http corresponding with the FQDN you specified in Step 3 of Creating the IIS Alternate Service Account above, click OK. 12. The list of specified services displayed should now allow Kerberos Constrained Delegation for the Good Work application against ActiveSync virtual directories when using a HWLB with Exchange 2010. Good Work™ 30 Implementing KCD for Good Work Click Apply, then click OK. Note: The sequence for configuring KCD for Exchange 2013 is virtually indentical, with only some minor variations. Configuring the Good Work App for KCD The final part of the KCD configuration process for Good Work is enabling KCD in the Good Work application settings in Good Control. This simply requires a short block of JSON appended to what's already in place for EAS or Autodiscover. Good Work™ 31 Implementing KCD for Good Work To add the JSON for KCD: 1. In the Good Control console under APPS, click Manage Apps. 2. Either search for or scroll down to Good Work and click it. 3. Open the Servers tab. 4. Add/append the following JSON to the existing configuration (open and close brackets are not needed if already present). { "useKCD":"true" } With this JSON parameter added, the Configuration field should look similar to this: Note: Currently, useKCD is only supported when the EASServer parameter is set. 5. Click Submit to save your changes. Good Work™ 32 Device Verification and Testing Device Verification and Testing The Good Work app is publicly available from the Apple App Store or the Google Play store. By default the app will only use HTTP/S to communicate with GEMS when it registers for push notifications. If you would like to do device verification and testing in a test environment, you can configure communications to use HTTP instead of HTTPS. This is a matter of making additional changes to the Good Control configuration (JSON) we set up when configuring the Good Work app with Active Sync earlier. If you haven’t already done so, download the Good Work app to your device. Upon launching the Good Work app for the first time, you will be prompted for an email address and a provisioning PIN. If you don’t have this information, refer to the previous section on device activation keys. Good Work will continue the provisioning process once the email address and PIN is entered correctly. Depending on the Good Control policy for the device, you may be prompted to create a password for the app. After the app password is set, you will be prompted for your enterprise email address and Active Directory password. If the system is not able to correlate your email address to an Exchange Active Sync (EAS) server, you will be prompted for a different EAS server and domain credentials. When everything is setup correctly, Good Work will automatically start synchronizing with Exchange and you will start to see mail, calendar and contact information in the app. If Good Presence is configured, you will also see presence information for each contact. Device Provisioning and Activation Users invited to install and activate Good Connect on their device(s), require an access key. The access key must be entered when the user opens Good Connect for the first time on a given device. The access key is a 15-character alphanumeric code sent to the user’s (registered) company email address and has the following properties: l It can be used only once and is consumed immediately upon the activation of an application. l It is not application-exclusive. In other words, a user who has been sent four access keys can use them to activate any four applications to which s/he is entitled. l It does not support reactivation. Hence, if the client software is uninstalled, then reinstalled on the same device, a new access key is required. This is also true if a new or factory-reset device is in use, or if a device emulator is in use and its state is not persisted. However, a user who has been issued multiple access keys could use them to activate the same application multiple times. l It can be configured to expire after a specified period of time. This is done in Provisioning Policies under the SECURITY POLICIES tab by enabling the Access Keys expire option, and then selecting the number of days after which access keys expire if not consumed. Good Work™ 33 Device Provisioning and Activation To grant access to all your enterprise users complete the following steps: 1. Assign the default policy set or create a new policy set in accordance with your enterprise’s user access protocols. The default policy set is automatically applied to all new users. For each user, the policy currently applied is located at the top of the user’s account page. To apply a different policy set, hover your cursor over it and select from the available policy sets in the listbox. It should be noted that the user must be granted access to the app in order to activate it. This is done by assigning the user to an App Group that includes the app (Good Work) for which the user is being permitted access. 2. Go to USERS > Manage Users in the navigation panel, locate and select the user you want to provision by clicking the corresponding checkbox, then click Edit. 3. Click on the Keys tab, then click New Access Key. A new access key will be sent to the user’s registered enterprise email address—one email message per key. Hashes of the access keys are also copied to the GD NOC for validation. Assuming the user has received the email message containing the access key and downloaded and installed the GD client application from the pertinent online marketplace—App Store or Google Play—on the device, they can now activate the application until its GC-specified expiration date. At application start-up, the Good Dynamics user activation interface opens, whereupon the user must enter the access key and his/her enterprise email address in the input fields provided on the client so that the GD Client Library can promptly transmit the access key to the NOC. Additional provisioning and activation options are also available in Good Control. For more on these features see: l Easy Activation Good Work™ 34 Appendix A – Good Work for Android Wear Appendix A – Good Work for Android Wear Wearable devices to interact and share data offer new avenues for mobile collaboration while also creating a new class of security and privacy risks. For this reason, Good Work offers limited support for wearable computing. Wearable computing is broadly classified as anything from your fitness tracker, Google Glass, or any form of computing device that you wear on your wrist, your head, or even clip onto your clothes. Wearable computing devices make it easy for users to go about their daily tasks without worrying that the device is going to get in their way. Such wearable devices rely on either Bluetooth or Wi-Fi connections to transfer data to a companion app on the mobile device with which it is paired, mainly because it doesn’t have a SIM slot to hold its own data. When using a device outside of a controlled wireless network, wearables require higher communications security with respect to encryption, information integrity, and non-repudiation. Since wearable computers are quite small, most do not come equipped with higher security measures baked in, which renders any data sent and received vulnerable. Consequently, Good Work's support for wearables is confined to notifications and reminders and, optionally, a corresponding user-initiated voice reply/quick reply enabled via the Good Work application policy set in Good Control. The feature includes: l Single-email notification – voice reply and quick reply l Multi-email notification – voice reply and quick reply for each email in the notification l Calendar Event reminders – voice reply and quick reply for emailing invitees l Meeting Invitation Notification – send Accept/Decline/Tentative The Good Work Application Policy in Good Control can be set to: l Allow/disallow notifications on connected wearable devices l Allow/disallow voice and quick reply from connected wearable devices To enable/disable Good Work for wearables: 1. In the Good Control console navigator (left-hand panel) click Policy Sets, select a policy to clone and/or modify, then click the Application Policies tab and select Good Work from the list by clicking it. 2. Click the Notifications tab, then scroll down to ADDITIONAL OPTIONS FOR NOTIFICATIONS ON ANDROID WEAR DEVICES (pictured). Good Work™ 35 Appendix A – Good Work for Android Wear 3. Check/uncheck Show notifications on connected wearable devices (Android Wear only) to enable/disable support for Android wearables. 4. From the options listed in the dropdown, make a selection. 5. Click Update. Good Work™ 36 Appendix B – Good Work Server Configuration: Settings and Definitions Appendix B – Good Work Server Configuration: Settings and Definitions This addendum furnishes the standard properties and their format for Good Work's application server configuration. Good Work's GD Application ID is com.good.gcs.g3. Common Guidelines Configuration options affect the behavior of the app and typically don't require frequent readjustment. The supporting network services and devices described in the core sections of this administration guide should already be set up, tested, and operating properly prior to adding/changing the configuration settings for the Good Work application server. Location Like all Good Dynamics applications, configuration settings for the Good Work application server are found in the Good Control console under Applications > Manage Applications > Good Work. Good Work™ 37 Appendix B – Good Work Server Configuration: Settings and Definitions One example of a Good Work application server configuration might look like this: { "disableSSLCertificateChecking": "true", "ignoreExchangeMDM": "true", "mycompany.com": { "EASDomain": "g3", "EASServer": "ex2010.mycompany.com", "EASSyncWindow": "5", "useKCD": "true" }, "dev.mycompany.com": { "EASDomain": "dev", "EASSyncWindow": "3", "AutodiscoverURL": "https://dev.mycompany.com/autodiscover/autodiscover.xml", "skipShortSetup": "true", "ignoreExchangeMDM": "false" } } Here, there are two global parameters: disableSSLCertificateChecking and ignoreExchangeMDM. There are also two Domain overrides: mycompany.com and dev.mycompany.com. The domain override allows us to set parameters specific to that domain. For the mycompany.com domain, we are hardcoding the EASServer parameter to a specific EAS server, and KCD is enabled (useKCD). In the second domain, dev.mydomain.com, Autodiscover (AutodiscoverURL) is used, the EAS short form is skipped (skipShortSetup), Exchange MDM is ignored (ignoreExchangeMDM) and the EAS Sync window (EASSyncWindow) is changed to 3. Default Values for Empty Settings Settings can be empty; if a setting is not specified (entered into Good Control) or its value is invalid, client default values are assumed. Format Configuration settings must be specified in valid JavaScript Object Notation (JSON) according to the standard protocol defined in RFC-4627. Global Level The Global level container is a JSON Object signified by curly brackets; i.e., {}. {} Members may include: l Any number of optional Settings – when placed in the Global Level container these are treated as "Global" and will apply in the absence of a domain override setting l Any number of optional Domain Override objects. Domain Override An object inside the top level object that contains any number of domain specific "override" settings is called a Domain Override. The name of the object is the host to which override settings will be applied. The value is the object, which can contain any number of settings members. Good Work™ 38 Appendix B – Good Work Server Configuration: Settings and Definitions { "setting" = "Global Default" "domain.com" = { "setting" = "Override" } } Members: Any number of optional Settings – when placed in the domain container these will only apply to email addresses ending in that domain and will override the Global setting. Settings Settings are members of either the global object or a domain object; each being a member value of these objects. "SettingName" = "Setting Value" See Definitions below for a description of function and example values. Override Values "Inheritance" Inheritance precedence adheres to the following rules: 1. If a setting is present in the client's domain, the setting will be what is set in the domain object. 2. If not present in the domain object, the client will look for the setting choice in the Global Level and use that. 3. If set in neither, the client will apply its out-of-the-box default settings. Definitions Definitions of each setting and value type, including working descriptions and examples, are set forth below. Important: The number of settings and control points will continue to expand as more and more features are added to Good Work and existing features are enhanced. Coinciding with each Good Work software version release, be sure to check new postings of this document for updates and revisions. Value Types Type Description BOOL Boolean, True or False, can be JSON standard true, false, strings "true", "false", true, false, 0, 1 "true", "false" or numbers 0, 1 URL Fully Qualified URL, including scheme "http://www.myserver.com", "https://secureserver.corp.com" Time Interval Time interval in minutes 60, 5, 3600 Unsigned Integer Positive whole number 1, 200, 443, 8000, 80 Server name Name of server (non-qualified) "myserver.com", "gems.mycompany.com" Protocol Valid web protocol "http", "https" String Valid string "TenantIdentifier", "Purple" Good Work™ Examples 39 Appendix B – Good Work Server Configuration: Settings and Definitions Security Settings Description Support (iOS/Android) disableSSLCertificateChecking BOOL "false" Disables SSL certificate verification for ActiveSync / EWS server iOS / Android useKCD If enabled, Kerberos Constrained Dispatch will be used for login (user won't be able to, or required if configured properly to enter a password for ActiveSync), otherwise NTLM / Basic authentication will be used iOS / Android Client Default Description Support (iOS/Android) Setting Type Client Default BOOL "false" GEMS Settings Setting Type defaultServerPort Unsigned 443 Integer Port to use when connecting to GEMS host iOS / Android serverProtocol Protocol "https" Protocol to use when connecting to the GEMS host iOS / Android PushServerURL URL None Required value for getting push notifications; should be the address of your GEMS server iOS / Android defaultServerName Server name not set If set, will use this to connect to GEMS host iOS / Android accessKey String not set Access key for GEMS Server (need to elaborate) iOS / Android profileName String not set Profile Name for GEMS (need to elaborate) iOS / Android tenantId String not set Unique Tenant ID String representing an enterprise iOS / Android or organization in a multi-tenant/cloud environment serverListReshufflePeriodInMinutes Time Interval 2880 (2 days) Frequency that server list (if present) will be reshuffled, for load balancing purposes iOS / Android 30 If a GEMS server is not working, Good Work will wait this period before retrying iOS / Android serverListQuarentinePeriodInMinutes Time Interval Note: tenantId, accessKey and profileName values must all be set in order to configure GEMS Push. Exchange Settings Setting Type Client Default EASDomain String none Good Work™ Description Windows NT Domain to try automatically when logging in. If your server uses newer UPN ([email protected]) style login instead of the older (domain\user) style login, this field should be omitted Support (iOS/Android) iOS / Android 40 Appendix B – Good Work Server Configuration: Settings and Definitions Client Default Type EASServerPort Number none (uses protocol default port) Port used when connecting to Exchange ActiveSync service. If not specified, defaults to protocol default (i.e., https, 443) iOS / Android EASServer Server Name none Default Exchange Server to attempt to connect to; used in place of AutodiscoverURL iOS / Android AutodiscoverURL URL none If provided, and attempts to connect to EASServer fail (or no EASServer is provided), will attempt autodiscovery directly to the URL provided. (This is more secure than "Automated Autodiscovery," which relies on guessing the Autodiscover URL based on DNS entries) iOS / Android skipShortSetup BOOL "false" If set to "true," short form will be skipped during setup and long form entry will be provided iOS / Android ignoreExchangeMDM BOOL "false" When responding to an exchange policy request, if this is true, response will be "Success," falsely indicates that the policy is successfully applied. Default of "false" will return "Third Party Managed," which indicates correctly that Good Work is managed by the GC and not Exchange iOS / Android Good Work™ Description Support (iOS/Android) Setting 41 Appendix C – GFE to Good Work Deployment Considerations Appendix C – GFE to Good Work Deployment Considerations For existing Good for Enterprise (GFE) deployments, please note the following considerations before deploying Good Work. GFE Material Parity In this first release (1.1) of the Good Work client with GEMS (1.1), complete material parity with GFE will be deferred to subsequent releases. If the capabilities and compatibilities listed below are required in your environment, then a full transition to the Good Work client and GEMS from GFE is currently not possible. Consequently, until full material parity with GFE is achieved, a POC or limited deployment of the Good Work client with GEMS is recommended. GEMS-Good Work/GFE Feature Disparity The main potential disparities to consider include: Mobile Device Management (MDM) In version 1.1 of Good Work, some device specific MDM policies available in GFE are not supported. However, because the Good Work client is built on the Good Dynamics (GD) platform, it is FIPS-certified with AES 256 encryption. Likewise, features such as jail break detection, remote wipe, offline wipe, OS verification, etc., are all available in Good Work v1.1. Domino Mail Domino mail is not currently supported by the Good Work client. S/MIME S/MIME is also not currently supported by the Good Work client. Deploying the Good Work Client Three distinct planning phases are recommended to realize a successful GFE-to-Good Work client migration process. Each is phase can be summarized as follows: Phase I: Environment Readiness Prior to deploying the Good Work client in your environment, make sure the following infrastructure is installed and properly functional. 1. Good Dynamics – The Good Work client is a Good Dynamics (GD) app. As such, it requires a Good Control and Good Proxy server. Please ensue that Good Control and Good Proxy are functional in your environment. More information about Good Dynamics can be found on the Good Developer Network (GDN) and in the GD Server Installation Guide. Good Work™ 42 Appendix C – GFE to Good Work Deployment Considerations 2. Microsoft Exchange – The Good Work client uses ActiveSync to connect to Exchange. Therefore, you must ensure that all Good Work users are enabled for ActiveSync in Exchange. Additionally, make sure the Exchange server is reachable by the Good Proxy server. More guidance on EAS with the Good Work client can be found in Appendix C of the GEMS Installation and Configuration Guide. 3. Good Enterprise Mobility Server (GEMS) – GEMS provides extra functionality to the Good Work client, including Presence, Push Notifications, and more. If you plan to use these extra features and functionalities, ensure that the GEMS host is correctly implemented in your environment. See GEMS Installation and Configuration Guide. Phase II: Backend User Update Because the Good Work client runs on the Good Dynamics platform, Good Work users must exist in Good Control before they can activate the Good Work app on their device. It is important to remember that, in a GFE deployment, users in Good Mobile Control (GMC) may not necessarily exist in Good Control. This inconsistency presents a problem when using “Easy Activation” (with GFE) to activate the Good Work client. In order to use GFE as an activation delegate for Good Work, the user must exist in Good Control. If the user does not exist in Good Control, Easy Activation will fail. Hence, to deploy the Good Work 1.1 client to your GFE users, you must ensure that GFE users in GMC are properly imported to Good Control (the Good Dynamics management server and console). By default, this is a manual process. Currently this means you must manually log into the Good Control console and add GFE users. Subsequently, in a GMC release slated for Q4 2014, the import process will be automatic with Easy Activation. Until then, however, please consult Good Professional Services to customize an automated solution for importing your users from GMC to Good Control. Phase III: Activating the Good Work Client Good Work client activation is the last phase in the Good Work client deployment process. Before installing the client, make sure Phases I and II above have been completed. Best practices for installing the Good Work client comprise: Easy Activation l This is the recommended method to activate the GSC client l For GFE users, the GFE client is the recommended activation delegate app l For other users and non-GD users (i.e., completely new users), only the email/PIN method is available for activating the Good Work client l For non-GFE users with an existing GD app installed on the device, Easy Activation is recommended to activate the Good Work client if the existing GD app supports Easy Activation. Good Work™ 43 Appendix C – GFE to Good Work Deployment Considerations Authentication Delegate For non-GFE users and non-GD users, the Good Work client is the recommended primary authentication delegate. For both non-GFE and GFE users, see Delegation Priorities to better understand the authentication delegation protocol. Good Work™ 44 Legal Notice This document, as well as all accompanying documents for this product, is published by Good Technology Corporation (“Good”). Good may have patents or pending patent applications, trademarks, copyrights, and other intellectual property rights covering the subject matter in these documents. The furnishing of this, or any other document, does not in any way imply any license to these or other intellectual properties, except as expressly provided in written license agreements with Good. This document is for the use of licensed or authorized users only. No part of this document may be used, sold, reproduced, stored in a database or retrieval system or transmitted in any form or by any means, electronic or physical, for any purpose, other than the purchaser’s authorized use without the express written permission of Good. Any unauthorized copying, distribution or disclosure of information is a violation of copyright laws. While every effort has been made to ensure technical accuracy, information in this document is subject to change without notice and does not represent a commitment on the part of Good. The software described in this document is furnished under a license agreement or nondisclosure agreement. The software may be used or copied only in accordance with the terms of those written agreements. The documentation provided is subject to change at Good’s sole discretion without notice. It is your responsibility to utilize the most current documentation available. Good assumes no duty to update you, and therefore Good recommends that you check frequently for new versions. This documentation is provided “as is” and Good assumes no liability for the accuracy or completeness of the content. The content of this document may contain information regarding Good’s future plans, including roadmaps and feature sets not yet available. It is stressed that this information is non-binding and Good creates no contractual obligation to deliver the features and functionality described herein, and expressly disclaims all theories of contract, detrimental reliance and/or promissory estoppel or similar theories. Legal Information © Copyright 2015. All rights reserved. All use is subject to license terms posted at www.good.com/legal. GOOD, GOOD TECHNOLOGY, the GOOD logo, GOOD FOR ENTERPRISE, GOOD FOR GOVERNMENT, GOOD FOR YOU, GOOD APPCENTRAL, GOOD DYNAMICS, SECURED BY GOOD, GOOD MOBILE MANAGER, GOOD CONNECT, GOOD SHARE, GOOD TRUST, GOOD VAULT, and GOOD DYNAMICS APPKINETICS are trademarks of Good Technology Corporation and its related entities. All third-party technology products are protected by issued and pending U.S. and foreign patents. Good Work™ 45 Glossary Glossary A Access Key Part of the activation key that is different for every GD application activation. Access keys consist of 15 letters and numbers. Access keys are generated by the enterprise GC server. Activation Key All the credentials necessary for activation of a GD application for an end user. The necessary credentials are a provisioning ID and an access key. AD Active Directory ADSI Active Directory Services Interface ADT Plugin Android Development Tools Plugin Affinities The feature that enables enterprises to allocate their GP servers between their GC servers and their application servers. Allocation can be an absolute division, or based on a priority order, or both. Application Policies The feature that enables GD application developers to add policies that are specific to their application to a GC server. Application policies are defined by developers, using an XML file format. Application-Based Service A GD shared service that is provided by GD applications. An application-based service uses Good Dynamics AppKinetics for communication. Authentication Delegation The feature for transferring authentication of the end user from one application to another. An application for which authentication is delegated does not display its unlock screen, and does not have its own security password. Authentication delegation can be used between two GD applications, and between GD applications and the GFE mobile client. Authentication delegation is controlled by the enterprise administrator through the management console of the respective software product, either GC or GFE Good Mobile Control. Good Work™ 46 Glossary C CLI Command Line Interface COTS Commercial Off the Shelf HTTP Proxy D DC Direct Connect DMZ Demilitarized Zone DMZ proxy for Direct Connect HTTP proxy in the enterprise perimeter network that relays DC connections. G GC Good Control server. The GD server component which hosts the web-enabled Good Control management console, or GC console, for managing permissions and settings for Good Dynamics applications. GC resides on a machine belonging to your organization. GD Good Dynamics. Good product that gives companies a set of development tools to create their own secure apps built on the technology used to create GFE. GD Application ID The unique identifier used throughout GD to identify the application for the purposes of entitlement, publishing and service provider registration. GD Authentication Token mechanism A token-based single sign-on feature that enables an end user to be authenticated by an application server without the need for entry of any further credentials. Good Work™ 47 Glossary GD Direct Connect The feature for relaying GD communication through a proxy in the enterprise perimeter network (also known as DMZ or demilitarised zone) instead of through the GD NOC. This feature also enables GP servers to be deployed in the enterprise perimeter network, instead of behind the firewall. GD Enterprise Servers Two GD components installed behind the enterprise firewall: Good Control (GC) and Good Proxy (GP). GD NOC Good Dynamics Network Operations Centre - provides a secure communications infrastructure between the GD Runtime on the mobile device and the GD enterprise servers behind the firewall. GD Runtime The component that is embedded in a mobile application to enable its connection to the GD platform and container. Every GD application includes an instance of the Good Dynamics Runtime. Alternative form: Good Dynamics Runtime GD SDK Good Dynamics Software Development Kit. The products that enable developers to build GD applications from source code in the native programming languages of the mobile platform. Native source code includes, for example, Objective-C on iOS, and Java on Android. Other forms: Good Dynamics SDK Good Dynamics Software Development Kit GD Shared Services Framework for collaboration that includes Application-Based Services and Server- Based Services. Both types of service use a consumer-provider model. The consumer is always a GD application. The provider of an application-based service will also be a GD application. The provider of a server-based service will be an application server. Alternative forms: GD Shared Services Good Dynamics Shared Services Framework GD Shared Services Framework Shared Services Framework GD Wrapped Application An application in which the GD Runtime has been embedded by using the GD Wrapping process. Other form: Good Dynamics Wrapped Application GD Wrapping The product for embedding the GD Runtime in a mobile application executable without requiring access to application source code. Other form: Good Dynamics Wrapping Good Work™ 48 Glossary GDN Good Developer Networking. A web portal to support app development. • Download the Good Dynamics SDK • Download the Good Dynamics Servers • Access technical support, the Good Community, and other resources • Get notifications for technical updates • Get access to Good Dynamics enabled applications • Connect with developers and Good ISV partners GFE Good for Enterprise GNP Good Notification Push. Protocol that allows notification messages to be pushed from an application server to GD app. Good Dynamics AppKinetics™ Mechanism for secure exchange of application data between two mobile applications on the same mobile device. AppKinetics data exchange uses a consumer-provider model. One application in the exchange provides a service that is consumed by the other. GP Good Proxy. The GD server component which provides a secure bridge between the GC server and your enterprise application servers, if any exist, and delivers messages to and from GD applications. GP resides on a machine belonging to your organization. GRP Good Relay Protocol. Protocol for end-to-end secure communications between the GD app and the GP server. GW Good Wrapping. The GD server component which can be used to wrap non-GD iOS applications with GD technology, allowing you to secure your applications without the need for additional programming or access to source code. GW resides on a machine belonging to your organization. H HTML/CSS/JS Hypertext Markup Language, Cascading Style Sheet, and JavaScript, which are the languages used to code applications in the Adobe PhoneGap MEAP. Good Work™ 49 Glossary I IDE Integrated Development Environment J JSON JavaScript Object Notation, the format used for AppKinetics service definitions files. JSON is a standard. K KCD Kerberos Constrained Delegation. A single sign-on feature that enables an end user to be authenticated by an application server that uses Kerberos, without the need for entry of further credentials. KDC Key Distribution Center. A logical component of the Kerberos infrastructure M MAM Mobile Application Management O OWA Outlook Web Access P Provisioning ID Part of the activation key that is the same for all GD applications activated by the same end user at the same enterprise. The provisioning ID is typically the end user’s enterprise email address. Good Work™ 50 Glossary R Relay Server Server in the NOC that provides communications between the GD app and GP servers. RTT Round trip time S SDK Software Development Kit. Typically a set of software development tools that allows for the creation of applications for a certain software package, software framework, hardware platform, computer system, video game console, operating system, or similar platform. Server Clustering A feature within GD that enables enterprises to deploy groups of servers as single nodes in their GD infrastructure. The following servers can be deployed in clusters using this feature: GP, GC, application servers. Server-Based Service A GD shared service that is provided by application servers. A server-based service could use any communication technology, including HTTP or TCP sockets. Service Discovery Feature that enables a prospective consumer of a shared service to query for available providers of the service. The result of a service discovery query will be a list of GD applications, for an application-based service, or a list of servers, for a server- based service. Alternative forms: AppKinetics Service Discovery Service provider registration Activity of adding a GD application or application server to the list of providers of a particular service. The list of service providers is hosted in the GD NOC. SPN Service Principal Name Good Work™ 51 Glossary U UI User Interface UX User Experience Good Work™ 52