One Identity Cloud PAM is one of the latest security products by One Identity. It provides asset management as well as secure and monitored remote access for One Identity Cloud users to hosts on their local network. Last year, I showed you how collect One Identity Cloud PAM Network Agent log messages on Windows and create alerts when somebody connects to a host on your local network using PAM Essentials. This time, I will show you how to work with the Linux version of the Network Agent.
Over the past year, there have been many improvements to One Identity Cloud PAM . The one I show you in this blog is the freshly introduced One Identity Network Agent for Linux. You will see that you can reuse the syslog-ng configurations from last year with slight modifications.
However, there are many other changes. One of my favorite changes is that you can connect to hosts not just using native tools, but also from a browser. You can even work in a really restricted environment, when native tools or firewall permissions are missing.
Before you begin
This is a technical blog about syslog-ng. I have already shown you enough of One Identity Cloud PAM Essentials to understand what I am doing on the syslog-ng side in my first PAM Essentials blog. If you want to learn more about One Identity Cloud PAM , check out the press release at: https://www.oneidentity.com/community/news/b/press-releases/posts/one-identity-cloud-pam-essentialssm-launched-to-streamline-management-and-strengthen-protection-of-privileged-access .
On the syslog-ng side, you can use both syslog-ng Premium Edition or Open Source Edition installed on the same host where the One Identity Network Agent is running. The configuration I show should work with both. In this case, I used syslog-ng OSE 4.8.1 (the currently available latest version), and the same configuration should work with the latest syslog-ng PE version (8.0).
What we are trying to achieve
Part one of my blog showed you how to collect log messages centrally. Part two showed how to work with the collected logs, store logs to multiple destinations, and send alerts to Slack if a new connection is initiated through the One Identity Network Agent running on Windows. In this blog, I will show you a simplified use case, which allows you to get started easily:
-
Collecting One Identity Network Agent logs on Linux, while properly handling multi-line log messages.
-
Parse the collected log messages using PatternDB
-
Store the results to a JSON formatted log file to be able to see parsed name-value pairs.
-
Send an “alert” if a new connection is made through the One Identity Network Agent.
The end result is simple, and probably not too practical. However, it is a good starting point, where you can extend it in many directions: adding multiple destinations for analytics, real alerting, and so on. In case of syslog-ng PE you can also add a LogStore for secure long term storage: an encrypted, timestamped, and compressed destination.
Parsing connection logs
The log format we parsed in my previous blog is slightly different from what we have now. There are two main differences:
-
The syslog-ng Agent for Windows also includes the file name in the log message.
-
The syslog-ng Agent for Windows sets the application name to syslog-ng-agent for logs read from files.
So, here is a slightly modified PatternDB XML file. It removes the file name from the log messages and sets the program name to “oina”. This is a value we set in the syslog-ng configuration. Copy & paste the XML from below into a file called oina.pdb and save it under /etc/syslog-ng/conf.d/ (or /opt/syslog-ng/etc/ in case of syslog-ng PE).
<?xml version='1.0' encoding='UTF-8'?>
<patterndb version='3' pub_date='2025-04-10'>
<ruleset name='oina' id='c800f393-45c3-456b-8c8e-e685ea947a36'>
<description>
This ruleset covers the One Identity Network Agent logs
</description>
<url>www.oneidentity.com</url>
<pattern>oina</pattern>
<rules>
<rule provider="CzP" id="86b694bf-868d-45d8-8347-a7ef8d72f4c2" class="system">
<patterns>
<pattern>@ESTRING:oi.date: [@@ESTRING:oi.level:]@@ESTRING::client: @@ESTRING:oi.clientid:; id: @@ESTRING:oi.sessionid:; target: @@ESTRING:oi.targethost::@@ANYSTRING:oi.targetport@</pattern>
</patterns>
<examples>
<example>
<test_message program="oina">2025-04-03 15:50:32.944 +02:00 [DBG] [secure-gateway-client:log] [2025-04-03T13:50:32Z DEBUG client::connection] Initiating new connection; client: bd5a41cb-80f1-4475-9297-ce2b087b2400; id: 093923a3-2198-4ef4-b497-cda4ee700f37; target: 172.16.167.182:22</test_message>
<test_values>
<test_value name="oi.date">2025-04-03 15:50:32.944 +02:00</test_value>
<test_value name="oi.level">DBG</test_value>
<test_value name="oi.clientid">bd5a41cb-80f1-4475-9297-ce2b087b2400</test_value>
<test_value name="oi.sessionid">093923a3-2198-4ef4-b497-cda4ee700f37</test_value>
<test_value name="oi.targethost">172.16.167.182</test_value>
</test_values>
</example>
</examples>
</rule>
<rule provider="CzP" id="3e9bdb97-c15c-4707-a461-21cfe60a145e" class="system">
<patterns>
<pattern>@ESTRING:oi.date: [@@ESTRING:oi.level:]@@ESTRING::closed; id: @@ANYSTRING:oi.sessionid@</pattern>
</patterns>
<examples>
<example>
<test_message program="oina">2025-04-10 09:51:08.146 +02:00 [DBG] [secure-gateway-client:log] [2025-04-10T07:51:08Z DEBUG client::connection] Connection closed; id: eaf7fbc3-a4f0-477c-95ad-e3a3f1d9110c</test_message>
<test_values>
<test_value name="oi.date">2025-04-10 09:51:08.146 +02:00</test_value>
<test_value name="oi.level">DBG</test_value>
<test_value name="oi.sessionid">eaf7fbc3-a4f0-477c-95ad-e3a3f1d9110c</test_value>
</test_values>
</example>
</examples>
</rule>
</rules>
</ruleset>
</patterndb>
Configuring syslog-ng
Create a new file under /etc/syslog-ng/conf.d/ with a .conf extension (or append to /opt/syslog-ng/etc/syslog-ng.conf in case of syslog-ng PE):
source s_oina {
wildcard-file(
base-dir("/opt/oneidentity/oina/Logs/")
filename-pattern("*.txt")
multi-line-mode(regexp)
multi-line-prefix("[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}")
program-override("oina")
flags(no-parse)
);
};
destination d_oina_json {
file("/var/log/oina_json.txt" template("$(format-json --scope rfc5424
--scope dot-nv-pairs --rekey .* --shift 1
--scope nv-pairs)\n"));
};
parser p_connect {
db-parser(file("/etc/syslog-ng/conf.d/oina.pdb"));
};
log {
source(s_oina);
parser(p_connect);
destination(d_oina_json);
if ("${oi.targethost}" ne "") {
if ("${oi.targethost}" ne "127.80.65.77") {
destination {file("/var/log/alert" template("${DATE} OI Network Agent connection to ${oi.targethost} to port ${oi.targetport}\n"));};
};
};
};
This simple syslog-ng configuration snippet has three building blocks and a log path that connects them together. Let me explain what we have here and why:
-
The source reads the One Identity Network Agent logs using a wildcard-file() driver. It reads .txt files from the given directory. There are some multi-line logs, which can be identified by a regular expression. We also set the program name to “oina”, which we use in the PatternDB XML file.
-
The file destination uses JSON formatting, making sure that you can see any name-value pairs created by PatternDB.
-
The PatternDB parser has a single parameter, the file name of the XML database. Make sure that you use /opt/syslog-ng/etc/oina.pdb in case of syslog-ng PE.
-
The log path connects all building blocks together and has some extra logic for alerting. If the oi.targethost name-value pair is not empty and does not point at the localhost (see behind the scenes story in the second PAM Essentials blog), then it creates an “alert” (a log message with a custom template) into a file.
Testing
Once you restarted syslog-ng for the configuration to take effect, you are ready for some testing. After a few minutes, you should already see some log messages appearing in /var/log/oina_json.txt. For example:
{"oi":{"sessionid":"1c711db6-1b92-4205-a313-7a32d6b4512d","level":"DBG","date":"2025-04-14 13:51:00.102 +02:00"},"classifier":{"rule_id":"3e9bdb97-c15c-4707-a461-21cfe60a145e","class":"system"},"SOURCE":"s_oina","PROGRAM":"oina","PRIORITY":"notice","MSGFORMAT":"raw","MESSAGE":"2025-04-14 13:51:00.102 +02:00 [DBG] [secure-gateway-client:log] [2025-04-14T11:51:00Z DEBUG client::connection] Connection closed; id: 1c711db6-1b92-4205-a313-7a32d6b4512d","HOST_FROM":"localhost","HOST":"localhost","FILE_NAME":"/opt/oneidentity/oina/Logs/log20250414.txt","FACILITY":"user","DATE":"Apr 14 13:53:53"}
As you can see, it is JSON formatted, and next to the regular syslog fields you can also see some values parsed by one of the PatternDB rules.
Now connect to a host on your local network through PAM Essentials. In this case, you should see a log message which also has oi.targethost defined:
{"oi":{"targetport":"22","targethost":"172.16.167.182","sessionid":"6bea7377-9ee3-49ef-a949-d8c3fe06a5da","level":"DBG","date":"2025-04-10 10:55:58.045 +02:00","clientid":"bd5a41cb-80f1-4475-9297-ce2b087b2400"},"classifier":{"rule_id":"86b694bf-868d-45d8-8347-a7ef8d72f4c2","class":"system"},"SOURCE":"s_oina","PROGRAM":"oina","PRIORITY":"notice","MSGFORMAT":"raw","MESSAGE":"2025-04-10 10:55:58.045 +02:00 [DBG] [secure-gateway-client:log] [2025-04-10T08:55:58Z DEBUG client::connection] Initiating new connection; client: bd5a41cb-80f1-4475-9297-ce2b087b2400; id: 6bea7377-9ee3-49ef-a949-d8c3fe06a5da; target: 172.16.167.182:22","HOST_FROM":"localhost","HOST":"localhost","FILE_NAME":"/opt/oneidentity/oina/Logs/log20250410.txt","FACILITY":"user","DATE":"Apr 10 10:56:05"}
And this time, you should also see a new message in /var/log/alert with several of the name-value pairs included from the log message:
[root@localhost log]# tail -1 /var/log/alert Apr 10 10:56:05 OI Network Agent connection to 172.16.167.182 to port 22
What is next?
As also mentioned earlier, this blog shows you only a bare-bone configuration. In a production environment, you might want to store logs locally for long term storage (using LogStore if you use syslog-ng PE), and one or more destinations over the network where log messages are further analyzed. Alerts in a text file are very useful for debugging a configuration. However, using a Slack or Telegram destination, where your security admins learn about new connections in real-time, is even more useful.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.