> ## 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. # NetIQ Identity Manager > Install the Oleria NetIQ-Connect Agent on a Windows host to discover Identity Vault users, groups, roles, resources, and connected-system accounts, plus optional CEF audit activity. Connect NetIQ Identity Manager to Oleria to see who has access to what across your Identity Vault: users, groups, Identity Manager roles, resources, and the connected systems users are provisioned to. Oleria reads the eDirectory Identity Vault over LDAPS through an Oleria agent that you install on a Windows host in your network, using a service account. The service account only needs read rights unless you use [remediation actions](#remediation-actions). ## What Oleria discovers * **Users** - `inetOrgPerson` users. A user is disabled when `loginDisabled` is set. A temporary intruder lockout doesn't mark a user disabled. Last activity comes from `loginTime`. Oleria marks a user as an admin when they hold the Supervisor entry right in a container's access control list, directly, through a container above them, or through a group or object in their `groupMembership` or `securityEquals`. * **Groups** - static groups, nested groups, and dynamic groups, with their members and the groups nested in them. * **Containers** - organizations (O), organizational units (OU), localities (L), and countries (C), and the objects they contain. * **Roles** - Identity Manager roles at each level (Business Role, IT Role, and Permission Role), the role hierarchy, the groups assigned to each role, and the users assigned to each role directly or through a container. * **Resources** - Identity Manager resources, shown as applications with the users assigned to them. This includes resources a user gets through a role, and assignments that are still pending, for example waiting for approval. In an access review, a pending assignment shows as access the user has. * **Connected systems** - Identity Manager drivers, shown as applications with the users who have an associated account in each connected system. Oleria shows associations in the Processed and Manual states. It doesn't show Disabled, Pending, or Migrate associations. * **Activity** - CEF audit events that eDirectory, and optionally the Identity Applications, send to the agent over syslog. Activity requires the [CEF auditing setup](#configure-cef-auditing) below. ## Prerequisites * Admin access on the Oleria platform to add a new integration. * A Windows host to install the Oleria NetIQ-Connect Agent on, with local administrator rights. The host must reach your eDirectory server over LDAPS. * LDAPS on your eDirectory server. Port `636` is eDirectory's implied TLS port. The Windows host must trust the certificate eDirectory presents, and the certificate must match the host name in the LDAPS URL you give the agent. If the certificate comes from your tree's Organizational CA, import that CA certificate into **Local Computer** -> **Trusted Root Certification Authorities** on the Windows host. The agent has no setting for a separate LDAPS CA file. * An eDirectory administrator account, to create the service account and grant it rights in OpenText Identity Console. * For the resource actions (optional): the Identity Applications, the password of the `rbpmrest` OSP client, and an Identity Applications user who is a Security Administrator or has a Domain Administrator role, to create an administrator assignment. * For activity (optional): CEF auditing in eDirectory. ## Agent host requirements The Oleria NetIQ-Connect Agent and its Fluentd log collector run on the Windows host you choose. Make sure that host meets these requirements: | Requirement | Details | | :- | :- | | Operating system | Windows. | | Installation rights | Local administrator, to run the installation command from an elevated PowerShell session. The agent then runs as the `OleriaNetIQConnectAgent` Windows service. | | Connection to eDirectory | Your eDirectory server over LDAPS, on the port in the agent's LDAPS URL (`636` by default). Oleria refuses a plain `ldap://` URL, because the service account's password would be sent unencrypted. | | Activity (optional) | Inbound syslog from each eDirectory server that sends CEF events, and from the Identity Applications if they send CEF events too. Contact us at [support@oleria.com](mailto:support@oleria.com) for the port and protocol the agent listens on. | | CPU architecture | 64-bit (x64). The bundled Fluentd package is x64 only. | | Outbound HTTPS (port 443) | Your Oleria API endpoint (`api..oleria.io`), Oleria authentication (`auth.prod.oleria.io`), and Amazon S3 regional endpoints (`*.s3..amazonaws.com`, for example `*.s3.us-west-2.amazonaws.com`), which the agent uses to download the installer and upgrades and to upload data. Contact us for the regions your tenant uses. Oleria never connects in to the agent from the internet. | | Connection to the Identity Applications (optional) | For the resource actions, HTTPS to the Identity Applications URL you give the agent (port `8543` by default). | > [!NOTE] > > If you need to route the agent's outbound traffic through a proxy, contact us at [support@oleria.com](mailto:support@oleria.com) before you install. ## Create a service account in eDirectory Create a dedicated service account for Oleria in eDirectory, then grant it rights on the containers Oleria reads. Use a service account, not an employee account, so the integration keeps working if someone leaves. > [!WARNING] > > Grant Read on the specific attributes below, not on `[All Attributes Rights]`. In eDirectory, Read on `[All Attributes Rights]` of a user also grants Read on the user's Password Management attribute, which exposes password-related information. **1. Create the service account** Sign in to OpenText Identity Console as an administrator. Click **User Management**, then create a user. In the **Create User** page, enter at least the **Username**, **Context**, **Last name**, and **Password**, then save the user. Note the service account's distinguished name (DN) and password. The agent needs them. **2. Grant read rights** For each container in the table below: 1. On the Identity Console home page, click the **Rights Management** tile, then click **Modify Trustees**. 2. Select the container and click **OK**. 3. Click **Add Trustee**, select the service account, and click **OK**. 4. Click **Assigned Rights** for the service account, then click **Add Property**. Select **Show All Properties in Schema**, because by default only the container's own properties are listed. Select the attributes, and click **OK**. 5. Assign the rights for each attribute, and select **Inheritable** on each rights assignment. Grant the Browse entry right on the `[Entry Rights]` item, which represents the object as a whole. 6. Click **Done**, then click **Apply**. | Container | Rights | | :- | :- | | The containers that hold your users | Browse entry right, and Read on `GUID`, `cn`, `uid`, `mail`, `givenName`, `sn`, `fullName`, `title`, `manager`, `employeeType`, `departmentNumber`, `ou`, `objectClass`, `loginDisabled`, `lockedByIntruder`, `loginIntruderAttempts`, `loginExpirationTime`, `loginTime`, `lastLoginTime`, `passwordExpirationTime`, `sasOTPEnabled`, `createTimeStamp`, `modifyTimeStamp`, `creatorsName`, `modifiersName`, `groupMembership`, `securityEquals`, `nrfAssignedRoles`, `nrfContainerRoles`, `nrfAssignedResources`, `nrfResource`, and `DirXML-Associations` | | The containers that hold your groups | Browse entry right, and Read on `GUID`, `cn`, `description`, `owner`, `member`, `groupMember`, `memberQueryURL`, `excludedMember`, `objectClass`, `createTimeStamp`, and `modifyTimeStamp` | | The containers under the agent's base DN | Browse entry right, and Read on `GUID`, `o`, `ou`, `l`, `c`, `description`, `objectClass`, `createTimeStamp`, `modifyTimeStamp`, and `ACL`. Oleria uses `ACL` to find admins. | | The role configuration container, `cn=RoleConfig,cn=AppConfig` under your User Application driver | Browse entry right, and Read on these role attributes: `GUID`, `cn`, `objectClass`, `nrfLocalizedNames`, `nrfLocalizedDescrs`, `nrfRoleLevel`, `nrfParentRoles`, `nrfChildRoles`, `nrfImplicitGroups`, `nrfImplicitContainers`, `nrfStatus`, `nrfActive`, `nrfRoleCategoryKey`, `owner`, `createTimeStamp`, and `modifyTimeStamp`. Also Read on these resource attributes: `GUID`, `cn`, `objectClass`, `nrfLocalizedName`, `nrfLocalizedNames`, `nrfLocalizedDescrs`, `nrfEntitlementRef`, `nrfCategoryKey`, `owner`, `createTimeStamp`, and `modifyTimeStamp`. | | Your driver set | Browse entry right, and Read on `GUID`, `cn`, `objectClass`, `description`, and `createTimeStamp` of the drivers | Read includes the Compare right. The table uses LDAP attribute names, and **Add Property** lists eDirectory attribute names, which can differ. For example, the LDAP attribute `groupMembership` is the eDirectory attribute Group Membership, `uid` is uniqueID, and `sn` is Surname. To find an attribute's eDirectory name, in iManager click **LDAP** -> **LDAP Options** -> **View LDAP Groups**, click your LDAP Group object, then click **Attribute Map**. **3. Grant rights for remediation actions (optional)** To use [remediation actions](#remediation-actions), also grant the service account these rights, the same way: * Write on `loginDisabled` of user objects, for **Disable user accounts** and **Enable user accounts**. * Write on `member` of group objects, Write on `groupMembership` of user objects, and the Supervisor entry right on the groups you want Oleria to change, for **Add user to group** and **Remove user from group**. The Supervisor entry right includes all rights to the group and all of its properties. If your eDirectory server doesn't update `securityEquals` and `equivalentToMe` itself when group membership changes, the agent writes them too. On such a server, also grant Write on `securityEquals` of user objects and `equivalentToMe` of group objects. In iManager, the same steps start from **Rights** -> **Modify Trustees**, and you finish with **Done**, then **OK**. ## Configure CEF auditing To see activity in Oleria, send eDirectory's CEF audit events to the agent host over syslog. This section is optional. **1. Point the CEF events at the agent host** Edit `auditlogconfig.properties` on each server. On Linux it's in `/etc/opt/novell/eDirectory/conf/`. On Windows it's in `/novell/nds/`. Set: * `log4j.rootLogger=info, S` * `log4j.appender.S=org.apache.log4j.net.SyslogAppender` * `log4j.appender.S.Host` - the host name or IP address of the agent host * `log4j.appender.S.Port` - the port the agent listens on (see [Agent host requirements](#agent-host-requirements)) * `log4j.appender.S.Protocol` - the protocol the agent listens on (see [Agent host requirements](#agent-host-requirements)). eDirectory supports `UDP`, `TCP`, and `SSL`. `SSL` also needs `log4j.appender.S.SSLCertFile`, the path of a certificate file. On Windows, use double backslashes in the path. Restart eDirectory after you change the file. **2. Select the events** Sign in to OpenText Identity Console as an administrator and click **Auditing**. Select the NCP server you're configuring and click **OK**. On the **CEF Audit** page: * Under **Global**, select **Do Not Send Replicated Events**, so you don't receive duplicate events from replication between servers. * Under **Basic Events Configuration**, select the **Security Events**, **Object Events**, **Attribute Events**, and **LDAP Events** you want to see in Oleria, such as authentication, password changes, intruder detection, and member changes. Changes to the event configuration take up to 3 minutes to take effect on the NCP server. **3. Load the CEF module** After you configure the events, load the `cefauditds` module on each eDirectory server whose events you want: * **Linux** - add `cefauditds` to `/etc/opt/novell/eDirectory/conf/ndsmodules.conf` so it loads when eDirectory starts. To load it now, run `ndstrace -c "load cefauditds"`. * **Windows** - run `ndscons.exe`, select `cefauditds`, click **Startup**, and select **Automatic** for **Startup Type**. To load it now, select `cefauditds` and click **Start**. To also see Identity Applications events, sign in to OpenText Identity Manager Dashboard as an administrator, select **Configuration** -> **Logging**, and select **Enable CEF format** from the **Auditing Configuration** drop-down menu. Set **Destination host** to the agent host, and set **Destination port** and **Network protocol** to the port and protocol the agent listens on. If the agent listens over TLS, select **TCP**, enable **Use TLS**, and provide the **Keystore file name** and **Keystore password**. Click **Apply**, then restart Tomcat. ## Set up Identity Applications access The **Assign user to application entitlement** and **Remove user from application entitlement** actions assign and revoke Identity Manager resources through the Identity Applications REST API. To use them, set up an Identity Applications account for Oleria. This section is optional. **1. Give an account resource rights** In the User Application, open **Administration** -> **Administrator Assignments** and create a new administrator assignment. Select **Resource** as the **Domain Type**, set **Assignment Type** to users, and select the account Oleria will use. Then do one of the following: * Enable **All Permissions** to make the account a Resource Administrator. * Leave **All Permissions** disabled to make the account a delegated administrator (Resource Manager), and give it the **Assign Resource** and **Revoke Resource** permissions. If you limit the assignment with **Resource Sub Container** or **Select Resources**, include every resource you want Oleria to assign or revoke. Click **Create**. **2. Collect the connection values** Note these values for the agent: * The Identity Applications URL, `https://:`. The HTTPS port is `8543` by default. * The OSP client ID, `rbpmrest` unless you use another client, and the client's password, which your administrator set when installing the Identity Applications. * The username and password of the account from the previous step. * If the Identity Applications use a certificate from a private certificate authority that the Windows host doesn't already trust, the absolute path of a PEM file with the CA certificate on the agent host. The agent always verifies the Identity Applications certificate. ## Connect NetIQ Identity Manager to Oleria **1. Open the integration** In your Oleria workspace, go to **Integrations**, find **NetIQ Identity Manager** on the **Available** tab, and select **Connect**. **2. Name your agent** In **Agent name**, enter a name for your agent and select **Continue**. The name can contain only letters (a-z, A-Z), numbers (0-9), hyphens (`-`), and underscores (`_`). **3. Copy the installation command** Oleria shows an installation command. Copy it, then select **Close**. You'll run the command on the Windows host where you install the Oleria NetIQ-Connect Agent. ## Install the Oleria NetIQ-Connect Agent The agent connects to eDirectory with these settings. Have them ready before you install it: | Setting | Notes | | :- | :- | | LDAPS URL | Required. The URL of your eDirectory server, starting with `ldaps://`, for example `ldaps://edir.example.com:636`. Use the host name on the server's certificate. | | Base DN | Required. The container Oleria reads users, groups, and containers under. | | Service account DN and password | Required. The service account you created. | | Role search base | Optional. The container Oleria searches for roles and resources. It must hold both your role and your resource definitions, because the resource actions also look up resources under it. If it's empty, Oleria searches the whole tree. | | Identity Applications settings | Optional. The URL, OSP client ID and password, account username and password, and CA certificate file from [Set up Identity Applications access](#set-up-identity-applications-access). Without them, the resource actions aren't available. | | Activity | Optional. Whether to collect activity, and the folder Fluentd is installed in, if you [configured CEF auditing](#configure-cef-auditing). | **1. Run the installation command** Sign in to the Windows host, open PowerShell as an administrator, and run the command you copied. The command downloads the installation package, checks the checksum and signature of each installer, then installs Fluentd and the Oleria NetIQ-Connect Agent. The Fluentd setup wizard opens first. Note the folder you install Fluentd to, for the Activity setting in the table above. During the agent installation, enter the settings in the table above: the LDAPS URL, base DN, and service account details, and optionally the Identity Applications settings. **2. Confirm the installation** When the installation completes, the `OleriaNetIQConnectAgent` service appears in the Windows services list. ## Verify the integration In your Oleria workspace, go to **Integrations** -> **Connected** -> **NetIQ Identity Manager** and select **View details**. The **Agent Health** section shows the health of the Oleria NetIQ-Connect Agent. The **Capabilities and operation readiness** section lists each action with the rights it requires. ## Remediation actions Oleria can take the following actions in NetIQ Identity Manager. The Oleria NetIQ-Connect Agent runs each action from your network. It checks the current state, and a revert undoes only what the action changed. | Action | What it does | Revert | | :- | :- | :- | | Disable user accounts | Sets `loginDisabled` to `TRUE` on the user. | Sets `loginDisabled` back to `FALSE`. | | Enable user accounts | Sets `loginDisabled` to `FALSE` on the user. | Sets `loginDisabled` back to `TRUE`. | | Add user to group | Adds the user to the group's `member` attribute and the group to the user's `groupMembership` attribute. If eDirectory doesn't update `securityEquals` on the user and `equivalentToMe` on the group itself, the agent writes those too. | Removes the values the action added. | | Remove user from group | Removes the user from the group's `member` attribute and the group from the user's `groupMembership` attribute, plus `securityEquals` and `equivalentToMe` if eDirectory didn't remove them. | Adds back the values the action removed. | | Assign user to application entitlement | Submits a request to the Identity Applications to assign the Identity Manager resource to the user. Provisioning follows any approval the resource requires. | Revokes the assignment. If the assignment isn't listed yet, for example because the request is waiting for approval, the revert fails and you need to cancel the request in Identity Manager. | | Remove user from application entitlement | Submits a request to the Identity Applications to revoke the user's direct assignment of the resource. | Assigns the resource again. | When the user is already in the requested state, the action succeeds without a change, and its revert changes nothing. The read rights from [the service account setup](#create-a-service-account-in-edirectory) aren't enough for these actions. Each action needs these rights: | Action | Required rights | | :- | :- | | Disable user accounts, Enable user accounts | Write right on `loginDisabled` of user objects | | Add user to group, Remove user from group | Write right on `member` of group objects, Write right on `groupMembership` of user objects, and the Supervisor entry right on the group objects. If your eDirectory server doesn't maintain `securityEquals` and `equivalentToMe` itself, also Write on `securityEquals` of user objects and `equivalentToMe` of group objects. | | Assign user to application entitlement, Remove user from application entitlement | The Identity Applications Resource Administrator role, or Resource Manager with the **Assign Resource** and **Revoke Resource** permissions, for the Identity Applications account, and the [Identity Applications settings](#set-up-identity-applications-access) on the agent | * Oleria won't disable the service account the agent binds as, remove it from a group, or revoke a resource from it. It also won't disable the Identity Applications account the agent uses, remove it from a group, or revoke a resource from it. * **Add user to group** and **Remove user from group** work only on static and nested groups. Oleria refuses dynamic groups. * **Remove user from group** removes a direct membership. Oleria also shows members of nested groups as members of the parent group (see [Known limitations](#known-limitations)). If the removal changes nothing and the group's `member` attribute still lists the user, the action fails and tells you to remove the user from the nested group. If the user is both a direct member and a member through a nested group, the action removes the direct membership, and the user keeps the group's access through the nested group. * **Assign user to application entitlement** and **Remove user from application entitlement** work only on Identity Manager resources. Oleria refuses a connected system. To grant access to a connected system, assign one of its resources. * **Remove user from application entitlement** revokes only a direct assignment. If the user gets the resource only through a role, the action fails and tells you to revoke the role in Identity Manager. * Without the Identity Applications settings on the agent, the two resource actions aren't available. ## Known limitations * Oleria doesn't classify non-human identities. Every user shows as a standard user, including service accounts. * Membership of a nested group includes the members of the groups nested in it, so Oleria shows effective membership. A nested member appears both as a member of the parent group and through the nested group. * Oleria doesn't assign or revoke Identity Manager roles. It reads role assignments only. * **Disable user accounts**, **Enable user accounts**, **Add user to group**, and **Remove user from group** change eDirectory directly over LDAP, not through Identity Manager requests. Oleria can't tell which group memberships or account states your Identity Manager policies manage. * Last activity is only as current as `loginTime`. When eDirectory's `sasUpdateLoginTimeInterval` is between 1 and 1440 minutes, eDirectory updates `loginTime` only after that interval, not on every login. When `sasUpdateLoginInfo` is `0`, eDirectory doesn't update any login attributes, so last activity doesn't change. * Oleria finds admins from the `ACL` of the containers under the agent's base DN. It doesn't see a Supervisor entry right granted above the base DN, or one a user holds only through a nested group. * Connected-system accounts come from `DirXML-Associations`. A driver that stores its associations only in `DirXML-AssociationsLite` shows no connected-system accounts. ## 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.