Appgate SDP is managed using the Admin UI (or REST API calls). For access, administrators or API users must have access to port 8443, an account in an external IdP (or the Local IdP) and be assigned the appropriate privileges via an Admin Role.
Modern day enterprise-wide deployments need to be supportable. Distributed local support with specific management rights is key for operating in different time zones. The ability to empower experts to configure and manage access to resources in different hosting domains, business networks, AWS, Azure, etc. is key, as is allowing other systems and dev-ops environments to automatically provision access as demand requires. So the administration management environment needs to be both role and API based, and offer the same levels of granularity as it does for user access management.
Admin access is typically required to:
perform admin tasks using the UI.
make API call to the Controller.
view audit logs using the LogServer.
manage appliances using SSH to port 22.
It is strongly recommended that additional admin accounts (some in the Local Database) are created as soon as possible for redundancy and for maintaining access.
Master Admin account
One system administrator account (username "admin"), is pre-configured in Appgate SDP with full system administration privileges. The System Administration account should not be deleted.
Once the Controller has been initialized and configured, you will be able to log into the Admin UI as "admin". The password for "admin" was created as part of the process of configuring the first Appliance.
Using the Admin UI
The Admin UI is a built-in program that can only be accessed by signing into the Controller UI at https://myserver.mycompany.com:8443/ui
Multiple administrators can work on the Admin UI at the same time. Changes to the database are managed at object level, so administrators can edit different elements on the console at the same time. If HA Controllers are in use then it is recommended that all administrators work on the same Controller.
All administrators logging in via the Controller UI will see the Admin UI dashboard and menu options. However the contents shown in the main window will depend on their admin roles and privileges. For example, an administrator with restricted admin privileges may see only certain Policies, , and Appliance information, or none at all if no admin role has been assigned.
Appgate SDP uses admin profiles to remember the preferences each administrator sets. So for instance the choice of light or dark theme will be remembered.
Using API based administration
These admin roles also apply to REST API calls, details of which can be found in Using APIs.
Record of administration actions
All actions undertaken by any administrator are also recorded in the logs. These are always referenced to the user performing the action:
t event_type on_boarded_device_deleted
Full details of all the log record types can be found in the Appendix.
Step by step guide
Steps to configure additional Administrators
Appgate SDP provides a powerful role-based administration capability, allowing you to delegate certain aspects of system administration with the same level of granularity used to control user access to network resources.
Before delegating administration, decide on your admin Policy: the roles (privileges) that will be delegated and how they will be controlled, such as by using Tags to identify entities relating to a particular business unit, or by named instances to restrict access to specific elements of the system.
Step 1. Create a local database account (if required)
Use the Local users UI to manage the builtin database
Add your additional administrator. Use the configuration form to add the new local user account:
Step 2. Create Admin Roles
Use the Admin Roles UI to add new admin roles
Create and configure the privileges required for the additional administrators.
"Admin roles" enable administrators to manage some or all aspects of the system from the Admin UI.
They define an administrator's Privileges, for example: the ability to create, edit, tag, view, or delete system entities such as Appliances, Policies, Tags, and Conditions. An admin role can provision <All> permissions to <All> entities, or the scope can be restricted, such as to particular entities used by a particular business unit.
Admin roles are assigned to administrators using Policies.
Step 3. Enable MFA for Admins
Use the MFA for Admins UI to enable multi-factor authentication
Choose the MFA provider and to specify any exempted users.
Step 4. Create Policies to assign admin roles
Use the Policies UI to create and change Policies
<Builtin Administrator Policy> assigns the System Administration role to the System Administrator user account.
Add new Admin Policies to assign your new Admin Roles to the new administration user accounts.
You are now ready to sign in to the Controller
Propagating changes to administrators
Admin roles define the privileges (such as to edit Policies, delete Policies, or revoke tokens) that can be performed from the Admin UI. Admin roles are assigned to administrators using Policies in the same way as user Entitlements. The admin roles for each administrator will be listed in their Entitlement Token once they have logged into the Admin UI, and will be valid until the session ends (they sign out), the Entitlement token expires or the Entitlement is renewed (whichever occurs sooner).
Renewing the Entitlement token for an administrator will cause the session to be ended, and he/she will have to sign in again. Any changes they were making to system settings that were not saved will be lost. It is recommended that a warning is provided before a token is renewed to provide an opportunity to save any changes.