1. technology and computing
2. internet technology
3. email

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