Configure log forwarders

Before You Begin

You must configure a log recipient to receive log events, including:

  • A logging server which can receive remote logging is configured and running.
  • Connection information for the remote logging consumer. For example:
    Fully qualified IP Address or DNS resolvable name of logger192.168.1.1

    Logger protocol

    TCP or UDP

    Logger listen port

    Appropriate port such as 5514.

    Important Note


    Note that the port being used to communicate between Access Gateway and the logging server must be open.
    Access Gateway will validate the logging server connection.

Creating a Log Forwarder Receiver

Important Note


This example uses graylog. It is purely instructional. For configuration of systems designed to receive the logging input, see their appropriate documentation.

To create a log forwarder in Graylog:

  1. Sign in to the Graylog console as admin.
  2. Select System > Inputs.
  3. In the Select Input drop down search for Syslog UDP.
  4. Click Launch new input.
  5. In the Launch New Syslog UDP Input dialog enter the following:






    An appropriate title.


    Enter an appropriate port.
    Reminder, this port must be accessible from the Access Gateway AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. instance.
    Okta recommends selecting port 2048 or higher to avoid operating system restrictions.

    Leave all other fields unchanged.
  6. Click Save.
  7. Return to the Access Gateway administration UI console.

Add a Log Forwarder

To add a remote logger:

  1. Navigate to your Access Gateway Instance.
  2. Select the Logs and Backups tab.
  3. Select the Log Forwarder pane .
  4. Select (+) > Syslog remote.
  5. In the Add Forwarder: Syslog pane enter the following.




    The name of the forwarder.


    One of:

    • AUDIT
    • ACCESS

    See Feed Examples for details of each feed.


    Select either UDP or TCP.  Ensure this protocol matches the log listener.


    Enter the DNS resolvable or IP address of the remote syslog listener.


    Enter the port of the remote syslog listener.

  6. Click Validate Forwarder.
    Access Gateway will then attempt to validate the remote logger connection information.
    If required correct any input errors.
    On success the Validate Forwarder button will become green and change to Forwarder Validated.
  7. Click Okay.
  8. The log forwarder definition will then appear in the list of log forwarders.


    The syslog definition will briefly be shown as testing and then will move to valid on success.

Test Log Forwarders

To test log forwarding you must have:

  • A configured log receiver. Follow the steps outlines in section Creating a Log Forwarder Receiver.
  • A log forwarder defined in your Access Gateway node. Access loggers are simplest to test, as then generate events based on sign in to the Access Gateway Console.
  • Be able to generate one or more events.
  1. Configure a system logger in your log server.
  2. Configure a log forwarder in Access Gateway, preferably an ACCESS logger.
  3. Ensure your system logger is started and ready to receive events
  4. Sign out and and then back into the Access Gateway Admin Console.
  5. Examine the log server. Multiple events should be generated resembling:

Feed Examples

For examples of Log file formats see: Log Formats and Examples.

Type Description
AUDIT Audit log events include log entries representing user authentication.
For details and examples of audit events see Log Formats and Examples/Gateway.

Sample Event:
Oct 5 22:57:05 Access Gateway ACCESS AUTHN SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. INFO USER_AUTHN [SESSION_ID="_6f89fde9801702d4055216fad847dc889536592839" SESSION_AUTH="_99077d998f2b3c0f65ee8dbea6abd1fb389a6e18a4" SUBJECT="<User login name>" TYPE="SAML_2_0" SOURCE="IDPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. Source URL" SOURCE_TYPE="<Identity Provider type>" SOURCE_DOMAINA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https).="<IDP URL>" SOURCE_AUTHN_TYPE="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" APPAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in.="Sample Header App" APP_DOMAIN="<App Domain URL>" RESULT="PASS" REASON="Valid SAML Assertion" REMOTE_IP="" USER_AGENTA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations.="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"] User login:<User login name>
ACCESS Access log events includes log entries representing user authorization and application accesses. For example, a particular user, accessed a particular application from a given IP address.
For details and examples of access events see Log Formats and Examples/Access Log.

Sample event:
Mar 28 13:13:57 sampleheaderapptest <App Domain URL> <User's IP Address> - - [28/Mar/2018:13:13:57 -0500] "GET / HTTP/1.1" 200 4828 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "<User's IP Address>" 0.006 0.001 .
MONITOR Monitor log events include log entries representing application configuration (add, delete, modify), Certificate configuration and Auth Module Configuration.
For details and examples of audit events see Log Formats and Examples/Process Monitor.

Sample event:
Oct 9 15:52:59 Access Gateway OAG_MONITOR MONITOR NGINXNginx is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache. INFO CONFIG_TEST [STATUS="VALID" UUID="9179e919-43dc-4396-8b26-164387213b1b"] nginx: the configuration file /tmp/nginx/nginx.conf syntax is ok nginx: configuration file /tmp/nginx/nginx.conf test is successful