> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # IBM QRadar SIEM > Connect your IBM QRadar SIEM Console to Oleria to discover its users, user roles, security profiles, authorized service tokens, apps, and log collectors, and its sign-in and audit activity. Connect IBM QRadar SIEM to Oleria to see who and what can act on your QRadar Console: its users and the user roles and security profiles that grant their access, the authorized service tokens that call its API, the App Framework apps and log collectors that run on it, and what they do with that access. Oleria connects with an authorized service token or a QRadar username and password, and can also disable, enable, create, and delete users, change a user's role or security profile, and disable authorized service tokens and apps. > [!NOTE] > > This integration supports QRadar SIEM Consoles that serve QRadar REST API version 20.0 to 29.0: on-premises QRadar 7.5.0 Update Package 6 or later, and QRadar on Cloud. Each integration connects one Console. If you have more than one, add an integration for each. See [Multi-instance support](/integrations/overview.md#multi-instance-support). ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Console: * **Users** - every deployed QRadar user, with username, email, user role, security profile, and, on multi-tenant Consoles, tenant. Oleria also shows: * **Status** - a user on QRadar's built-in **Disabled** user role is shown as disabled. Every other user is shown as enabled. * **Administrator status** - users whose role holds **System Administrator** (`ADMIN`), **Security Administrator** (`SAASADMIN`), or **Administrator Manager** (`ADMINMANAGER`) are marked as administrators. * **Last login** - the user's most recent successful sign-in from QRadar's login history. * **Password age** - when the user's current local QRadar password was set. * **Authentication method** - password sign-in for local users, or single sign-on (SSO) when the Console uses SAML and the user isn't **Local Only**. Users who signed in to the API with a username and password are marked as having API access. * **User roles** - every user role, with the QRadar capabilities it grants. QRadar's built-in **Admin**, **All**, **WinCollect**, and **Disabled** roles are marked as standard roles, and all others as custom roles. Each user and authorized service holds exactly one role. * **Security profiles** - every security profile, shown as a group. A security profile controls which domains, networks, and log sources its members can see, so each membership lists the profile's domains. A profile with no domains grants all data. The built-in **Admin** profile is marked as built in. Each user and authorized service belongs to exactly one profile. * **Non-human identities (NHIs):** | Identity | Shown as | | :- | :- | | Authorized services | API token, with its user role, security profile, tenant, creation date, expiry date, and last use. Once its expiry date has passed, the token is shown as disabled, and its credential as expired. A service with no expiry date is marked as never expiring. When QRadar reports who created the service, and that user or authorized service is discovered, it's shown as the token's owner. | | App Framework apps | Application, enabled while the app is running. Oleria shows the QRadar user whose authority the app uses, the capabilities the app requests, its security profile, and the user who installed it, shown as its owner. | | WinCollect agents | Workload identity, enabled when QRadar reports the agent as enabled, with its host, version, and last heartbeat. | | Disconnected Log Collectors | Workload identity, with its host, creation date, and last event time. A collector whose status reports a failure or a disabled state is shown as disabled. Its public authentication keys and client certificate appear as credentials, and the certificate shows its expiry date. | * **Activity** - two QRadar audit sources: * successful and failed sign-ins from QRadar's login history, with the source IP address and whether the user signed in through the Console or the API; * SIM Audit events from QRadar's event store: configuration changes (authorized services added or removed, users added or deleted, user role and security profile changes, password changes, and other settings changes), user actions, sign-outs and expired sessions, and Risk Manager configuration changes. Every event keeps its QRadar event name. Events are attributed to the user or authorized service that made them. QRadar's own system events are attributed to a **QRadar system** account. Events from a username Oleria can't match, such as a deleted user, keep that username but have no actor. On a [Username and password](#connect-qradar-to-oleria) connection, Oleria drops the events of its own QRadar user. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > This integration covers identities, roles, security profiles, NHIs, and activity. It doesn't inventory log sources, domains, offenses, rules, or reference data, so Oleria doesn't populate resource-level Access Graph or Access Inventory data for QRadar. A security profile's domain scope appears on its memberships. > > QRadar has no AI agent objects, so none appear. AI features such as the QRadar Investigation Assistant are installed as App Framework apps, so they appear as App Framework app NHIs. ## Prerequisites * A QRadar SIEM Console reachable from the internet over HTTPS on port `443`, by DNS name. Oleria doesn't connect to IP addresses, other ports, or through an on-premises agent. * The Console's host on Oleria's egress allowlist. Before you connect, contact [support@oleria.com](mailto:support@oleria.com) with the Console's host name, such as `qradar.example.com`, and ask for it to be allowlisted. * A QRadar administrator who can create user roles and authorized services and deploy changes. * A user role for Oleria with these QRadar capabilities, and the **Admin** security profile. See [Create the Oleria credential in QRadar](#create-the-oleria-credential-in-qradar). * **System Administrator** (`ADMIN`). On QRadar on Cloud, **Security Administrator** (`SAASADMIN`) can replace it for reading, with the limits in [Known limitations](#known-limitations). * **Administrator Manager** (`ADMINMANAGER`) * **Log Activity** (`EventViewer`) * Optional: the PEM-encoded CA certificate that issued the Console's TLS certificate, if the Console uses a self-signed or private certificate. Oleria always verifies the Console's certificate. * Admin access on the Oleria platform to add a new integration. > [!NOTE] > > Use a dedicated authorized service for Oleria rather than a person's account. QRadar recommends authorized service tokens for API integrations, and the token carries its own user role and security profile, so Oleria's access is easy to review in QRadar. If your policy doesn't allow authorized services, use a dedicated local QRadar user with the same role and security profile instead. > [!WARNING] > > QRadar has no read-only administrator capability. **System Administrator** is needed to read every user, role, and security profile, and it also lets the credential change them. Oleria uses the same credential for [remediation actions](#remediation-actions), so store the token or password securely. ## Create the Oleria credential in QRadar **1. Create a user role for Oleria** In the QRadar Console, go to **Admin** > **User Management** > **User Roles** and create a user role, such as `Oleria`. Select these capabilities, then save the role: * **System Administrator** (`ADMIN`). On QRadar on Cloud, select **Security Administrator** (`SAASADMIN`) if your role can't hold **System Administrator**. * **Administrator Manager** (`ADMINMANAGER`) * **Log Activity** (`EventViewer`) The tables below show what each capability is used for. **2. Create an authorized service** Go to **Admin** > **User Management** > **Authorized Services** and click **Add Authorized Service**. Then: 1. Enter a service name, such as `Oleria`. 2. Select the user role you created and the **Admin** security profile. Leave **Tenant** empty. 3. Set an expiry date that matches your credential rotation policy. QRadar's default is 30 days. When the token expires, syncs stop. 4. Create the service and copy its token. QRadar shows the token only once. You enter it as **Authorized service token** when you connect. To connect with a username and password instead, go to **Admin** > **User Management** > **Users** and create a local user with the same user role and the **Admin** security profile. A SAML user must be **Local Only**. **3. Deploy changes** On the **Admin** tab, click **Deploy Changes**. QRadar doesn't activate a new user role, authorized service, or user until you deploy. **4. Get the Console allowlisted** If you haven't already, send the Console's host name to [support@oleria.com](mailto:support@oleria.com) and wait for confirmation that it's on Oleria's egress allowlist. If the Console uses a self-signed or private certificate, export the issuing CA certificate in PEM format. ### Permissions for reading | QRadar capability | What Oleria reads with it | | :- | :- | | **System Administrator** (`ADMIN`) | Every user, user role, security profile and its domains, and tenant; the Console's authorization settings and password policy; every user's login history; App Framework apps; WinCollect agents; and Disconnected Log Collectors. Oleria's **Read users**, **Read groups**, and **Read roles** capabilities each need it. Without it, QRadar returns only the credential's own user, so Oleria refuses the connection. | | **Security Administrator** (`SAASADMIN`) | QRadar on Cloud alternative to **System Administrator** for reading users, user roles, and security profiles only. See [Known limitations](#known-limitations) for what it doesn't read. QRadar then hides every user and user role that holds **System Administrator**. | | **Administrator Manager** (`ADMINMANAGER`) | Every authorized service. Without it, QRadar lists only the authorized services this credential created. | | **Log Activity** (`EventViewer`), with the **Admin** security profile | SIM Audit events. Oleria runs searches on your Console's event store, one per day of history, and deletes each search after reading its results. Without it, Oleria skips SIM Audit events and still reads the login history. | ### Permissions for remediation actions Remediation actions are optional. They need these capabilities on the same credential: | Action | QRadar capability | | :- | :- | | Disable user accounts, Enable user accounts, Add user to role, Remove user from role, Add user to group, Delete user | **System Administrator** (`ADMIN`). Also **Administrator Manager** (`ADMINMANAGER`) when the user's current or new role holds **System Administrator** or **Security Administrator**. | | Create user | **System Administrator** (`ADMIN`) | | Disable NHI accounts - authorized service | **Administrator Manager** (`ADMINMANAGER`). For an authorized service that's **Local Only**, QRadar also requires **Manage Local Only** (`MNGELOCALONLY`). | | Disable NHI accounts - App Framework app | **System Administrator** (`ADMIN`) | ## Connect QRadar to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **IBM QRadar SIEM**. **2. Complete the connection form** Select your **Authentication method** first. The form shows only the fields that method needs. | Field | Notes | | :- | :- | | **QRadar Console URL** | Required. Your Console's address, for example `https://qradar.example.com`. It must use `https`, a DNS name rather than an IP address, and port `443`. If you paste an address ending in `/api` or `/console`, Oleria removes it. You can't change this field later. | | **Authentication method** | Select **Authorized service token** (default, recommended) or **Username and password**. | | **Authorized service token** | Required for **Authorized service token**. The token you copied when you created the authorized service. | | **Username** | Required for **Username and password**. The dedicated QRadar user you created. | | **Password** | Required for **Username and password**. That user's password. | | **Console CA certificate (PEM)** | Optional. One or more PEM-encoded CA certificates for a Console with a self-signed or private certificate. Paste only complete certificate blocks, from `-----BEGIN CERTIFICATE-----` to `-----END CERTIFICATE-----`. Other text, such as a private key or `Bag Attributes` lines, is rejected. Oleria trusts these certificates for this integration only. | **3. Authenticate** Select **Authenticate**. Before it saves anything, Oleria connects to the Console, agrees on a QRadar API version, and reads the credential's user role. If the role has neither **System Administrator** nor **Security Administrator**, Oleria refuses the connection. If the role lacks **Administrator Manager** or **Log Activity**, Oleria still connects, but reads less, as described in [Permissions for reading](#permissions-for-reading). Find the newly connected Console on the **Connected** tab of your Oleria **Integrations** page, named **IBM QRadar SIEM (*host*)**. If **Authenticate** fails, the message says what's wrong: * **QRadar rejected the credential (HTTP 401)** - check the token, or the username and password. Check that the authorized service hasn't expired and that you deployed changes after creating it. * **The QRadar credential's user role lacks System Administrator** - assign a user role with **System Administrator** and the **Admin** security profile, then deploy changes. * **QRadar Console ... is not reachable from Oleria** - check that the Console is reachable over public HTTPS on port `443`, and that Oleria support has added its host to the egress allowlist. * **The QRadar Console ... presented a certificate Oleria does not trust** - paste the Console's CA certificate into **Console CA certificate (PEM)**, or install a publicly trusted certificate on the Console. A host that isn't on Oleria's egress allowlist can also cause this error. * **QRadar REST API not found (HTTP 404)** - check that **QRadar Console URL** is your Console's address. * **The console offers no supported REST API version** - the Console runs a QRadar release older than 7.5.0 Update Package 6. Upgrade the Console, then try again. > [!NOTE] > > When the authorized service's token expires, QRadar rejects it and syncs fail. Before it expires, add a new authorized service in QRadar, deploy changes, and enter the new token by editing the integration. ### Edit the integration When you edit the integration, you can change **Authentication method**, **Authorized service token**, **Username**, **Password**, and **Console CA certificate (PEM)**. **QRadar Console URL** can't be changed. To connect a different Console, add a new integration. * Leave **Authorized service token** or **Password** blank to keep the stored value. * If you switch **Authentication method**, enter the credential for the new method. * Clear **Console CA certificate (PEM)** to remove the stored CA certificates. Select **Update** to save. Oleria runs the same checks as **Authenticate**. ## Verify the integration Confirm the Console appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered users, user roles, security profiles, NHIs, and activity in your Oleria workspace. In the integration's **Capabilities and operation readiness** section, **Read users**, **Read groups**, and **Read roles** show **Available**. If one shows **Needs permission**, check that the credential's user role still holds **System Administrator**, or **Security Administrator** on QRadar on Cloud. If authorized services are missing, check that the role holds **Administrator Manager**. If sign-ins appear but no SIM Audit events do, the role lacks **Log Activity** or the credential doesn't have the **Admin** security profile. ## Remediation actions Oleria can take these actions in QRadar: | Action | What it does | Revert | | :- | :- | :- | | Disable user accounts | Moves the user to QRadar's built-in **Disabled** user role, which is how QRadar disables a user. Oleria records the user's previous role in the user's description, as `[oleria:disabled prior_user_role_id=]`. | Supported - restores the previous role and description. | | Enable user accounts | Restores the role Oleria recorded when it disabled the user, and removes the note from the description. | Supported - moves the user back to the **Disabled** role. | | Add user to role | Gives the user the role. A QRadar user holds exactly one role, so this replaces the user's current role. | Supported - restores the previous role. | | Remove user from role | Moves the user to the **Disabled** role. QRadar requires every user to hold a role, so removing the user's only role disables the user. Oleria records the removed role in the user's description, the same way **Disable user accounts** does, so **Enable user accounts** can restore it. | Supported - restores the role and description. | | Add user to group | Moves the user to the security profile. A QRadar user belongs to exactly one security profile, so this replaces the user's current profile. | Supported - restores the previous security profile. | | Create user | Creates a QRadar user with the username, email, and password you provide, in the one security profile you select. The user is created on the **Disabled** role, so they can't sign in until you give them a role with **Add user to role**. Oleria uses the first and last name as the user's description. | Supported - deletes the user the action created. | | Delete user | Deletes the user from QRadar. The action's result records the username. | Not supported. A deleted QRadar user can't be restored. A user created again gets a new ID and no history. | | Disable NHI accounts | For an authorized service, sets its expiry date to now, so its token stops working, then runs an incremental deploy so the change takes effect (see the warning below). QRadar may set the expiry up to a minute later. If the deploy doesn't start, Oleria restores the previous expiry date and the action fails. If the deploy starts but doesn't finish within 10 minutes, Oleria waits up to 10 more minutes, and the action succeeds if the deploy then completes without errors. If it's still running, or QRadar reports errors, the action fails without restoring the expiry date, because the deploy may already have applied it. Check the authorized service and the **Admin** tab before you run the action again. Disabling an authorized service needs **System Administrator** as well as **Administrator Manager**. For an App Framework app, stops the app. WinCollect agents and Disconnected Log Collectors can't be disabled, because the QRadar API has no way to disable them. | Supported - restores the authorized service's previous expiry date, or no expiry, or restarts the app. The revert deploys the same way: if its deploy starts but doesn't complete cleanly, the revert fails and the restored expiry date may already be active, so check the authorized service. | > [!WARNING] > > **Every user action deploys all pending changes on the Console.** QRadar stages changes to users and activates them only on deploy. So every action that changes a user, and every revert of one, ends with an incremental deploy, which also activates any other changes pending on the Console, including other administrators' unfinished edits. **Disable NHI accounts** also deploys when it disables an authorized service, and when it reverts one. Stopping an App Framework app doesn't deploy. Before you approve an action, check the **Admin** tab for pending changes. > [!NOTE] > > The **Remediations** page offers **Revert** only for **Disable user accounts** and **Disable NHI accounts**. The integration supports the other reverts in this table, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed. Keep these limits in mind when you use these actions: * Oleria refuses to change QRadar's default `admin` user, and the QRadar user this integration signs in as. * Disabling the authorized service this integration connects with fails, because QRadar doesn't let an authorized service change itself. * **Enable user accounts** works only for a user that Oleria moved to the **Disabled** role, with **Disable user accounts** or **Remove user from role**, because it needs the role Oleria recorded. It also refuses to restore a role that holds **System Administrator**, **Security Administrator**, or **Administrator Manager**, because anyone who can edit the user's description could change the recorded role. In both cases, use **Add user to role** instead. * **Add user to role** can't assign the **Disabled** role. Use **Disable user accounts** instead. * QRadar requires the **Admin** security profile for users whose role holds **System Administrator** or **Security Administrator**. Oleria refuses to give such a role to a user outside the **Admin** profile, or to move such a user to another profile. * If the user already has the role, profile, or status the action asks for, Oleria makes no change. If the change is staged but not deployed, Oleria deploys it only when the staged change carries Oleria's description note, which is the case for **Disable user accounts** and for **Remove user from role** to **Disabled**. Otherwise the action fails without changing anything, and says that another change is pending for the user. Deploy or discard that change on the QRadar **Admin** tab, then run the action again. Running **Create user** or **Delete user** again also deploys a user or a delete that an earlier attempt staged. **Create user** refuses a username that a different staged change already uses, so deploy or discard that change first. **Delete user** succeeds without a change if the user is already gone. * Reverting an action changes only what the action changed. If the user's role, profile, or the authorized service's expiry date changed since the action, or the app is no longer stopped, the revert makes no change and says why. * **Create user** needs exactly one security profile, and a password when the Console uses QRadar's own authentication. Oleria can't generate a password. Usernames must be 1-60 characters without quotes or slashes, and can't match an existing user or authorized service. * If another deploy is running on the Console, Oleria waits up to 5 minutes for it to finish before it deploys. If the Console is still busy after that, the action fails and Oleria rolls back the change it staged, so nothing it wrote stays pending. If Oleria's own deploy doesn't finish within 10 minutes or QRadar reports errors for it, Oleria waits up to 10 more minutes and then checks the user. If the change took effect, the action succeeds. If it didn't, Oleria rolls back the staged change and the action fails. If Oleria still can't tell, the action fails without a rollback and says so, because rolling back a change that took effect would undo it at the next deploy. Check the user and the **Admin** tab before you run the action again. A rolled-back **Create user** deletes the staged user. If the rollback also fails, the error says so and the change stays staged, so it would take effect at the next deploy, including one another administrator runs. Deploy or discard it on the QRadar **Admin** tab. A failed deploy after **Delete user** can't be rolled back, so the delete stays staged. ## Known limitations * **Some actions aren't in QRadar's API.** QRadar's API has no way to remove a user from a security profile (every user needs one), end another user's sessions, or create a security profile. Oleria doesn't offer **Remove user from group**, **Revoke sessions**, or **Create group** for QRadar. Security profiles and user roles also can't be nested, and security profiles have no owners. * **MFA and SSO are inferred.** QRadar has no multi-factor authentication (MFA) of its own, and its API doesn't report the authentication module (LDAP, RADIUS, TACACS, or SAML) the Console uses. Oleria infers SAML from the Console's authorization settings. Local users show MFA as not required. Other users show MFA as unavailable, because MFA in your identity provider isn't visible to QRadar. Users of LDAP, RADIUS, and TACACS look the same as local users. * **Last login depends on login history retention.** Oleria takes last login from QRadar's login history, which QRadar keeps only for the Console's login history retention period. A user with no sign-in in that period shows no last login. QRadar doesn't record failed sign-ins for SAML users. On a Console with more than 20,000 API (HTTP Basic) sign-ins in its login history, Oleria doesn't report which users use the API. * **No creation date or password expiry.** QRadar doesn't report when a user was created. Oleria shows when each local password was set, but not when it expires. * **90 days of history.** When you connect, Oleria reads up to 90 days of activity, and the login history goes back no further than its retention period. SIM Audit events from the last five minutes are read on the next sync. * **Oleria's own activity.** On a **Username and password** connection, Oleria drops the events of its own QRadar user. On an **Authorized service token** connection, QRadar doesn't identify which authorized service is calling, so Oleria's own sign-ins and changes appear as activity of its authorized service. * **QRadar on Cloud credentials.** With **Security Administrator** instead of **System Administrator**, QRadar hides every user and user role that holds **System Administrator**. Oleria shows a group named **System Administrators not visible to this credential (synthesized)** and a role named **ADMIN capability (synthesized)** to flag them, with no members. Without **System Administrator**, the login history holds only the credential's own sign-ins, so users show no last login and no sign-in activity. App Framework apps, WinCollect agents, and Disconnected Log Collectors may not appear, and security profiles may lack their domain names. Remediation actions on users need **System Administrator**, so they're unavailable with a **Security Administrator** credential. * **Authorized services need Administrator Manager.** Without it, Oleria discovers only the authorized services this credential created. * **Apps and their tokens aren't linked.** An App Framework app uses its own authorized service. That service appears as a separate API token NHI, not linked to the app. * **App Framework disabled.** If the App Framework is disabled on the Console, no apps appear. * **Log collectors can't be disabled.** QRadar's API has no way to disable WinCollect agents or Disconnected Log Collectors. * **Network access.** Oleria connects only over public HTTPS on port `443`, to a Console host that Oleria support has added to the egress allowlist. Each Console's host is allowlisted separately, and there's no on-premises agent option. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.