RadiantOne Directory and Integration
The main log file for troubleshooting the RadiantOne service is vds_server.log.
This chapter describes the RadiantOne Directory and Integration logs.
Windows Service Log
If the RadiantOne service has been installed as a Windows Service, information related to installing, starting, and uninstalling the service can be found in:
<RLI_HOME>/logs/rli_fid_server_service.log
Information about stopping the service can be found in:
<RLI_HOME>/logs/rli_fid_server_service_stop.log
-->
RadiantOne Server Log
Server logging is configured from the Main Control Panel > Settings tab > Logs > Logs Settings section. Select the VDS – Server option from the Log Settings to Configure drop-down menu.
Log Contents
The vds_server.log records:
Host name of the local RadiantOne server. This is only reported when the service starts. An example is:
2017-08-14 10:33:16,839 WARN VDSServer:54 - zkId:1 hostname:vds72l IP:10.11.8.22 cloudId:6646de6a-356a-45b1-b1cf-5ae118c35fc5
-
Open/closed connections by LDAP clients to the RadiantOne service
-
LDAP requests made to the RadiantOne service
-
LDAP responses from the RadiantOne service
-
Some information generated by the RadiantOne engine: errors (backend unavailable, etc…), requests, etc…
-
Commands issued by RadiantOne against the underlying backends.
-
Requests made to ZooKeeper.
-
Activities from the Context Builder tool.
-
SCIMv2 requests and responses. The SCIMv2 incoming queries from clients are prefixed with ScimRequest for the requests and ScimResponse for the replies from RadiantOne. RadiantOne server log level of at least INFO is required to log the SCIMv2 requests.
Log Level
Select a log level from the drop-down list in the Log Settings section. For details on available log levels, see Chapter 1.
To troubleshoot/trace ACI evaluation decisions, RadiantOne server log level must be set to DEBUG. When DEBUG level is set, the evaluation rules can be seen in vds_server.log. An example of ACI evaluation is shown below:
2021-05-07T15:40:44,920 DEBUG com.rli.slapd.aci.generic.AciHandler:436 - [ACI EVAL] operation: 'SEARCH REQUEST' [ACI EVAL] targetDN: 'ou=Accounting,o=companydirectory' [ACI EVAL] subject: 'uid=Aaron_Medler,ou=Accounting,o=companydirectory' [ACI EVAL] Aci candidates {2}: [ACI EVAL] Aci candidate # 1 - '(targetattr = "*")(target = "ldap:///o=companydirectory")(targetscope = "subtree")(version 3.0;acl "myaci description";deny (all) (userdn = "ldap:///uid=Aaron_Medler,ou=Accounting,o=companydirectory");)' [ACI EVAL] Aci candidate # 2 - '(targetattr!="aci")(version 3.0; acl "Grant read access to anyone"; allow (read,search,compare) userdn="ldap:///anyone";)' [ACI EVAL] Aci evaluation result: --DENY-- 2021-05-07T15:40:44,921 DEBUG com.rli.slapd.server.nio.SessionHandler:2354 - [conn=50 op=2] Entry discared by ACI
Rollover Size
By default, the vds_server.log file rolls over once it reaches 100MB in size. Change this value if needed.
Log Archiving
By default, 20 log files are kept (oldest ones are deleted to maintain a maximum of 20). You can change this value in the How Many Files to Keep in Archive setting. The archived files are named vds_server-<yyyy-MM-dd_HH-mm-ss>.log.zip and can be downloaded from Server Control Panel > Log Viewer. <!-- The default instance name is vds_server, so the path would be: <RLI_HOME>/vds_server/logs/.
Log Failure Notification
The RadiantOne service can send an alert email if logging fails for the vds_server.log. Enable the notification process from Main Control Panel > Settings > Log > Log Settings > Log Failure Notification section.
- Check to Enable Notifications.
- Enter the SMTP Server URL.
- Enter the SMTP port.
- Username to connect to the SMTP server.
- Password associated with the username entered in step 4. Used to connect to the SMTP server.
- Enter the subject of the email message in the Message Subject property.
- Enter the body of the email message in the Message Body property.
- Enter the email address to send the alert to, in the Message Recipient property.
- Enter the email address from which the alert should be sent, in the Message Sender property.
- Enter a number of minutes to indicate how long to wait before sending a subsequent alert email, in the Minimum Interval Between Emails.
- Click Save.
RadiantOne Access Log
The vds_server_access.log contains less information than vds_server.log and is used more for auditing. Access logging is configured from the Main Control Panel > Settings tab > Logs > Access Logs section.
Log Output Format
The output formats for the access log are text and CSV by default. The other output option is CSV. <!--If you want the log content written to a database, you must enable the CSV output option and use the Log2DB utility.
Bind DN Information in vds_server_access.log
By default, the Search Results in vds_server_access.log do not contain bind DN information. To enable bind DN information to be logged for search results in the access log:
-
In the Main Control Panel, go to the Zookeeper tab.
-
In the pane on the left, expand
/radiantone/v2/<cluster name>/config/
and select the vds_server.conf node. -
Click Edit Mode.
-
Change the value for enableAccessLoggingWithWhoDidThat to true.
Figure 3. 2: Enabling bind DN info for vds_server_access.log
- Click Save.
The access log now displays bind DN information for Search Results for both successful and unsuccessful binds.
This setting does not affect vds_server_access.csv, which displays bind DN information by default.
The following example entry shows bind DN information for a successful bind.
2020-11-10 16:26:04,896 |localhost~201110154406|<== conn=10 op=57 MsgID=57 SearchResult {resultCode=0, matchedDN=null, errorMessage=null} ### nEntries=1 ### bindDN="cn=Directory Manager" ### etime=0 ###
The following example entry shows bind DN information for an unsuccessful bind attempt.
2022-05-09 15:02:40,446 |localhost ~220509150108|<== conn=5 op=3 MsgID=3 BindResponse {resultCode=49, matchedDN=null, errorMessage=Reason: 52e - Invalid credentials} ### bindDN="cn=Marketing User,dc=hdap" ### etime=8 ###
Log Location
The vds_server_access.log and vds_server_access.csv can be viewed and downloaded from Server Control Panel > Log Viewer.
Rollover Size
The vds_server_access.log rolls over when it reaches 100MB in size. Change this value if needed.
Log Archiving
By default, once the vds_server_access log rolls over, it is kept for 30 days. Change this value in the Rollover: How long to keep the logs property if needed.
Log Contents
This log file acts as an audit log (and is used to generate reports from) and records the following information:
-
Who binds to RadiantOne
-
Open/closed connections by LDAP clients to the RadiantOne service
-
LDAP requests made to RadiantOne
-
LDAP responses from RadiantOne
More information can be found in the Log Details section below.
Log Details
Details regarding the CSV column names and descriptions are shown below.
Table 1: Access Log CSV Column Names and Description
ACCESS LOG COLUMNS | DESCRIPTION |
---|---|
LOGID | This is the unique accesslog id based on |
LOGDATE | This is the date of request. |
LOGTIME | This is the time of request. |
LOGTYPE | 1:request, 2:response, 3:connect, 4:disconnect |
SERVERID | This is |
SERVERPORT | This is the RadiantOne service port the request came in on. |
SESSIONID | This is the server session id. |
MSGID | This is the LDAP operation message ID. |
CLIENTIP | This is the IP address of client. For calls sent to RadiantOne through REST (through the ADAP API) or SCIM, X-Forwarded-For header is supported. In this context, the whole chain of IP addresses (e.g. client, load balancer…etc.) are logged. |
BINDDN | BindDn contains the value representing the user to authenticate, that RadiantOne gets in the BindRequest. |
BINDUSER | If Proxy Authorization is used in the request, BindUser contains the authorization DN. This is the DN associated with the user which RadiantOne bases authorization on. If Proxy Authorization is not used in the request, BindUser is empty. |
CONNNB | This is the connection number. |
OPNB | This is the operation number. |
OPCODE | This is the protocol operation type (see table 2 below). |
OPNAME | This is the protocol operation name (see table 2 below). |
BASEDN | This is the basedn (starting point in the RadiantOne namespace) rec'd in the request. |
ATTRIBUTES | These are the attributes received in the request. |
SCOPE | This is the scope received in the request. |
FILTER | This is the filter received in the request. |
SIZELIMIT | This is the sizelimit received in the request. |
TIMELIMIT | This is the timelimit received in the request. |
LDAPCONTROLS | These are the LDAP controls received in the request. This column also indicates if a secure socket is used. If the request came in on the non SSL/TLS port, this column has |
CHANGES | These are the changes for add/delete/modify requests. |
RESULTCODE | This is the ldap operation result code returned by RadiantOne. |
ERRORMESSAGE | This is the error message returned by RadiantOne. |
MATCHEDDN | This is returned in the result message from RadiantOne in case of errors like (32) noObjectFound or (21) invalidSyntax. This is usually set to the last DN used in finding the requested entry. |
NBENTRIES | This is the number of entries returned in searchrequest. |
ETIME | This is the elapsed time (in ms) to complete the operation. |
Table 2: Operation Name and Code
OPNAME | OPCODE |
---|---|
BindRequest | 0 |
BindResponse | 1 |
UnbindRequest | 2 |
SearchRequest | 3 |
SearchResponse | 4 |
SearchResult | 5 |
ModifyRequest | 6 |
ModifyResponse | 7 |
AddRequest | 8 |
AddResponse | 9 |
DelRequest | 10 |
DelResponse | 11 |
ModifyRDNRequest | 12 |
ModifyRDNResponse | 13 |
CompareRequest | 14 |
CompareResponse | 15 |
AbandonRequest | 16 |
SearchResultReference | 19 |
ExtendedRequest | 23 |
ExtendedResponse | 24 |
Connect | 30 |
Disconnect | 31 |
Ignore Logging for Internal Naming Contexts
Queries to certain internal naming contexts can happen frequently resulting in a lot of “noise” in the access log. To ignore logging for these naming contexts, expand below the Advanced section (requires Expert Mode) and check the box next to the naming context. Logging for the following naming contexts can be ignored.
-
ROOT – this is for queries requesting the rootDSE (an empty base DN) and is often used by hardware load balancers to check the availability of the RadiantOne service.
-
cn=changelog – modifications to entries in the RadiantOne namespace are tracked in the changelog. Other services can query the changelog frequently to check for changes.
-
cn=clustermonitor – various statistics and availability of cluster nodes are retrieved by querying cn=clustermonitor.
cn=replicationjournal – inter-cluster replication queries the cn=replicationjournal.
RadiantOne Persistent Cache with Real-time Refresh
The logs associated with persistent cache with real-time refresh are described in this section. The high-level diagram below depicts the components involved.
Figure 3.3: High-level Persistent Cache with Real-time Refresh Diagram
-
A connector detects changes in the backend.
-
The connector publishes changes into a queue (one queue per backend). The message doesn't require all attributes of the entries, just enough to process the refresh.
-
The Sync Engine picks up changes from the queue. This is event-driven (not polling).
-
The Sync Engine queries the backend(s) and updates the persistent cache view(s) accordingly.
Agent
The agent logs to agent_fid_sd_agent_real_time.log. This log can be viewed and downloaded from Server Control Panel > Log Viewer.
The agent logs level is controlled by the setting in Main Control Panel -> Settings tab -> Logs -> Log Settings. Select the Sync Agents – Agents option.
Figure 3.4: Sync Agents Log Settings
Connectors
The capture connector logs use the following syntax: <naming_context>_<baseDN>_<data_source>\connector.log
. These logs can be viewed and downloaded from Server Control Panel > Log Viewer. They can also be viewed from the Main Control Panel > PCache Monitoring tab.
The log level is defined per connector with the setting in Main Control Panel -> PCache Monitoring tab. Select the connector on the topology and the configuration window displays. In the Configuration section, select the level from the Log Level drop-down list.
Figure 3.5: Connector Log Level
Sync Engine
The sync engine log sync_engine.log on the RadiantOne node where the sync engine processor that is assigned for the pipeline is running. If RadiantOne is deployed in a cluster, a sync engine processor can be running on one or more nodes and the pipeline processing is distributed across them. The sync_engine.log can be viewed and downloaded from the Server Control Panel > Log Viewer.
HDAP Trigger
When virtual views are created on RadiantOne Directory (HDAP) stores or persistent cache, and those views are configured for persistent cache, the change capture connector type defaults to HDAP Trigger. This is an internal mechanism that automatically refreshes persistent caches that are built on top of other persistent caches or RadiantOne Directory (HDAP) stores. When the RadiantOne VDS Sync Engine is configured for DEBUG log level, the HDAP trigger activity is logged into the sync_engine.log
You can set the log level from Main Control Panel > Settings > Logs > Log Settings as shown below.
Figure 3.6: VDS Sync Engine Log Level
-->
RadiantOne Persistent Cache with Periodic Refresh
Snapshot Files
Periodic persistent cache refresh leverages a snapshot mechanism to detect changes in the backend data source(s). The “snapshot” is an LDIF formatted file that contains the entries from the backend. During a refresh cycle, a new LDIF file is generated from the backend and compared to the last snapshot to detect changes.
Log
The log associated with persistent cache with periodic refresh is configured from the Main Control Panel > Settings tab > Logs > Logs Settings section. Select the VDS – Persistent Cache Periodic Refresh option from the Log Settings to Configure drop-down menu.
Log Contents
The periodiccache.log records persistent cache, periodic refresh activity. Below is an example of the activity you can find in this log. The example below is based on a naming context named dc=pxy that has been configured as persistent cache with periodic refresh.
[2016-03-18 14:56:01,571] [Storage Periodic Refresh - dc=pxy] scheduling refresh - cron expression=0 0/2 * * * ?
[2016-03-18 14:58:00,769] [Storage Periodic Refresh - dc=pxy] Entries exported: 10015 in 1 sec
[2016-03-18 14:58:00,770] [Storage Periodic Refresh - dc=pxy] Sorting C:\radiantone\vds\vds_server\ldif\import\dc=pxy_temp.ldif...
[2016-03-18 14:58:01,123] [Storage Periodic Refresh - dc=pxy] Delta refresh starting...
[2016-03-18 14:58:01,588] [Storage Periodic Refresh - dc=pxy] Compared: 10000 entries [inserted=2, updated=0, deleted=0]...
[2016-03-18 14:58:01,590] [Storage Periodic Refresh - dc=pxy] Finished: total compared 10015 entries [inserted=4, updated=10, deleted=0]
Log Location
Periodiccache.log can be viewed and downloaded from Server Control Panel > Log Viewer.
Log Level
Only log level INFO is applicable. Therefore, this cannot be changed.
Rollover Size
By default, the periodiccache.log file rolls over once it reaches 10MB in size. Change this value if needed.
Log Archiving
By default, 10 files are kept in the archive. Change this value in the How Many Files to Keep in Archive setting. The archived files are named periodiccache-<N>.log
and can be viewed and downloaded form Server Control Panel > Log Viewer.
ADAP Access Log
ADAP is the RESTFul Web Service included in RadiantOne. It allows REST-access to RadiantOne. ADAP access logging is configured from the Main Control Panel -> Settings tab -> Logs -> Log Settings section. Select the VDS – ADAP Access option from the Log Settings to Configure drop-down menu.
Log Contents
The ADAP access log records the following.
-
Simple binds
-
Authorization (basic or token)
-
Searches
-
Operations including Post, Put, RDN Patch, and deletes
-
Detailed error messages
Log Location
The adap_access.log file can be viewed and downloaded from Server Control Panel > Log Viewer
Log Level
Select a log level from the drop-down list in the Log Settings section. For details on available log levels, see Chapter 1. The default log level for this log is OFF.
To log Certificate Revocation error messages when accessing ADAP using mutual authentication, set the log level to DEBUG from the Main Control Panel > Zookeeper tab by navigating to radiantone/v2/<cluster_name>/config/logging/log4j2-vds.json
and updating the “Loggers” section with the information shown below.
"loggers" : {
"logger" : [
{
"name" : "org.eclipse.jetty",
"level" : "DEBUG"
}, {
"name" : "com.rli.zookeeper",
"level" : "INFO"
}, {
Rollover Size
By default, the adap_access.log file rolls over once it reaches 100MB in size. Change this value if needed.
Log Archiving
By default, 10 files are kept in the archive. Change this value in the How Many Files to Keep in Archive setting. The archived files are named adap_access-<N>.log
and can be viewed and downloaded from Server Control Panel > Log Viewer.
SCIM Log
The RadiantOne service supports SCIMv2. SCIM logging is configured from the Main Control Panel > Settings tab > Logs > Logs Settings section. Select the VDS – SCIM option from the Log Settings to Configure drop-down menu.
Log Contents
The SCIM log records the following.
-
Operations including post, put, patch, and deletes
-
Internal processing related to servicing requests from SCIM clients
Log Location
The SCIM log file is scim.log. It can be viewed and downloaded from the Server Control Panel > Log Viewer.
Log Level
Select a log level from the drop-down list in the Log Settings section. The default log level for this log is INFO. For details on available log levels, see Chapter 1.
Rollover Size
By default, the scim.log file rolls over once it reaches 100MB in size. Change this value if needed.
Log Archiving
By default, 20 files are kept in the archive. Change this value in the How Many Files to Keep in Archive setting. The archived files are named scim-<yyyy-MM-dd_HH-mm-ss>.log.zip
and and can be downloaded from Server Control Panel > Log Viewer.