This account has full access to all dashboard features. Leave password blank to keep the current password.
Lets people sign in with Okta, Entra ID, Keycloak, Google or any other OpenID Connect
provider. It goes live once an issuer and client ID are saved. Register this redirect
URI with the provider:
{your-host}/api/auth/oauth/oidc/callback.
Scopes, the groups claim and group-to-workgroup mapping are in Settings afterwards.
This decides which features the instance offers. The two are mutually exclusive, because they disagree about where BeyondTrust tenant configuration lives.
A POV instance is deliberately narrow.
The four cloud credential steps are skipped and nothing is written for them — except object storage, which the next-but-one step offers on its own so this instance has somewhere to stage files too large for an agent-brokered share. The cloud consoles stay unavailable regardless. Estate features — on-premises hypervisors, cloud databases, Kubernetes, containers, virtual desktops, cost reporting — stay unavailable on this instance whatever their toggles say. Run a second instance, with its own database, for those.
Changes what the dashboard leads with, and pre-ticks the integrations this focus usually needs. Nothing is switched off, every page stays reachable, and you can change focus at any time from the nav bar.
Pre-ticked on the Features step:
Untick anything you don't want before finishing — what you submit is what is saved. A focus never switches an integration off.
Your existing feature toggles are left exactly as they are — changing focus during a reconfigure only changes what the dashboard leads with.
Used to deploy EC2 instances. Create a dedicated IAM user with a
customer-managed policy — see Part A of
docs/ONBOARDING.md,
as the AWS-managed policies do not grant enough (read-only S3 cannot
write Terraform state) — then generate an access key.
Name (or ARN) of an AWS Secrets Manager secret containing a JSON object with a
public_key field. Call it anything you like —
paste the name here and the dashboard will use it for every EC2 deployment.
The IAM instance profile — its name or ARN, not the role name — attached to every
deployed EC2 instance for AWS Systems Manager (SSM) access. In IAM open your role and copy the
Instance profile ARN; the name is the part after instance-profile/
(e.g. role ec2-ssm-role → profile ec2-ssm-instance-profile).
Required for the cloud-native AWS Systems Manager Password Safe onboarding; leave blank if you are not using SSM.
The role needs the AmazonSSMManagedInstanceCore policy.
Required if you launch BeyondTrust Gateway containers in ECS. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.
Spin up an isolated, disposable AWS lab tenant on your own machine — where your aws login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.
From a clone of the dashboard repo, with the AWS CLI logged in:
aws login # or: aws configure ./scripts/sandbox/Linux/setup-aws.sh # Windows: .\scripts\sandbox\Windows\Setup-AwsSandbox.ps1
Provisions an isolated VPC, a scoped IAM user, and an SSH-key secret, then prints an aws_* config block to paste here. Tear it down later with rollback.sh --cloud aws. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).
See IAM access keys docs for setup instructions.
Used to deploy Azure VMs. Create a service principal with Contributor rights:
az ad sp create-for-rbac --name dashboard-dev --role Contributor --scopes /subscriptions/<sub-id>
Leave blank if everything lives in the same resource group and you don't use a Shared Image Gallery or Key Vault.
The resource group that contains your VNets and NSGs. Leave blank to use the VM RG above.
Shared Image Gallery (private images tab)
Key Vault — SSH key retrieval
The service principal above needs Key Vault Secrets User role on this vault.
Key Vault secret containing JSON with public_key (used for VM deploys) and private_key (used by Ansible) fields.
Windows servers — Microsoft Entra ID join (optional)
Defaults for the Entra ID checkbox on Windows VM deploys. A joined VM gets a system identity and the AADLoginForWindows extension; the groups below get Virtual Machine Administrator / User Login on it, which needs roleAssignments/write for the dashboard's service principal.
Windows servers on AWS and GCP can be Entra joined through Azure Arc (Windows Server 2025+ with Desktop Experience): they are onboarded as Arc machines in this subscription and get the same login groups. The dashboard's service principal needs Azure Connected Machine Onboarding (or Contributor) on the Arc resource group.
Container Registry — ACI Ansible / Gateway pulls (optional)
Configure if you mirror the Ansible runner or BeyondTrust Gateway images in your own registry (e.g. to bypass Docker Hub rate limits). Credentials are stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.
Leave blank to pull all images from public Docker Hub without authentication.
Required if you launch BeyondTrust Gateway containers in ACI. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.
For a new setup, prefer Single sign-on (OIDC) on the Admin step: it works with Entra ID too, and with any other provider. This older Microsoft-only button still works and can sit alongside it.
Requires a separate Entra app registration (not the service principal above).
Grant delegated permissions: openid
profile
email
User.Read. Leave blank to disable.
The redirect URI is auto-configured to
{your-host}/api/auth/oauth/azure/callback —
add this in the app registration → Authentication.
Spin up an isolated, disposable Azure lab tenant on your own machine — where your az login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.
From a clone of the dashboard repo, with the Azure CLI logged in:
az login ./scripts/sandbox/Linux/setup-azure.sh # Windows: .\scripts\sandbox\Windows\Setup-AzureSandbox.ps1
Provisions a resource group, VNet, a scoped service principal, and a Key Vault, then prints an azure_* config block to paste here. Tear it down later with rollback.sh --cloud azure. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).
Used to deploy Compute Engine instances. Create a service account with the
Compute Admin and
Secret Manager Secret Accessor roles,
then download a JSON key:
gcloud iam service-accounts create dashboard-sa --display-name "Dashboard SA" gcloud projects add-iam-policy-binding <PROJECT_ID> \ --member "serviceAccount:dashboard-sa@<PROJECT_ID>.iam.gserviceaccount.com" \ --role "roles/compute.admin" gcloud iam service-accounts keys create sa-key.json \ --iam-account "dashboard-sa@<PROJECT_ID>.iam.gserviceaccount.com"
Paste the full JSON key file (sa-key.json).
It is stored encrypted in the dashboard database.
Name of a GCP Secret Manager secret containing a JSON object with a
public_key field (or raw public key).
Used for every Compute Engine deployment.
Cloud-NAT subnet the cloud-database tunnel Gateway lands in (it needs egress to reach PRA, unlike the default VM subnet). Emitted by setup-gcp.sh as gcp_jumpoint_subnetwork; falls back to the default subnetwork if blank.
The deploy key the GCE COS Gateway container registers with. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page. Consumed when provisioning the GCP cloud-database tunnel Gateway.
Spin up an isolated, disposable GCP lab project on your own machine — where your gcloud login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.
From a clone of the dashboard repo, with gcloud logged in:
gcloud auth login ./scripts/sandbox/Linux/setup-gcp.sh # Windows: .\scripts\sandbox\Windows\Setup-GcpSandbox.ps1
Provisions a VPC, a scoped service account, and a Secret Manager secret, then prints a gcp_* config block to paste here. Tear it down later with rollback.sh --cloud gcp. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).
Optional — used to deploy OCI compute (Always-Free by default). Uses API-key signing. In the OCI console under Identity → Users → your user → API Keys, add a key and copy the shown tenancy/user OCIDs + fingerprint; paste the matching private-key PEM below. All fields may be left blank to skip OCI.
Stored encrypted in the dashboard database.
Where this POV keeps playbooks, scripts and installers. Pick a cloud if you need
to stage a file too large for a share reached through an agent — that route
carries files inside a signed job envelope and tops out around 190 KB, which
rules out every .exe and
.msi.
These credentials are used for object storage only. The AWS, Azure and GCP consoles stay unavailable on a POV instance, and nothing here turns them on.
Skipping this leaves the agent-brokered share as the only option, which is fine for playbooks and scripts. You can add a bucket later from Settings → Storage.
Enable optional integrations. All default to off — turn on only what you have infrastructure for.
Credentials are encrypted with AES-256 and stored in the application database.