WALLIX Bastion Hardening Guide: Securing the Gateway to Privileged Sessions

A WALLIX Bastion holds the credentials, session rights and recordings for an organisation's most powerful accounts, so its own configuration decides how much protection every target behind it really gets. The product ships with sensible protocol defaults, but many of the controls that matter most are customer-side choices: who administers the Bastion, how users authenticate, which sub-protocols each authorisation allows, how secrets rotate and where the audit trail goes. This guide walks through those settings using the names in the WALLIX Bastion 12.5 Functional Administration Guide, with a phased rollout, detection guidance and a framework mapping. It is written for PAM engineers, security architects and auditors who run or assess a WALLIX Bastion deployment.

This is an independent guide from NHI Mgmt Group, based on WALLIX's public documentation as of November 2026. It is not sponsored or reviewed by WALLIX. Product features change, so confirm settings against WALLIX's current documentation.

Key takeaways

• Replace the default admin account. WALLIX recommends deleting the built-in admin local identity after deployment and creating a differently named local administrator, kept for restricted use such as an identity provider outage.
• Authorisations are the real policy. Each authorisation links one user group to one target group and lists the exact sub-protocols allowed, so granting only what a role needs (for example SFTP_SESSION rather than SCP) is the core hardening step.
• Use the built-in protections, then add approvals. NLA with Kerberos, Session Probe and server certificate checks protect RDP sessions; approval quorums, mandatory tickets and time frames add the dual control layer.
• Rotate what the Bastion vaults. Turn on password change per domain, set a reconciliation account, and use locked checkout with change at check-in so a revealed secret does not outlive its task.
• Send the evidence somewhere else. Forward configuration, authentication and session events through System > SIEM integration or syslog, and protect break-glass credential recovery with GPG keys that are kept valid.

How WALLIX Bastion controls privileged access

WALLIX Bastion sits between users and targets. Users authenticate to the Bastion through the web interface, an SSH client or an RDP client, and the Bastion opens the session to the target with a vaulted or mapped credential, so the user never needs the target password. WALLIX describes the product as combining an access manager, a password vault and a session manager that records privileged activity for audit. Understanding the object model makes the hardening choices clearer.

For the wider discipline behind these objects, see the Privileged Access Management Guide and the Privileged Session Management Guide.

Administrator accounts, profiles and Bastion authentication

The administrative plane of the Bastion is the first thing to lock down, because a Bastion administrator can grant themselves access to every target.

• Default admin: the admin account is a local identity. WALLIX recommends deleting it after deployment and creating a new local administrator with a different name. Keep local identities for restricted cases such as emergency access during an identity provider outage, and manage them under the Break-Glass Account Guide process.
• Custom profiles: split product administration, operations, approval and audit into separate custom profiles. Set the profile fields "Limitations on user group" and "Limitations on target group" (False by default) to scope delegated administrators to their own estate, and add an IP limitation (a single address or a network such as 10.10.0.0/24) to admin profiles.
• Primary and secondary factors: WALLIX lists Kerberos Ticket, LDAP/AD bind password, local password, SSH key and X.509 as recommended primary methods, and PingID, RADIUS and TACACS+ as the only method for local users or the secondary method for LDAP/AD users. The documentation recommends configuring multi-factor authentication in the identity provider (for example through SAML or OIDC external authentication).
• Directory transport: enable StartTLS or SSL on Active Directory and LDAP external authentication, because without them the AD password crosses the network unencrypted, and password reset requires them. Kerberos-Password is deprecated in version 12; move those users to Kerberos Ticket. Members of the AD Protected Users group can only use Kerberos Ticket, with the SASL GSS-API bind method.
• X.509 matching: when using certificate login, set matching conditions so a certificate is only accepted for the intended domain; with no condition any certificate signed by the trusted CA is accepted. Turn on OCSP or CRL checking so revoked certificates are refused.
• Account hygiene: set an expiration date on contractor and temporary accounts, restrict source IPs per user, and use the Disable option for leavers rather than leaving accounts active.

Local password policy

Configuration > Local Password Policy governs local identities. The values below are WALLIX's documented recommendations, not defaults.

Upload a banned password list (UTF-8 file) as well. Locked accounts are unlocked from Users > Accounts with the display set to Local, which gives the service desk a controlled path rather than a reason to raise the threshold.

Authorisations, approvals and session controls

Authorisations translate role design into enforcement. Each one carries the following controls, and the same field names appear in WALLIX's Terraform provider, which makes them reviewable as code.

Self-approval: self-approval is permitted by default and is controlled by "Allow self approvals" in Configuration > Configuration options > Global. Turn it off where approvals are meant to provide dual control; see the Dual Control and Four-Eyes Approval Guide. One rejection dismisses a request, and quorum must not exceed the number of approvers.

