IBM Support

IJ13746: INCONSISTENT USER INTERFACE STATUS MESSAGES AND ISSUE WITH AUTO ACQUIRE CERTIFICATE USING THE OKTA RESTAPI PROTOCOL

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as Permanent restriction.

Error description

  • It has been identifed that there are inconsistent and confusing
    status messages that can sometimes be generated when using the
    Otka RESTAPI Protocol along with functionality issues with the
    Auto Aquire Certificate option.
    UI:
    1) In some instances Log Source which which should throw error,
    stay as success.  Error message for an Okta Log Source recorded
    in qradar.error but nothing in User Interface (UI).
    When an error does appear for some Log Source in the UI, they
    can change from Error -> Success within few seconds (even when
    nothing is changed/refreshed for the Log source).
    2) UI status messages can be vague (eg. "Error communicating
    with remote Okta API resource").
    This general message can appear when there is a connection
    Drop/Rejected, when there is a wrong proxyIP, or when there is
    a wrong ProxyHost.
    3) When an error appears for any Log Source in qradar.error
    log, the debug log for that log source displays the message
    "status changed from HEARTBEAT to HEARTBEAT" repeatedly.
    Also observed can be message "Polling time has arrived. Will
    now try to execute quer(y|ies)" when the Log Source shouldn't
    be in HEARTBEAT once it throws the error.
    4) When setting incorrect Okta IP or Hostname while configuring
    an Okta Log source, an error message is generated in the
    qradar.error log (error displayed depends on whether you are
    using proxy or not).
    - When using proxy: nullpointerexception
    - When not using proxy the expected error message appears in
    the logs: "The Okta Remote IP or Hostname provided could not be
    reached."
    Proxy:
    Creating a Log Source with correct proxy information, then
    updating it with an incorrect proxy password: No error is
    thrown and events are received without issue.
    API:
    There is UI validation for proxyServer, proxyUsername &
    proxyPassword which restricts entering more than 255 characters.
    There is no restrictor in API for proxyServer, proxyUsername &
    proxyPassword that restricts entering more than 255 characters.
    Based on the sensorprotocolparameter proxyPort is required but
    proxy username is not required.  Also proxyPassword is required
    but proxy username is not required.
    If proxy port is required it becomes necessary to havve proxy
    IP as required and likewise if proxy password is required the
    proxy username should also be required.
    

Local fix

  • No workaround available.
    

Problem summary

  • It has been identifed that there are inconsistent and confusing
    status messages that can sometimes be generated when using the
    Otka RESTAPI Protocol along with functionality issues with the
    Auto Aquire Certificate option.
    UI:
    1) In some instances Log Source which which should throw error,
    stay as success.  Error message for an Okta Log Source recorded
    in qradar.error but nothing in User Interface (UI).
    When an error does appear for some Log Source in the UI, they
    can change from Error -> Success within few seconds (even when
    nothing is changed/refreshed for the Log source).
    2) UI status messages can be vague (eg. "Error communicating
    with remote Okta API resource").
    This general message can appear when there is a connection
    Drop/Rejected, when there is a wrong proxyIP, or when there is
    a wrong ProxyHost.
    3) When an error appears for any Log Source in qradar.error
    log, the debug log for that log source displays the message
    "status changed from HEARTBEAT to HEARTBEAT" repeatedly.
    Also observed can be message "Polling time has arrived. Will
    now try to execute quer(y|ies)" when the Log Source shouldn't
    be in HEARTBEAT once it throws the error.
    4) When setting incorrect Okta IP or Hostname while configuring
    an Okta Log source, an error message is generated in the
    qradar.error log (error displayed depends on whether you are
    using proxy or not).
    - When using proxy: nullpointerexception
    - When not using proxy the expected error message appears in
    the logs: "The Okta Remote IP or Hostname provided could not be
    reached."
    Proxy:
    Creating a Log Source with correct proxy information, then
    updating it with an incorrect proxy password: No error is
    thrown and events are received without issue.
    API:
    There is UI validation for proxyServer, proxyUsername &
    proxyPassword which restricts entering more than 255 characters.
    There is no restrictor in API for proxyServer, proxyUsername &
    proxyPassword that restricts entering more than 255 characters.
    Based on the sensorprotocolparameter proxyPort is required but
    proxy username is not required.  Also proxyPassword is required
    but proxy username is not required.
    If proxy port is required it becomes necessary to havve proxy
    IP as required and likewise if proxy password is required the
    proxy username should also be required.
    

Problem conclusion

  • A New protocol is in Development for Okta. This issue will not
    be addressed in any new RPM versions.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IJ13746

  • Reported component name

    QRADAR SOFTWARE

  • Reported component ID

    5725QRDSW

  • Reported release

    731

  • Status

    CLOSED PRS

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-02-14

  • Closed date

    2019-11-26

  • Last modified date

    2019-11-26

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU048","label":"IBM Software"}, "Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"731","Edition":""}]

Document Information

Modified date:
26 November 2019