Access Wall Configuration

Overview

Access Wall is a PAM-native privileged access enforcement layer that prevents direct, unmanaged administrative access to protected assets. When enabled, Access Wall automatically restricts inbound administrative connections, such as SSH, RDP, and WinRM, so they are permitted only from the PAM platform or explicitly approved trusted systems. This ensures that all privileged access is technically enforced through PAM rather than relying solely on policy, monitoring, or credential controls.

By enforcing where privileged connections can originate, Access Wall eliminates common PAM bypass paths, including direct logins using valid or stolen credentials, insider attempts to access assets outside PAM, and access windows created by credential resets. Enforcement is applied automatically at the host level and scales across on-premises, cloud, and hybrid environments without requiring manual firewall configuration, enabling consistent and reliable privileged access control at any scale.

Configuring Access Wall

This section describes how to activate and apply Access Wall enforcement to managed assets. Access Wall configuration consists of a one-time site-level activation followed by asset-level tagging and enforcement actions.

Step 1: Activate Access Wall at the Site Level

Access Wall must be activated at the site level before it can be applied to assets.

As a Site Administrator or Configuration Manager, navigate to Configuration > Access Wall.
Carefully read the Informational message related to the functionality of the Access Wall feature.
Once read and understood, activate the Access Wall option for the site.

This screen functions as an activation acknowledgment rather than a simple on/off toggle. Activation creates the required services and policies needed for the Access Wall functionality. Once activated, all additional configuration is performed at the asset level.

Step 2: Verify the Management Server IP List Asset

Access Wall uses the [IP List / Management Server Access] asset to define the allowed IP addresses for the 12Port server farm.

This asset is automatically created when a new tenant is provisioned.
Update this asset if additional 12Port nodes (master or remote nodes) are added to the environment.
Add additional IP addresses to this asset to expand privileged access to non-12Port hosts like jump servers or trusted machines.

The IP addresses defined here are used to allow privileged access from approved 12Port servers or other defined trusted hosts to Access Wall enforced asset Hosts.

Step 3: Tag Assets for Access Wall Enforcement

Assets must be explicitly tagged to be eligible for Access Wall enforcement.

Apply the [Application :: Access Wall] tag to each asset that should be protected.
When the tag is added and the asset is published to a Major version, the system generates firewall rules on the asset endpoint to allow privileged access from the 12Port server (those defined in the [IP List / Management Server Access] asset from the previous step).

When tagging an asset, the application prompts the user to acknowledge that this is a special tag that may modify firewall rules on the target system.

Note: The Access Wall tag itself does not restrict access. It only opens the required access ports for the 12Port server.

Step 4: Ensure Asset Type Identification

Access Wall determines which ports to manage based on the asset's operating system.

Assets with "Unix" or "Windows" in the Asset Type Name are automatically classified.
For custom asset types that do not include "Unix" or "Windows" in its Name, apply one of the following appropriate tags to the Asset:
- [Component :: Server :: Unix]
- [Component :: Server :: Windows]

These tags allow the system to determine whether to open SSH (Unix) or RDP and WinRM (Windows) ports. Bulk tagging and Intelligent Tagging can be used for large environments.

Step 5: Define Connectivity Ports on the Asset

Access Wall uses port definitions directly from the asset configuration.

Ports are taken from the Port, Management Port, or Port Security fields (or default values if not specified).
For Unix assets, the SSH port is used.
For Windows assets, the RDP and WinRM ports are used.

No additional port configuration is required outside of the asset definition.

Step 6: Enable Access Wall on the Asset

Once firewall rules have been published to the endpoint, the Enable Access Wall option becomes available in the asset Manage menu.

Note

The Asset must be published to a Major version (e.g. 1.0, 2.0, etc) for the firewall rules to be published to the endpoint.

Open the Asset View page or the Asset List page.
Select Enable Access Wall from the Manage or Actions menu.

Enabling Access Wall publishes the firewall rules that block SSH or RDP/WinRM access from all sources except those previously allowed by the Access Wall configuration (those defined in the [IP List / Management Server Access] asset from the previous step).

When Access Wall is successfully enabled on the Asset host, the menu option changes to Disable Access Wall, which removes the restrictive firewall rules if selected.

The asset metadata displays an Access Wall status element explaining why the option may be unavailable (for example, missing tags, not published to Major version, or site-level activation) or its current status.

Step 7: Monitor Access Wall Activity Using Jobs Report

Access Wall configuration and enforcement actions are executed as system jobs and can be monitored through the Jobs Report.

Use the Jobs Report to:

Track the status of Access Wall-related operations, such as rule publication, enablement, or disablement
Review execution results and confirm successful firewall rule deployment
Identify errors or failures during policy application or removal

The Jobs Report provides visibility into when Access Wall changes are applied, which assets are affected, and whether enforcement actions completed successfully. This allows administrators to validate Access Wall behavior and troubleshoot operational issues.

Supported Platforms

Access Wall enforcement is supported on the following platforms:

Windows
Linux
Solaris
AIX
Devices using iptables

Safely Disabling Access Wall on an Asset

Access Wall must be disabled in a specific sequence to avoid leaving a managed host in an unreachable state. Disabling enforcement restores the default operating system access firewall rules before removing Access Wall-specific firewall policies.

Step 1: Disable Access Wall Enforcement on the Asset

Before removing any configuration, re-enable default operating system access rules.

Navigate to the asset's Manage menu.
Select Manage > Disable Access Wall.

This operation restores the default operating system inbound firewall rules:

Linux: SSH inbound access from any source
Windows: RDP and WinRM inbound access from any source

This step ensures that standard remote access is available before AccessWall-specific rules are removed.

Step 2. Validate Remote Connectivity Before Proceeding

After disabling Access Wall enforcement, verify that remote connectivity to the asset has been successfully restored using standard access methods.

Test access from a non-12Port host using the default protocol:
- Linux: SSH
- Windows: RDP and/or WinRM

Confirming connectivity at this stage ensures that default operating system firewall rules are active and functional before AccessWall-specific firewall rules are removed in the next step. Proceed only after successful validation to avoid potential loss of remote access.

Step 3: Remove the Access Wall Tag and Publish Changes

After Access Wall enforcement has been disabled on the asset:

Remove the [Application :: Access Wall] tag from the asset.
Publish the change to a Major version.

Publishing the updated asset version removes the custom Access Wall firewall rules that allowed access from the 12Port server and other trusted hosts.

Important Caution

Do not remove the Access Wall tag before disabling Access Wall on the asset.

If the [Application :: Access Wall] tag is removed first, the custom Access Wall firewall rules may be deleted before default access rules are restored. This can result in SSH, RDP, and/or WinRM ports remaining closed to all sources, potentially causing loss of remote connectivity to the host.

Always disable Access Wall enforcement on the asset before removing the Access Wall tag.

Summary

After site activation and proper asset tagging, Access Wall enforcement is typically enabled with a single Enable Access Wall action per asset. All required ports, policies, and firewall rules are derived from existing or automatically generated configuration, minimizing operational overhead while enforcing privileged access through PAM.