How does it work?
Always-on Clients are similar to the full Client that a normal user would use, however they allow the user's device to connect to the network even when the user is not signed in. The always-on Client combines the full Client which behaves in the usual (interactive) way with the headless Client (which will runs in the background without a UI).
The following are a few examples of different use cases relating to the headless half of the always-on Client:
Provision sufficient Entitlements to allow connection to the domain controller. This could then allow a computer to become domain-joined while remote from the network (just using a bootable USB stick).
Include an Entitlement (down rule) that would allow remote administration of the device.
Set a default route Entitlement for the device so it captures and redirects all the user's traffic at all times.
The only difference between this and the headless Client is that the user can sign in (because there is assumed to be a screen/keyboard). Whenever the user is not signed in, the always-on headless Client will continuously try to sign in. This will mean that at boot-up device will always be signed-in using the always-on headless Client which gets its own Entitlements (based on its own Policy). This allows secure connections to be established with certain Sites - providing access to a limited set of resources protected by AppGate ZTNA irrespective of what the user is doing.
As soon as the user signs in using the always-on full Client they will get their own Entitlements (based on their Policy) and always-on headless will suspend (keeping its tokens in memory so it can resume later). If and when the user suspends the always-on-full Client or signs out, then the always-on-headless takes over again immediately. These two modes of operation (headless and full) are quite independent, so renewing the tokens for one will not renew tokens for
The always-on Client supports auto-update and is initiated from either the headless or full Client depending on which is connected. Both parts of the Client will be updated together.
NOTE
To use the macOS client, you must turn off Limit IP address tracking on your device. If this is not disabled, DNS settings will be ignored. You can disable the setting manually or through an Apple MDM profile. To manually disable this setting:
On your macOS device, navigate to Settings > Network.
Select your ethernet connection or Wi-Fi.
Select the Details… button.
Disable Limit IP address tracking and select OK.
Background information
System limitations
You must have different users defined for the always-on headless and always-on full mode. The on-boarding process has to be done for both the AppGate ZTNA always-on headless and always-on full Clients. If the user is the same for both modes and has already on-boarded in one of the two modes, then the other mode will fail to on-board. This means the Client will consume two user licenses.
Muti-factor authentication on-boarding is not supported on always-on-headless Client, so if this is required for the always-on-full Client, then a different IdP will have to be chosen and two different profile links used.
Custom on-demand device claims are not supported while running in always-on in headless mode.
You will probably want to have different Policies for always-on headless and always-on full modes. These can be assigned based on the different users (or IdPs) that have been defined. Alternatively the clientType claim can be used as this will report either full or headless depending on the mode in use.
How to install
Using the Client
Logs
See macOS headless Client and macOS full Client.
How does it work?
Always-on Clients are similar to the full Client that a normal user would use, however they allow the user's device to connect to the network even when the user is not signed in. The always-on Client combines the full Client which behaves in the usual (interactive) way with the headless Client (which will runs in the background without a UI).
The following are a few examples of different use cases relating to the headless half of the always-on Client:
Provision sufficient Entitlements to allow connection to the domain controller. This could then allow a computer to become domain-joined while remote from the network (just using a bootable USB stick).
Include an Entitlement (down rule) that would allow remote administration of the device.
Set a default route Entitlement for the device so it captures and redirects all the user's traffic at all times.
The only difference between this and the headless Client is that the user can sign in (because there is assumed to be a screen/keyboard). Whenever the user is not signed in, the always-on headless Client will continuously try to sign in. This will mean that at boot-up device will always be signed-in using the always-on headless Client which gets its own Entitlements (based on its own Policy). This allows secure connections to be established with certain Sites - providing access to a limited set of resources protected by AppGate ZTNA irrespective of what the user is doing.
As soon as the user signs in using the always-on full Client they will get their own Entitlements (based on their Policy) and always-on headless will suspend (keeping its tokens in memory so it can resume later). If and when the user suspends the always-on-full Client or signs out, then the always-on-headless takes over again immediately. These two modes of operation (headless and full) are quite independent, so renewing the tokens for one will not renew tokens for
The always-on Client supports auto-update and is initiated from either the headless or full Client depending on which is connected. Both parts of the Client will be updated together.
Background information
System limitations
You must have different users defined for the always-on headless and always-on full mode. The on-boarding process has to be done for both the AppGate ZTNA always-on headless and always-on full Clients. If the user is the same for both modes and has already on-boarded in one of the two modes, then the other mode will fail to on-board. This means the Client will consume two user licenses.
Muti-factor authentication on-boarding is not supported on always-on-headless Client, so if this is required for the always-on-full Client, then a different IdP will have to be chosen and two different profile links used.
Custom on-demand device claims are not supported while running in always-on in headless mode.
You will probably want to have different Policies for always-on headless and always-on full modes. These can be assigned based on the different users (or IdPs) that have been defined. Alternatively the clientType claim can be used as this will report either full or headless depending on the mode in use.