Time frames: assign time frames to user groups so standing access only exists during working periods. They use the Bastion's local time, and automatic disconnection at the end of a period can be kept on (it can be disabled per frame). The default "allthetime" frame should not be the frame for privileged groups.

Restrictions: user group restrictions take a kill or notify action against case-sensitive regular expressions, one per line. For RDP, patterns can match keyboard input ($kbd) and window titles ($ocr); for SSH, a warning count can be set before disconnection. When several groups apply, kill wins. Detection only covers client-to-server data, so restrictions complement recording rather than replace it; see Session Recording vs Command Filtering.

Connection policy hardening

Connection policies hold the protocol settings. The built-in RDP and SSH policies cannot be deleted, and the product also ships CCN-STIC and SOG-IS compliant variants (RDP-ccn, SSH-ccn, RDP-sogisces_1.3_2030, SSH-sogisces_1.3_2030), which WALLIX recommends where applicable. Duplicate a built-in policy, tighten it and assign it, so the original remains as a reference.

Agent forwarding needs both the connection policy and the authorisation to allow it, so leave SSH_AUTH_AGENT out of authorisations unless a documented workflow needs it. For SSH certificate design behind the Bastion, see the SSH Protocol and Certificate Authority Guide.

Vaulted credentials, rotation and checkout

The vault only reduces risk if the secrets in it change. WALLIX handles rotation per domain and per account.

1. Enable password change on the domain and define a reconciliation account. WALLIX recommends always providing one, because the new secret cannot be set if the old one is unknown, and recommends disabling automatic secret change on the domain's administrator account itself.
2. Choose a password change policy. The built-in default policy requires at least 16 characters with a special character, number, uppercase and lowercase letter, and has no automatic schedule; it cannot be edited. Create a custom policy with a change periodicity (5-field cron syntax) for scheduled rotation. The default SSH key type is RSA 4096.
3. Test before you widen. Changing a policy or applying a new one to a domain triggers rotation for every account with automatic change enabled. WALLIX recommends testing with one non-administrator account first.
4. Use locked checkout. Under Targets > Checkout policies, enable Lock and "Change password at check-in", with a checkout duration, extension and maximum duration that match the task. The built-in policy named "default" can be edited but not deleted, so review what it allows.
5. Prepare target systems. For Windows targets WALLIX advises "minimum password age" set to 0 for reliable rotation, Kerberos for global domains, and WinRM over HTTPS on port 5986 with "Allow unencrypted transport" left off. The LDAP plugin uses STARTTLS on port 389 by default.

For programme-level rotation design, see Credential Rotation at Scale.

Where identity fits: API keys, integrations and service accounts

Automation against the Bastion REST API, scanners that pull credentials, and Terraform pipelines are non-human identities with broad reach. Treat them as such.

• API keys: each key is bound to a profile, and its profile and IP limitation can only be set at creation. Bind keys to a narrow custom profile, always set the IP limitation (unset means usable from any IP), and record the owner in the description. The raw key is only shown at creation in the web UI, so store it straight into a secrets manager. See the API Key Management Guide.
• TLS verification: WALLIX's Terraform provider verifies the Bastion certificate by default and documents insecure_skip_verify for development only. Replace the GUI and API certificate with one from your PKI so clients can validate it.
• Credential recovery right: integrations that fetch credentials for privilege escalation, such as vulnerability scanners, need the credential recovery feature on their account. Grant it to a dedicated integration account, scoped to the target groups it scans.
• Discovery accounts: discovery needs local administrator rights on Windows and read access to files such as /etc/shadow on Linux, so vault and rotate those accounts like any other privileged credential. WALLIX recommends never scanning a subnet larger than 8,192 addresses.

Encryption, break glass and resilience

• Encryption passphrase: the Bastion encryption state can be sealed, unsealed or need setup, and the encryption mode is either passphrase protected or unprotected. A passphrase can only be set at initial setup, so decide at installation and record the passphrase under dual custody. A passphrase-protected Bastion is sealed after reboot until the passphrase is entered.
• Session recordings: recordings are encrypted so only the Bastion instance that created them can read them. Plan backup and restore around that, and keep restore tests in your resilience exercises.
• Break-glass e-mail: the standard credential recovery mechanism sends a GPG-encrypted e-mail of gathered credentials nightly at 2:34 (Bastion time zone). Limit the Credential recovery Execute right to named custodians, check their GPG keys before expiry, and store the output offline.
• High availability: HA database replication offers Master/Master and Master/Slaves modes, and clusters spread jump server sessions. For upgrades, the controlled deployment method tests on a cluster copy first and carries less risk than auto-deployment.
• Updates: apply WALLIX security updates promptly through your normal change process, and track WALLIX customer support communications for advisories.

Logging, detection and measurement

