Appgate SDP's Admin UI is an API-driven, secure web front end that provides a central point of control of the whole Collective, even across a distributed network.
The information that will be displayed in the admin UI and the admin actions allowed, will depend on the administration privileges that have been assigned to that user. For more information about admin roles and privileges, refer to: System Administration.
Accessing the Admin UI
Admin/API access is via the Unique Admin Hostname. You should make sure to use this and not some other hostname or IP address as some browsers check the URL against the certificate when connecting and require an exact match before access is allowed.
It is strongly recommended that you DO NOT allow admin access directly from the internet. Please refer to System security - best practice.
It is also very strongly recommend to nominate JUST ONE Controller as the point where all admin tasks are performed to avoid any database conflict issues. This might seem as a weak point from an HA perspective, however changes to the configuration (such as adding a new Entitlement) are not usually time critical. What might be more time critical is reading information from the Controller(s) using the REST API e.g. finding the users IP tunneling address. So, for API calls that ONLY READ INFORMATION you can use the Profile DNS name (same as the Clients use - part of the profile link). This has should have multiple A records and will provide HA working for these specific REST APIs calls.
You should sign-in to the admin UI on a regular basis to check the Admin messages and the Appliance health status. If you do not do this, then vital messages such as appliance certificate expiry might get missed.
Removing the browser security warning
The admin UI uses the self-signed root certificate which means there will be an 'unsafe' warning shown (the browser does not trust the certificate). To avoid the admin having to approve this certificate, the best option is to use an externally signed certificate. However there are also a couple of other options available if you want to continue to use the root certificate:
Add a trusted third party certificate
The 'unsafe' warning can be removed by adding a trusted third party certificate for use with the Admin/API TLS Connection on port 8443 of your Controller appliance. There are actually two ways of doing this, you can either add a PKCS #12 file that includes an existing wild-card certificate/private key or if you want to limit the distribution or corporate wild-card certificates and private keys, then a new private key and certificate can be generated using a CSR.
NOTE
This process has to be done for each Controller (although only 1 controller should be used for administration).
Add an exception for the Controller's self-signed root certificate
The 'unsafe' warning can also be removed by adding an exception for the self-signed certificate. The exact action required differs depending on the device being used:
Safari requires that an exception be added for the self-signed root CA.
Firefox uses its own Certificate Manager (where an 'exception' has to be added for the Appgate SDP CA before access is allowed to the Admin UI); but the browser will continue to show it as untrusted.
Chrome also requires an 'exception' has to be added for the Appgate SDP root CA before access is allowed; and the browser will continue to show it as untrusted. However Chrome uses the native OS certificate store present on each device and once the root CA has been correctly saved into the store, will allow access to the Admin UI without the browser showing it as untrusted. This is similar to the Client which also uses the native OS certificate stores so the same process applies.
Trust the Controller's self-signed root certificate
The 'unsafe' warning can also be removed by adding the Controller's self-signed root certificate to the local certificate stores in administrator's devices.
Obtain the certificate from admin UI in Certificate Authority. The Controller produces a .pem or .cer cert depending on the device you are using. Windows does not recognize .pem so rename it to .cer (it uses the same encoding).
Windows:
Either add cert to local machine root cert store (requires admin priv and will be for all users):
certutil -addstore "Root" C:\AGSDPcert.cer"Or just open and install the Certificate (choosing the Current User option and location defaults). The certificate will end up in: Certificates-Current User > Intermediate Certification Authorities > Certificates. Run the Windows Certificate Manager (certmgr.exe) utility as admin and drag the certificate to Trusted Root Certification Authorities > Certificates.
macOS:
Either with the terminal enter:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain <cert>.crtOr through the UI buy installing the certificate into the keychain; opening the certificate and setting the trust to 'Always trust'