Adding Wallix PAM via Syslog

Purpose

This guide explains how to forward Wallix Bastion (PAM) events to Logsign USO over syslog and what Logsign does with them. The integration covers proxy authentication events produced by the RDP and SSH proxies, Bastion user authentication events, and the session and audit events that the Bastion writes for recorded sessions and administrative changes.

Prerequisites

• A Wallix Bastion administrator account that is allowed to change the log forwarding configuration.
• Network connectivity from the Bastion to the Logsign USO collector on your syslog port (TCP or UDP 514 by default).
• The Logsign user account that will add the data source needs access to Settings > Data Collection.

Step 1: Forward Bastion logs to Logsign

Wallix Bastion sends its logs through its own syslog configuration. Menu names differ between Bastion releases, so use the Wallix administration guide for your version to find the log forwarding or remote syslog server settings. In that configuration, add the IP address of the Logsign USO collector and the syslog port, and keep the Bastion default message format.

Logsign reads the key="value" pairs from the message body and does not depend on the syslog header, so both RFC 3164 and RFC 5424 headers are accepted. What matters is that the pairs arrive intact: each event must reach Logsign as a single message, and the quoting around values must be preserved. Do not enable a CEF, LEEF or JSON output on the Bastion for this source, because only the native key/value format is parsed.

Step 2: Add the data source in Logsign USO

Open the Logsign USO web interface and click + Device under Settings > Data Collection. Choose Syslog as the collection method, select Wallix as the vendor and PAM as the product, and enter the IP address of the Bastion as the host. Click Save. Once the Bastion starts sending, events appear under Search.

Supported message format

Every Wallix Bastion message carries a bracketed source tag such as [rdpproxy], [sshproxy], [wabauth], [wabaudit] or [RDP Session], followed by key="value" pairs. Three typical events look like this (anonymized):

1 2026-09-16T11:27:52+02:00 wallix rdpproxy 1208735 - - [rdpproxy] psid="5733451208734" user="test_user" type="AUTHENTICATION_SUCCESS" method="Password"

1 2026-09-16T11:27:52+02:00 wallix WAB(root) 1208735 - - [wabauth] type="UserAuth" action="authentify" user="test_user" client_ip="192.0.2.10" status="success" infos="diagnostic [Authentication success: identified with local(LOCAL), authenticated with: LDAP_AUTH(LDAP).]"

1 2023-09-12T12:04:38+03:00 pam rdpproxy 9821 - - [RDP Session] session_id="18a889374c7c086a00505681868a" client_ip="192.0.2.20" target_ip="10.2.9.85" user="jdoe@example.com" device="SAPGUI" service="APP" account="jdoe@example.com" type="TITLE_BAR" source="Probe" window="ABAP Debugger(1)"

Values that contain spaces have to stay inside double quotes. Key names are used exactly as the Bastion writes them, so a renamed or lower cased key is not recognized.

What gets collected

Logsign fills the following fields from the Bastion key/value pairs. A field only appears on an event when the corresponding key is present in that message.

Every event is recorded with Vendor Wallix, Product PAM, EventSource Type Security System, EventSource Category Access Control and EventSource PrefixID 4392.

Event classification

Authentication events are classified from type and status. The proxy events written by [rdpproxy] and [sshproxy] have no status key, so the type alone decides the result. Bastion user authentication events written by [wabauth] carry type="UserAuth" and are classified by their status.

A single interactive login usually produces both a [wabauth] pair and a proxy event. The Bastion writes status="started" when the authentication attempt begins and follows it with status="success" or status="failure" for the same attempt. The started event is deliberately classified as Identity / User / Info instead of a login, so that one login is not counted twice in login rules and reports.

Notes and limits

• Session activity and audit events, for example [RDP Session] events such as TITLE_BAR, KBD_INPUT and FOREGROUND_WINDOW_CHANGED, and [wabaudit] configuration events, stay on Network / Connection / Info (60901). Use Event.Type and Event.Action to filter them.
• If your authentication events still arrive as Network / Connection / Info, the appliance is running an older version of the Wallix PAM plugin. The classification table above applies from the plugin update that introduced it. Contact Logsign support to confirm the version you need.
• Wallix messages do not carry a time_generated key, so Time.Generated is set when Logsign processes the message. For events that are delayed on the way, use the timestamp in the raw log to reconstruct the exact Bastion time.
• The event severity comes from the syslog priority of the incoming message, not from a field inside the Wallix event.

Verification

After both sides are saved, one login through the Bastion is enough to check the integration end to end.

• In Logsign USO, open Settings > Data Collection and confirm that the Wallix PAM source is receiving data.
• Log in through the Bastion to generate a test event. In Search, look for events with Vendor Wallix and Product PAM. The login should appear with EventMap Identity / User / Login and your user name in Source.UserName.
• Enter a wrong password once. That attempt should appear as Identity / User / Deny with Event.Type AUTHENTICATION_FAILURE, or as a [wabauth] event with status="failure".
• If the source is receiving data but no events show Vendor Wallix, the messages are not in a format this integration recognizes. Check that the Bastion is sending its native key/value format and that quoted values are not being split or rewritten on the way.