立即与支持人员聊天
与支持团队交流

Identity Manager 9.2.1 - Configuration Guide

About this guide One Identity Manager software architecture Customizing the One Identity Manager default configuration Customizing the One Identity Manager base configuration One Identity Manager schema basics
Overview of the One Identity Manager schema Table types and default columns in the One Identity Manager data model Notes on editing table definitions and column definitions Table definitions Column definitions Table relations Dynamic foreign key Supporting file groups
Editing the user interface
Object definitions for the user interface User interface navigation Forms for the user interface Statistics in One Identity Manager Extending the Launchpad Task definitions for the user interface Applications for configuring the user interface Icons and images for configuring the user interface Using predefined database queries
Localization in One Identity Manager Process orchestration in One Identity Manager
Mapping processes in One Identity Manager Setting up Job servers
The One Identity Manager Service functionality Tracking changes with process monitoring Conditional compilation using preprocessor conditions Scripts in One Identity Manager
Visual Basic .NET scripts usage Notes on message output Notes on using date values Tips for using PowerShell scripts Using dollar ($) notation Using base objects Calling functions Pre-scripts for use in processes and process steps Using session services Using #LD notation Script library Support for processing scripts in the Script Editor Creating and editing scripts in the Script Editor Copying scripts in the Script Editor Testing scripts in the Script Editor Testing script compilation in the Script Editor Overriding scripts Permissions for running scripts Editing and testing script code with the System Debugger Extended debugging in the Object Browser
One Identity Manager query language Reports in One Identity Manager Adding custom tables or columns to the One Identity Manager schema Web service integration One Identity Manager as SCIM 2.0 service provider Processing DBQueue tasks One Identity Manager Service configuration files

SCIM plug-in requests

Required permissions

To process filter expressions with relational comparison operators, the user account used requires the ApiServer_SCIM program function. Exceptions are the equals test (eq) and the presence of a value (pr). This applies to both filters in the URL parameter filter and when using the Path filter in patch operations.

If certain users are allowed to handle filter expressions, you can assign the permissions to the users through permissions groups.

  • The QBM_ApiServer_SCIM permissions group is provided for non role-based login. This group owns the program function. Add the system users to the permissions groups. Administrative system users automatically obtain these permissions groups.

  • The QER_4_ApiServer_SCIM permissions group is provided for role-based login. This group owns the program function. The permissions group is linked to the Base roles | API Server SCIM filter application role. Add the identities to the application role.

Base URL requests

The SCIM 2.0 specification provides optional requests for the SCIM service provider base URL. These requests can contain a filter expression if required. This is mainly used to search for objects when their endpoint is not known exactly and so the search must be across endpoints.

The SCIM plug-in supports these requests. In the filter, only logical OR operations and the comparison operators eq, sw, ew as well as co are allowed, which must reference the Resourcetype metadata.

Example:

https://<servername>.<domainname>/ApiServer/scim/v2?filter=(meta.Resourcetype eq “Locality”) or (meta.Resourcetype sw “D”)

The result can contain a list of objects of different types, but the number of returned elements must not exceed 10,000 for load and performance reasons. Otherwise an error message of type tooMany is returned. The search condition should be refined and the result should be more restricted.

Endpoint URL requests

The SCIM 2.0 specification provides for optional filter, attributes, count, and startIndex parameters for requests to the endpoints defined by /ResourceTypes. Requests with the ID of a concrete object (the URL contains the id of the object) can have the excludedAttributes and attributes parameters. The SCIM plug-in supports these parameters.

Endpoint requests return a list of all elements (or all elements matching the filter). This allows the SCIM client to initiate index-based paging by specifying the desired number of records per page ( count and startIndex parameters).

Example: Endpoint request

http://<servername>.<domainname>/ApiServer/scim/v2/Person

Example: Request the first 100 elements of an endpoint with paging

http://<servername>.<domainname>/ApiServer/scim/v2/Person?startindex=1&count=100

Example: Endpoint request with filter

http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"

Example: Endpoint request with filter and output of two additional properties

http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"&attributes=ExitDate,TechnicalEntryDate

Example: Endpoint request for an object

http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8

Example: Endpoint request for specific properties of an object

http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8?attributes=cn,members

Processing DBQueue tasks

The tasks queued in the DBQueue are the result of triggering, modifications to configuration parameters (for example, changes to a configuration parameter concerning inheritance) or running scheduled tasks. The DBQueue Processor processes tasks in the DBQueue. The DBQueue Processor uses several slots for running tasks in parallel. Internal tasks are processed by the Database Agent Service. Ensure that the Database Agent Service is installed and configured.

Detailed information about this topic

DBQueue Processor configuration for test, development, or productive environments

You use the staging level of the One Identity Manager database to specify whether the database is a test database, development database, or a live database. A number of database settings are controlled by the staging level.

If you change the database's staging level, the following settings are configured.

Table 185: Default settings for development, test, and production databases

Setting

Development Test Production

Maximum DBQueue Processor runtime

20 minutes

40 minutes

120 minutes

Maximum number of slots for the DBQueue Processor

5

7

Maximum number of slots according to the hardware configuration

The DBQueue Processor default configuration settings are configured for normal operation and do not normally need to be modified.

If several databases are operating in a managed instance in Azure SQL Database, you can fix the number of slots. In the Designer, adjust the following configuration parameters.

  • QBM | DBServerAgent | CountSlotAgents: Exact number of slots. If the configuration parameter is set, the given number of slots are always set up. There is no internal calculation of the number of slots based on the hardware configuration. Changing the server's configuration has no effect. The value 15 is recommended.

    NOTE: This configuration parameter is not recommended for implementing a database on an SQL Server. For implementing a database on an SQL Server, it is standard practice to use the hardware configuration to determine the slots.

The configuration settings are reduced for testing or development because several databases may be located on a server. If it is necessary to change the settings for testing or development for reasons of performance, you must modify the following configuration parameter settings in the Designer.

  • QBM | DBQueue | CountSlotsMax: Maximum number of slots to be used.

    Use this configuration parameter to reduce the number of slots if required. Values lower than 5 are not permitted.

    Exception: Enter a value of 0 for using the maximum number of slots available based on the hardware configuration.

  • QBM | DBQueue | KeepAlive: Maximum runtime of the central dispatcher. Tasks on slots currently in use are still processed when the timeout expires. Then the slot are stopped and the central dispatcher exits.

    The lowest permitted value for runtime is 5 minutes; the maximum permitted value is 720 minutes.

Related topics

Configuring notification behavior for DBQueue Processor initialization

If errors occur during initialization of the DBQueue Processor, messages are written to the application log. You can use the results display in the Microsoft Management Console, for example, to view the application log.

Use the QBM | DBServerAgent | CreateNotification configuration parameter to configure in which cases error messages are written to the application log. In the Designer, you can modify the configuration parameter as required.

Permitted values are:

  • 0: No logging.

  • 1: Only success messages are logged.

  • 2: Only error messages are logged.

  • 3: All messages are logged.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级