Forward Bastion events off the appliance so an administrator cannot quietly remove the trail. System > SIEM integration (licence dependent) sends syslog over UDP or TCP in RFC 3164 format with ISO timestamps; prefer TCP. Selectable categories include configuration changes, authentication logs, account activities, SSH and RDP proxy events and SSH, RDP and VNC session events. Logs also remain on the Configuration > Logs audit page. Under Configuration > Notifications, enable alerts for authentication failures, flagged patterns or processes in sessions, SSH fingerprint changes and critical target access.

Map detections to ATT&CK T1078 Valid Accounts, T1021.001 Remote Desktop Protocol and T1021.004 SSH, since an attacker with a Bastion login uses exactly those paths. Metrics that show the hardening is working:

• Recorded coverage: percentage of authorisations to production targets with recording on (target 100%).
• Rotation coverage: percentage of target accounts with automatic password change and a successful rotation in the last period.
• Approval discipline: share of critical sessions with a ticket reference and an approver other than the requester.
• Local identity count: number of local Bastion accounts, trending down to the documented break-glass set.
• API key hygiene: percentage of API keys with an IP limitation and a named owner.
• Log delivery: hours since the last event received in the SIEM from each Bastion node.

Rolling out the baseline safely

1. Inventory: export users, profiles, authorisations, connection policies and API keys; the Terraform provider can import them for a reviewable baseline.
2. Protect the admin plane: create named administrators and custom profiles, add IP limitations, connect the identity provider with MFA, then remove the default admin.
3. Turn on forwarding first: configure SIEM integration and notifications before changing session policy, so you can see the effect of each change.
4. Pilot connection policies: duplicate the RDP and SSH policies, tighten TLS, algorithms and timeouts, and assign them to a pilot target group. Test Session Probe and Application Driver behaviour per Windows build.
5. Tighten authorisations: remove unused sub-protocols, add recording, critical flags, approvals and time frames, starting with tier 0 targets.
6. Enable rotation: start with one non-administrator account per domain, then widen.
7. Rollback: keep the original built-in policies untouched, so reverting a pilot is a reassignment; take a Bastion backup before each phase and record the change ticket.

Small versus large estates: a single Bastion with directory groups, built-in policy duplicates and SIEM forwarding covers most small deployments. Large estates benefit from delegated profiles limited by user and target group, HA replication, clustered jump servers and configuration managed as code, which makes review and drift detection simpler.

Common misconfigurations

• The default admin still in use: a shared, well-known account at the top of the access chain defeats attribution. Replace it as WALLIX recommends.
• Broad sub-protocol sets: authorisations copied with every SSH and RDP sub-protocol allow file transfer, drive mapping and agent forwarding that the role never needed.
• Self-approval left on: approval workflows look like dual control in reports while one person both requests and approves.
• Server certificate checks off for convenience: disabling "Server cert check CA" for self-signed targets reduces protection against interception; adding the target CA is the documented route.
• Vault without rotation: accounts onboarded with automatic change off, or no reconciliation account, keep the same passwords for years.
• Unscoped API keys: keys with a powerful profile and no IP limitation turn an automation leak into full Bastion control.

Framework mapping

MITRE ATT&CK mitigation M1026 Privileged Account Management describes the outcome these controls deliver. WALLIX Bastion 6.0.102 received an ANSSI CSPN first-level certification (report ANSSI-CSPN-2019/15) covering functions including secure communications, access control, traceability, secure storage and Bastion hardening; check WALLIX's current certification status for the version you run.

Practitioner checklist

• Default admin deleted and replaced by named administrators with custom, scoped profiles and IP limitations.
• MFA enforced through the identity provider; AD and LDAP connections use StartTLS or SSL.
• Local password policy meets or exceeds WALLIX's recommendations, with a banned list loaded.
• Every production authorisation lists only needed sub-protocols, with recording on and critical targets flagged and alerted.
• Approvals use quorum, mandatory ticket and comment, and "Allow self approvals" is off.
• Duplicated RDP and SSH policies set explicit TLS levels, SSH algorithms and inactivity timeouts; server certificate checks are on.
• Automatic password change and reconciliation accounts enabled per domain; locked checkout with change at check-in.
• API keys bound to narrow profiles with IP limitations and stored in a secrets manager.
• SIEM integration forwarding all categories over TCP, with alerting tested end to end.
• Encryption passphrase and break-glass GPG keys held under dual custody and checked before expiry.

Standards and references

• WALLIX: WALLIX Bastion 12.5.0 Functional Administration Guide
• WALLIX: Terraform Provider for WALLIX Bastion
• ANSSI: Certification report ANSSI-CSPN-2019/15, WALLIX Bastion 6.0.102
• WALLIX: Privileged Access Management
• Sekoia: WALLIX Bastion integration
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• MITRE ATT&CK: M1026 Privileged Account Management

Related NHI Mgmt Group resources: Privileged Session Review Checklist, JIT Access Guide, Privileged Access Workstations vs Jump Servers, Break-Glass Account Guide.