About:
This article discusses SaaS Omnissa Access SIEM Integration with an On-Premises SYSLOG service in order to record and retain the SaaS Access Audit Log data for security records and troubleshooting.Introduction:
While the Omnissa documentation and actual integration are relatively straightforward and simple, there are some additional steps to take and topics to review in setting up SYSLOG integrations with a SaaS Access tenant. These items will be discussed individually in sections here; however, they should all be reviewed and worked through for any organization attempting this integration to ensure suggested changes meet your organization’s policies and requirements for secure communications between the SaaS Access tenant and an on-premises SYSLOG tenant.It should be noted, this article will specifically discuss SYSLOG integrations with a SaaS Access tenant. It will NOT discuss the other SIEM integrations which Omnissa Access supports, including Splunk or CrowdStrike.
In this article, I show the setup with Graylog, pfSense for firewalls, and an internal ADCS-created certificate.
Requirements:
The following items will be required for integration. They are in no particular order.SYSLOG tenant running on-premises
- SYSLOG Secure Listener configured and running on TCP 6514 (or whichever desired TCP port)
SYSLOG Secure Listener TCP port (6514 or whichever defined) publicly NAT’ed/LB with an externally routable IP and/or FQDN
- Optionally, Firewall filters for inbound traffic filtering to allow traffic from Omnissa Access SaaS tenant.
A CLIENT CERTIFICATE for use by the Omnissa Access tenant for authenticating to the SYSLOG Secure Listener on TCP 6514 (or whatever defined port).
- PEM formatted Certificates/Certificate Chains.
- PEM formatted RSA PRIVATE KEY.
SYSLOG Server Needs:
SYSLOG Secure Listener:
The SYSLOG Secure Listener will need to be up and running. See your SYSLOG provider for instructions on how to enable a secure listener on your SYSLOG server.In my case, I used Graylog as my SYSLOG server.
When setting up the SYSLOG Secure TCP Listener, it is generally recommended to have this ONLY accept secure settings and NOT also accept insecure settings. For other, insecure (or in the clear) listeners, use separate listeners on separate TCP (or UDP) ports as it is not recommended to expose insecure listeners to the Internet.
Additionally, even though it is optional within most SYSLOG providers, it is highly recommended for secure listeners to require client authentication to ensure only the necessary traffic is consumed and bad actors cannot access the SYSLOG system.
Understanding the Certificate Needs:
Client Certificates:
The client certificate is what is used by Omnissa Access to authenticate into the SYSLOG Secure Listener. This can be a generic client certificate or a specific client certificate (some SYSLOG servers only support the use of a single client certificate on a secure listener, and others can support multiple client certificates on a single listener - check with your SYSLOG provider to understand what your SYSLOG can support).When creating the Client Certificate, the Client Certificate can be created by either an internal or external CA. What you choose will depend on how your SYSLOG solution is deployed and what it supports.
In my case, I used Graylog as my SYSLOG server and chose to use an internal ADCS CA to generate the client certificate for my Omnissa Access tenant. For Graylog to both require client authentication and accept any client certificate signed by my internal ADCS CA, I provided the necessary certs in the path on the SYSLOG host(s) and defined this in the SYSLOG Secure Listener settings.
Creating the Client Certificate on ADCS:
To create the Client Certificate, I first needed to create an ADCS Certificate Template I could use for generating SYSLOG Client Certificates - which would also allow me to define any additional needed properties and would NOT require the certificate to be tied to an AD-joined computer object. To do this, within ADCS, under the Certificate Templates Console, I cloned the Domain Computer template and created a new SYSLOG CLIENT TEMPLATE with the following settings.Key Adjustments for Non-AD Clients
Below are the main changes needed for ADCS to supply a client certificate for syslog client authentication to a SYSLOG server.Change Subject Name tab → “Supply in the request”.
Enable Export private key under Request Handling.
Set Compatibility to a modern Windows Server version if possible.
Ensure EKU = Client Authentication (1.3.6.1.5.5.7.3.2).
Grant Enroll to whoever submits the CSR (likely an admin group).
With these settings, you’ll be able to generate CSRs on most any system, including iLinux/macOS (via OpenSSL), submit them against this template in ADCS, and export the resulting certificate + private key in PFX/PEM for use with your SYSLOG’s Secure Listener for Client Certificate authentication.
Detailed ADCS Computer Client Certificate Template Changes Per Tab:
Compatibility Tab
Certification Authority: If possible, set to the highest version your CA supports (e.g., Windows Server 2016/2019).
- You currently have Windows Server 2003 which disables modern options (key attestation, stronger crypto, etc.).
- If you can, bump this to at least Windows Server 2012 R2 or later.
Certificate Recipient: Not critical for Linux/macOS, but same guidance — choose the newest option supported.
General Tab
- Template display name: SyslogClient (good).
- Validity/Renewal: Reasonable defaults (1 year validity, 6-week renewal) — fine as is.
- Publish in AD: Not needed for non-domain systems → leave unchecked.
Request Handling Tab
Purpose: Signature and encryption is correct.
Allow private key to be exported:
- Enable this — Linux/macOS clients often require exporting the private key from Windows CA enrollment, since they won’t be using Windows Key Store.
Enroll without user input: Fine to keep as is, since requests will come via manual enrollment or certreq/OpenSSL → not autoenrolled.
Cryptography Tab
- Ensure minimum key size is 2048 (or 3072/4096 if your syslog server supports it).
- Provider: Allow Microsoft Enhanced RSA and AES Cryptographic Provider.
- If syslog supports ECC, you could configure an ECDSA template instead (P-256/P-384).
Subject Name Tab
For non-domain clients, select “Supply in the request”.
- This allows you to submit CSR with custom CN and SANs (DNS or IP of the syslog client).
- If you keep “Build from AD info,” non-domain clients won’t be able to get a proper name.
SAN (Subject Alternative Name): Ensure you can supply DNS/IP manually via CSR.
Extensions Tab
Application Policies (EKU):
- Must include Client Authentication (1.3.6.1.5.5.7.3.2).
- If server-side auth might also be needed, keep Server Authentication (1.3.6.1.5.5.7.3.1). This, however, is optional and not required for client authentication to succeed.
Key Usage:
- Should include Digital Signature (for TLS client auth).
- Key Encipherment is optional but commonly left enabled.
Security Tab
- Add a group/role (e.g., “Syslog Clients” or admins) with Enroll permission.
- If you want automated certificate pulls from non-AD machines, you’ll typically generate CSR externally and have an admin submit it.
Server & Issuance Requirements Tabs
- Server tab: leave defaults.
- Issuance requirements: Leave unchecked (no CA manager approval) unless you want manual approval for every cert.
Publishing the Client Certificate Template:
Once the above SYSLOG Client Certificate template is created in ADCS, you then need to publish the client certificate template in order for it to be used. This is done via the ADCS Certificate Authority MMC.EXE snap-in UI via the NEW>CERTIFICATE TEMPLATES TO ISSUE context menu option. See Microsoft documentation for any needed additional guidance on this.Creating the Client Certificates:
Once the above SYSLOG Client Certificate template is published in ADCS, you then need to request and create the client certificate. This can be done using ADCS UI via the MMC.EXE Certificates plugin or via OPENSSL (if on a system where OPENSSL is installed).- When requesting the certificate via the Certificate Request UI in Windows, it is required to utilize the Computer account.
- Within the Certificates MMC snap-in, using the context menus, request a new certificate.
- Click through the next few screens to get to the Certificate Templates selection and check the box to select your SYSLOG CLIENT template and then click the blue text “More information is required to enroll for this certificate. Click here to configure settings.” DO NOT CLICK ENROLL!!
- By clicking the blue text in the above screen, you will get the option to type in the common name and DNS (Subject Alternate Name or SAN) values you may wish to define.
After defining the common name and alternate settings needed for your environment, click OK and finish off the wizard by selecting ENROLL.
Once done, you will need to export the certificate and the private key and store all of it as a single, password-protected PFX/P12. Ensure you select “Yes, export the private key” in the MS Certificate Export Wizard.
- When exporting as a PFX/P12, you will want to include all certificates in the certificate path if possible, and enable certificate privacy. This will enable you to set a password on the exported certificate PFX bundle.
- Select your file name, path, and save the file.
Converting the Client Certificate(s) to PEM Format:
Omnissa Access requires the certificate bundle to be in a PEM format. This is similar to the below example.Example: PEM Certificate Example
| Certificate Chain Example |
| -----BEGIN CERTIFICATE----- |
| (Your Primary SSL certificate:your client_cert.crt) |
| -----END CERTIFICATE----- |
| -----BEGIN CERTIFICATE----- |
| (Your Intermediate/Issuing CA certificate: .crt) |
| -----END CERTIFICATE----- |
| -----BEGIN CERTIFICATE----- |
| Your Root CA certificate: TrustedRoot.crt) |
| -----END CERTIFICATE----- |
| Private Key Example |
| -----BEGIN RSA PRIVATE KEY----- |
| (Your PrivateKey: your_client_cert_key) |
| -----END RSA PRIVATE KEY----- |
Using OPENSSL is generally the industry baseline for converting a certificate (public or private, server or client) and certificate private key from one format to another. Once the certificates and key are converted to PEM format, they are ready for use within Access to provide your SaaS Access tenant the ability to perform client authentication into your on-premises SYSLOG via its SYSLOG Secure Listener.
Server Certificates:
There are no needs for creating server certificates in this deployment. Additionally, the SYSLOG web admin UI does not need to be publicly exposed just for Omnissa Access to route traffic to the SYSLOG Secure Listener. Should you choose to do this, I highly recommend securing this traffic with multiple layers of security - including TLS security for Admin UI communications as well as authentication and authorization security in the form of Identity Providers and Multi-Factor Authentications/Authorizations.Firewall Needs:
External SYSLOG Secure Listener:
The SYSLOG Secure Listener will need to be publicly exposed at this time as SaaS instances of Omnissa Access do not (at this time) support proxying SYSLOG traffic via the Access Connectors (something Omnissa Workspace ONE UEM ACCs do support). This means - assuming use of TCP 6514 (the default SYSLOG Secure Listener port) - TCP 6514 will need to be available on a publicly routable IP address and routed inbound to the SYSLOG Secure Listener port on the internal SYSLOG server.NAT Rules:
Optional Inbound Traffic Filters:
If inbound filters are desired with Omnissa Access, please see Omnissa KB68035 to obtain the latest SOURCE IPs list and use those to build the correct filters for applying to your firewall rules.NOTE: In the above screenshots, I am showing filters in use on my firewall rules.
Applying Changes to Access:
Enabling the SYSLOG SIEM Adapter in Omnissa Access:
When enabling the SYSLOG adapter for use to send Access Audit Logs to SYSLOG, the Omnissa Access documentation provides step-by-step instructions to apply the settings once all of the other requirements have been met above. Essentially, the steps are: enable the SYSLOG Adapter and fill in the necessary information and save the data.
Troubleshooting:
If successful, you will see Access report “Adapter connected” in green.
If unsuccessful, you will see a “Connection failure” in red and the reason why.
Aside from removing firewall filters and checking the SYSLOG Secure Listener is up and running, you may wish to review Omnissa’s documentation on “Troubleshooting TLS Encrypted Message Transfer” as this assists in any potential TLS issues.