Appendix C Using Audit and Debug Logging to Isolate Problems
This appendix expands on the logging and troubleshooting information in the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide by describing how to use audit and debug logging to isolate problems in the system.
This appendix covers the following topics:
Audit Logging and Action IDs
Before enabling debug logging, make sure that setting the audit log level to FINEST does not produce the desired level of information. When a new log level setting is saved in the console, it is immediately propagated to every component, and messages at that log level and above are logged to the central log.
Note –
Changes to the log level are not propagated to subcomponents, that is, the Directory Server Plug-in, the Windows NT Change Detector, and the Windows NT Password Filter DLL, until the next configuration change is saved. To propagate a new log level setting to the subcomponents, make any minor edit to the configuration, undo the edit, and then save the configuration.
Action Types
When an Identity Synchronization for Windows Connector detects a change to a user entry, it uses an action to represent this change as it travels through Identity Synchronization for Windows. Each action includes a type such as CREATE, MODIFY, or DELETE, and enough attributes from the user entry to allow the destination connector to synchronize the change. The type of an action appears in log entries and can be one of the following:
-
MODIFY — Indicates that an existing user entry was modified.
-
LINK — When Identity Synchronization for Windows synchronizes a new Directory Server user to Windows, the Windows Connector sends a Link Action to the Directory Server Connector after the entry is created. This Link Action contains the user's Windows GUID, which is written to the user's Directory Server entry. Link Actions are only sent from a Windows Connector to the Directory Server Connector.
-
UNKNOWN — When a Windows Connector detects a change to a user, the corresponding action is assigned the Unknown type until the connector determines the type of action by comparing it with the object cache.
-
REFRESH — Indicates resynchronization operations resulting from running the idsync resync command. Actions of this type hold the current value of all user attributes and do not correspond to a detected change in a user entry.
-
SENTINEL — Signals that all source actions are sent during the idsync resync operation. During idsync resync operation, the source connector sends one Sentinel action for each Synchronization User List (SUL) that is processed, to signal that all users in that SUL are sent. This is the only action type that does not correspond to a user entry.
Attributes from the user entry are also included when the action is logged. These attributes are divided into two types: data attributes and other attributes. Data attributes correspond to attributes that are always synchronized, for example, userpassword. The other attributes (sometimes referred to as meta attributes) are required, for example, objectguid or pwdlastset.
Connector Layers: Accessor, Controller, and Agent
During processing, an action is passed through three different layers of the connector: accessor, controller, and agent. Each layer has different responsibilities:
-
Accessor — Interfaces directly with a directory source over protocols such as LDAP. There are separate accessor implementations for Directory Server, Active Directory, and Windows NT.
-
Controller — Is a connector component that interfaces with the agent and accessor components. The controller performs key synchronization-related tasks such as determining a user's membership in a SUL, searching for and linking equivalent user entries, and detecting changes to users by comparing current user entries with the previous versions stored in the object cache.
Note that the term adapter refers to the combination of the accessor and controller layers.
-
Agent — Interfaces with Message Queue and translates attributes between their Directory Server names and Windows names. Distributes configuration received over Message Queue to the other connector layers.
For better performance, the connector processes many actions at once, causing log messages for different actions to be interleaved. When the processing of an action is complete, the source of the action (that is, the accessor or Message Queue) is notified by an acknowledgement. After an action is acknowledged, the source of the action is no longer responsible for redelivering the action in the event of a failure. The action path that detected changes from the directory source to Message Queue is known as the inbound path. The action path that applies changes from Message Queue to the directory source is known as the outbound path. These action paths are summarized in the following figure.
Figure C–1 Action Paths
To illustrate how this process applies to log messages, a sample message from the central audit.log follows and shows when user John Test's password was changed.
[01/Nov/2004:07:17:56.082 -0600] FINE 54 CNN101 connectors-us "The controller has received the following inbound action from the accessor: Type: UNKNOWN {Data Attrs: } {Other Attrs: cn: John Test dn: CN=John Test,CN=Users,DC=gt,DC=com objectclass: top, person, organizationalPerson, user objectguid: coFNlF3ePUWC5Vm32GENfg== pwdlastset: 127437958757034806 samaccountname: jtest sn: Test usnchanged: 313464 whenchanged: 20041101151755.0Z}." (Action ID=CNN101-FFEF4A8986-206, SN=1)
This message was logged as the accessor passed a detected change along the inbound path to the controller. The type of action is UNKNOWN because the controller has not yet compared the action with its object cache database. There are no data attributes in the entry because password values cannot be extracted from Active Directory. Instead, the pwdlastset attribute is used to detect if the password has changed. The action also includes a unique ID that can be used to track the action through the system. A monotonically increasing sequence number (the SN value) also appears in the log entry. In rare circumstances when messages logged at different connectors arrive out-of-order at the Central Logger, the sequence number can be used to correctly order the messages. However, sequence numbers might not always increase by one. This action can be tracked through the log by searching for the unique ID ID=CNN101-FFEF4A8986-206.
[01/Nov/2004:07:17:56.448 -0600] FINE 16
CNN100 connectors-us "The agent has received an outbound action from MQ:
Type: MODIFY SUL: GT_USERS {Data Attrs: }
{Other Attrs: cn: John Test dn: CN=John Test,CN=Users,DC=gt,DC=com
objectclass: top, person, organizationalPerson,
user dspswuserlink: coFNlF3ePUWC5Vm32GENfg== pwdlastset: 127437958757034806
samaccountname: jtest sn: Test usnchanged: 313464
whenchanged: 20041101151755.0Z passwordchanged: TRUE}."
(Action ID=CNN101-FFEF4A8986-206, SN=7)
[01/Nov/2004:07:17:56.462 -0600] FINE 16
CNN100 connectors-us
"The controller has received the following outbound action from the agent:
Type: MODIFY SUL: GT_USERS {Data Attrs: }
{Other Attrs: cn: John Test dn: CN=John Test,CN=Users,DC=gt,DC=com
objectclass: top, person, organizationalPerson,
user dspswuserlink: coFNlF3ePUWC5Vm32GENfg== pwdlastset: 127437958757034806
samaccountname: jtest sn: Test usnchanged: 313464
whenchanged: 20041101151755.0Z passwordchanged: TRUE}."
(Action ID=CNN101-FFEF4A8986-206, SN=8)
[01/Nov/2004:07:17:56.549 -0600] FINE 40
CNN100 connectors-us
"Applying outbound action to Accessor"
(Action ID=CNN101-FFEF4A8986-206, SN=9)
[01/Nov/2004:07:17:56.557 -0600] FINE 40
CNN100 connectors-us
"The accessor has received the following outbound action from the controller:
Type: MODIFY SUL: GT_USERS {Data Attrs: } {Other Attrs: cn: John Test
objectclass: top, person, organizationalPerson,
user dspswuserlink: coFNlF3ePUWC5Vm32GENfg== pwdlastset: 127437958757034806
samaccountname: jtest sn: Test usnchanged: 313464
whenchanged: 20041101151755.0Z passwordchanged: TRUE
dn: uid=jtest,ou=People, dc=gt,dc=com}." (Action ID=CNN101-FFEF4A8986-206, SN=10)
[01/Nov/2004:07:17:56.640 -0600] FINE 40
CNN100 connectors-us
"Successfully modified user 'uid=jtest,ou=People, dc=gt,dc=com',
action=Type: MODIFY SUL: GT_USERS {Data Attrs: [REPL dspswvalidate: true]}."
(Action ID=CNN101-FFEF4A8986-206, SN=11)
[01/Nov/2004:07:17:56.657 -0600] INFO 40
CNN100 connectors-us
"Successfully modified user uid=jtest,ou=People, dc=gt,dc=com"
(Action ID=CNN101-FFEF4A8986-206, SN=12)
Most log entries dealing with an action include the Action ID, but some log entries do not. In these cases, the log entry without the Action ID is usually close to log messages that do include the ID. For example, a summary of the LDAP modification for the previous password update appears between two other log messages:
[01/Nov/2004:07:17:56.557 -0600] FINE 40
CNN100 connectors-us
"The accessor has received the following outbound action from the controller:
Type: MODIFY SUL: GT_USERS {Data Attrs: }
{Other Attrs: cn: John Test objectclass: top, person, organizationalPerson,
user dspswuserlink: coFNlF3ePUWC5Vm32GENfg== pwdlastset: 127437958757034806
samaccountname: jtest sn: Test usnchanged: 313464
whenchanged: 20041101151755.0Z passwordchanged:
TRUE dn: uid=jtest,ou=People, dc=gt,dc=com}."
(Action ID=CNN101-FFEF4A8986-206, SN=10)
[01/Nov/2004:07:17:56.567 -0600] FINE 40
CNN100 connectors-us "LDAP Modify Request:
[REPLACE dspswvalidate: true] [REPLACE dspswloop: true] [REPLACE dspswloop: ] "
[01/Nov/2004:07:17:56.640 -0600] FINE 40
CNN100 connectors-us
"Successfully modified user 'uid=jtest,ou=People, dc=gt,dc=com', action=Type:
MODIFY SUL: GT_USERS {Data Attrs: [REPL dspswvalidate: true]}."
(Action ID=CNN101-FFEF4A8986-206, SN=11)
|
Note –
All messages that appear in the error log file also appear in the audit log file, to facilitate correlation of events leading up to the error or warning message.
The central log files are an aggregation of the individual component logs. As long as a connector can access Message Queue, all messages written to the local logs will also be written to the central log.
A special central log file is used for idsync resync operations. The information in this log is only available on the Core machine in the logs/central/resync.log file. During a resynchronization operation, some information is also logged to the audit log, so the Action ID might be required to correlate log entries between the two files.
Directory Server Plug-In
Increasing the global log level alone might not display all the log entries from the Directory Server Plug-in. Editing Directory Server's cn=config entry might also be required. To enable more informational logging, set the following attributes in Directory Server's cn=config entry.
-
This entry can be manipulated over LDAP while Directory Server is running, or by editing the dse.ldif file when Directory Server is not running.
Note –
nsslapd-infolog-area is a bit-mask entry. If it already has a value, bit-wise OR in the 16th least-significant bit into the value.
To enable additional logging, set the attributes in Directory Server's cn=config entry as follows:
-
nsslapd-infolog-area: 65536
-
nsslapd-infolog-level: 1
Debug Logging
Most of the Identity Synchronization for Windows components have debug logging capability. This section describes how to enable debug logging for each component.
Note –
Using debug logging to isolate a problem can be a time-consuming process. Be sure to read ChapterChapter 12, Troubleshooting, in Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide in Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide before using this method.
Debug Logging in Java Components
To enable debug logging in one of the Java components (connector, System Manager, or Central Logger), edit the process's command line in the WatchList.properties file to include the -Dcom.sun.directory.wps.flags.Flags.DBG=true flag, and restart the Identity Synchronization for Windows daemon (on Solaris) or service (on Windows). For example, debug logging for the CNN101 Connector has been enabled in the following example. The existing entry for the CNN101 Connector in the /var/opt/SUNWisw/resources/WatchList.properties file is shown here.
process.name[2]=CNN101 process.command[2]=/usr/java/bin/java -Xmx256m -Xrs -DimqConnectionType=TLS -Djava.library.path=/opt/SUNWisw/lib:/usr/lib/mps/secv1 -Djava.util.logging.config.file=/var/opt/SUNWisw/resources/Log.properties -Dcom.sun.directory.wps.logging.directory=/var/opt/SUNWisw/logs/CNN101 -DPSWHOME=/var/opt/SUNWisw -DWPSCNFG=resources -classpath /opt/SUNWisw/lib/common.jar:/opt/SUNWisw/lib/connector.jar: /opt/SUNWisw/lib/db.jar:/opt/SUNWisw/lib/ldapjdk.jar: /opt/SUNWisw/lib/manager.jar: /opt/SUNWisw/lib/registry.jar: /opt/SUNWisw/lib/watchdog.jar: /var/opt/SUNWisw/resources:/opt/SUNWisw/locale/resources: /usr/share/lib/jms.jar:/usr/share/lib/imq.jar: /usr/share/lib/mps/secv1/jss3.jar: /usr/sfw/share/lib/xerces-200.jar:. com.sun.directory.wps.controller. AgentHarness CNN101 process.delay[2]=120000 process.interval[2]=60000 |
Note –
The idsync printstat command provides information about the Connector ID and the installation location, which can be used to find the correct entry in the WatchList.properties list.
In the following example, the command-line entry for this connector has been edited to include the special debug option. It is safest to include this option as the first option for the Virtual Machine for the Java Platform (JVMTM tool interface).
process.name[2]=CNN101 process.command[2]=/usr/java/bin/java -Dcom.sun.directory.wps.flags.Flags.DBG=true -Xmx256m -Xrs -DimqConnectionType=TLS -Djava.library.path=/opt/SUNWisw/lib:/usr/lib/mps/secv1 -Djava.util.logging.config.file=/var/opt/SUNWisw/resources/Log.properties -Dcom.sun.directory.wps.logging.directory=/var/opt/SUNWisw/logs/CNN101 -DPSWHOME=/var/opt/SUNWisw -DWPSCNFG=resources -classpath /opt/SUNWisw/lib/common.jar:/opt/SUNWisw/lib/connector.jar: /opt/SUNWisw/lib/db.jar:/opt/SUNWisw/lib/ldapjdk.jar: /opt/SUNWisw/lib/manager.jar:/opt/SUNWisw/lib/registry.jar: /opt/SUNWisw/lib/watchdog.jar:/var/opt/SUNWisw/resources: /opt/SUNWisw/locale/resources:/usr/share/lib/jms.jar: /usr/share/lib/imq.jar:/usr/share/lib/mps/secv1/jss3.jar: /usr/sfw/share/lib/xerces-200.jar:. com.sun.directory.wps.controller.AgentHarness CNN101 process.delay[2]=120000 process.interval[2]=60000 |
After enabling this option, stop and start the Identity Synchronization for Windows daemon (on Solaris) or service (on Windows) so that the changes take effect.
To prevent conflicts with Message Queue, wait 30 seconds after stopping the Identity Synchronization for Windows daemon or service before restarting it. When the process starts, it will write three new logs, logs/CNN101/debug.log, logs/CNN101/debugErrors.log, and ogs/CNN101/resyncDebug.log.
-
debug.log— Includes all debug log messages, as well as all log messages from the audit log file.
-
debugErrors.log— Includes all debug, warning, and error messages, as well as all messages from the error log file.
-
resyncDebug.log— Includes all resynchronization log messages that are normally only sent to the central log.
Enabling debug logging has an impact on performance and security. Debug logging can generate trace-level information that consumes more disk space than audit logs, requiring additional processor cycles that can reduce throughput. Although no sensitive information is ever written to the audit log, the debug log might include sensitive information such as passwords.
Unlike audit logging, the amount of information in the debug log is not controlled by the global log level in the console. Instead, debug logging is controlled by the Log.properties file located in the resources/ directory. The primary settings that can be changed in this file are the log levels. The log levels for debug logging behave identically to the settings for the audit logs but give more fine-grained control.
The com.sun.directory.wps.logging.debugLogger.loggerLevel = FINE line in Log.properties sets the default log level to FINE, but individual components change the log level to increase or decrease the default amount of logging. In general, the defaults provided in this file will produce an adequate amount of debug logging without populating the log with unnecessary information.
The following table summarizes the component-level debug log levels. In the Component column, com.sun.directory.wps.logging.DebugLogger.prefix is implied:
Table C–1 Component-Level Debug Log Levels|
Interaction with directory sources for detecting and applying changes, which is useful when problems accessing a directory source need to be diagnosed. |
FINER |
|
|
Communication between the connector and the subcomponents. |
FINE (if not specified, inherits from accessor.level) |
|
|
Processing that occurs within the controller, including determining membership in an SUL and interaction with the object cache. |
FINER |
|
|
Processing that occurs within the agent, including mapping attributes, sending messages over Message Queue, and receiving messages from Message Queue. |
FINER |
|
|
Processing that occurs within the agent on actions that are received from Message Queue. |
<default\> |
|
|
INFO |
||
|
Interaction with Message Queue. |
<default\> |
|
|
INFO (increasing to FINE+ can significantly slow performance during resynchronization operations) |
||
|
<default\> (can only be set in CentralLoggerLog.properties) |
||
|
Processing done by the configuration system that retrieves, manages, validates, and saves configuration in the configuration directory. |
INFO |
|
|
Processing done by common utility components. |
INFO |
|
|
Low-level execution information for each thread in the system. |
INFO (increasing to FINE+ can significantly slow performance) |
|
|
Low-level parsing details for XML configuration objects. |
INFO (increasing to FINE+ can significantly slow performance) |
These log levels can be changed by editing the Log.properties files. The changes will be reflected after a restart.
Note –
All messages that appear in the audit log file also appear in the debug log file to facilitate correlation of events between the logs.
Debug Logging in the Installer
The installer and uninstaller can be configured to write extra debugging information to the installer log file, for example, Identity_Synchronization_for_Windows_install-20041025035143.log, by setting the ISW_DEBUG_INSTALL environment variable to true before starting the installer.
-
On Solaris systems, the installer log files are written to the /var/sadm/install/logs directory.
-
On Windows systems, these log files are written to a temporary directory, which is controlled with the %TEMP% environment variable.
For example:
bash-2.05# export ISW_DEBUG_INSTALL=true bash-2.05# ./runInstaller.sh
Note –
Secure information such as passwords might appear in the installer log file when debug logging is enabled.
Debug Logging in the Console
The console logs some information to the central log, but most information is only logged if the console is started with the -D option to enable debug logging. The -D option accepts a single argument that controls the amount of logging to generate. The argument varies from 1 (least) to 9 (most). By default, the logging information is only written to stderr, but it can also be redirected to a file using the -f option, for example:
bash-2.05# ./startconsole -D 7 -f /tmp/console.log
Windows NT Change Detection
The first time that you start the Windows NT Connector, with no existing object cache present, the corresponding Java process’s memory usage is approximately 26 – 30 Mbytes. However, the Windows NT Connector's memory usage can easily reach 100 Mbytes during normal operations.
The Windows NT Connector periodically polls the Windows NT subcomponents, that is, the Identity Synchronization for Windows NT Change Detector and the Identity Synchronization for Windows Password Filter DLL for changes. After the connector retrieves changes from a subcomponent, the connector processes the change and based on the configuration, it will or will not send the change over Message Queue. After the connector finishes processing the change, it removes the change from the subcomponents.
If the Windows NT Connector is unavailable for a longer period of time, the subcomponents can accumulate a significant number of changes in memory. A typical change record requires less than 100 bytes of memory, so 10 Mbytes of memory can accommodate 100,000 changes. However, this scenario is not likely to occur on a Windows NT system.
Both the Change Detector service and the Password Filter DLL service maintain some internal counters. You can use these counters (with the connector's log file) to determine how far behind the connector is with change processing compared to the subcomponents.
For example, the following is a user creation entry in the connector's log:
[01/Nov/2004:10:29:07.390 -0600]
INFO 18 CNN102 example-wnt
"The agent is sending the following inbound action to MQ:
Type: CREATE SUL: NT {Data Attrs: [ADD userpassword: ****]}
{Other Attrs: sn: test cn: Jane Test user_rid: 1004
dspswuserlink: RID=1004+DOMAIN=EXAMPLE subcomp_src:
PASSWORD_FILTER usnchanged: 5}."
(Action ID=CNN102-FFF4EFF25B-995, SN=0)
|
The important fields in this entry are:
-
subcomp_src: PASSWORD_FILTER — Indicates that the change was read from the Identity Synchronization for Windows Password Filter DLL.
-
usnchanged: 5 — Indicates that the Password Filter DLL assigned change number 5 to this record.
If you open the registry editor and navigate to HKEY_LOCAL_MACHINE\\SOFTWARE\\Sun Microsystems\\Sun Java System Identity Synchronization for Windows\\1.1, you can view the following registry values:
"PfLastAckedChangeNumber"=hex:05,00,00,00,00,00,00,00 "PfLastAckedChangeTime"=hex:54,64,86,41 "PfHighestChangeNumber"=hex:05,00,00,00,00,00,00,00 "PfHighestChangeTime"=hex:52,64,86,41
-
PfLastAckedChangeNumber — Specifies the last change number the connector acknowledged to the Password Filter.
-
PfLastAckedChangeTime — Specifies what time the last update was received, in the following format:
number of seconds since 00:00:00 UTC, January 1, 1970
-
PfHighestChangenumberr — Specifies the highest change number recorded by the Password Filter DLL. If this change number is the same as the PfLastAckedChangeNumber, there are no changes buffered in the Password Filter DLL.
-
PfHighestChangeTimer — Specifies what time the change was processed by the Password Filter DLL.
The following is another example from the Identity Synchronization for Windows Change Detector:
[01/Nov/2004:10:30:31.802 -0600]
INFO 18 CNN102 example-wnt
"The agent is sending the following inbound action to MQ:
Type: MODIFY SUL: NT {Data Attrs: }
{Other Attrs: sn: test cn: Jane Test user_rid: 1004
dspswuserlink: RID=1004+DOMAIN=EXAMPLE subcomp_src:
NT_CHANGE_DETECTOR usnchanged: 19}."
(Action ID=CNN102-FFF4EFF25B-1162, SN=0)
In this example, subcomp_src is set to NT_CHANGE_DETECTOR, and the following counters are displayed in the same registry entry mentioned previously:
"LastProcessedSecLogRecordNumber"=dword:0000001b "LastProcessedSecLogTimeStamp"=dword:418664a7 "HighestChangeNumber"=dword:00000013
In this example, the Change Detector does not show the last acknowledged changenumber, but the value of HighestChangeNumber is the same as the value in the log entry.
To determine (approximately) how many unprocessed changes there are in the Change Detector, check the last log entry in which subcomp_src is set to NT_CHANGE_DETECTOR, and then compare the usnchanged value in the log entry with the HighestChangeNumber in the registry.
The LastProcessedSecLog counter refers to the last-processed entry in the system's security log.
The psloglist.exe file in the PsTools software bundle at http://www.sysinternals.com/ facilitates listing the contents of the security log and printing out the security log numbers. For example:
C:\>psloglist.exe security
Security log on \\\\ EXAMPLE-WNT:
[027] Security
Type: AUDIT SUCCESS
Computer: EXAMPLE-WNT
Time: 11/1/04 10:30:31 AM ID: 642
User: Administrator\\EXAMPLE
User Account Changed:
Target Account Name: test
Target Domain: EXAMPLE
Target Account ID:
S-1-5-21-975783841-454902410-2021868755-1004
Caller User Name: Administrator
Caller Domain: EXAMPLE
Caller Logon ID: (0x0,0x144B)
Privileges:
...
|
In this example, the log record number is 27 (which corresponds to the value in LastProcessedSecLogRecordNumber - 0x1b).
Changing the Location of the Central Logs
The location of the central logs can be changed using the console and the Log Configuration tab. Specify the location in the Write Log File to Directory field.
Changing the Location of the Component Logs
The location of logs for Java components, that is, System Manager, Central Logger, and connectors, is changed by modifying the com.sun.directory.wps.logging.directory property in the WatchList.properties file.
In the following example, the logging directory for the Active Directory Connector is changed from /var/opt/SUNWisw/logs/CNN101 to /export/isw/logs/adConnector:
Original WatchList.properties entry:
process.name[2]=CNN101
process.command[2]=/usr/java/bin/java
-Xmx256m -Xrs -DimqConnectionType=TLS
-Djava.library.path=/opt/SUNWisw/lib:/usr/lib/mps/secv1
-Djava.util.logging.config.file=/var/opt/SUNWisw
/resources/Log.properties
-Dcom.sun.directory.wps.logging.directory=/var/opt/SUNWisw/logs/CNN101
-DPSWHOME=/var/opt/SUNWisw -DWPSCNFG=resources
-classpath /opt/SUNWisw/lib/common.jar:/opt/SUNWisw/lib/connector.jar:
/opt/SUNWisw/lib/db.jar:/opt/SUNWisw/lib/ldapjdk.jar:
/opt/SUNWisw/lib/manager.jar:/opt/SUNWisw/lib/registry.jar:
/opt/SUNWisw/lib/watchdog.jar:/var/opt/SUNWisw/resources:
/opt/SUNWisw/locale/resources:/usr/share/lib/jms.jar:
/usr/share/lib/imq.jar:/usr/share/lib/mps/secv1/jss3.jar:
/usr/sfw/share/lib/xerces-200.jar:.
com.sun.directory.wps.controller.AgentHarness CNN101
process.delay[2]=120000
process.interval[2]=60000
|
Note –
The idsync printstat command provides information about the Connector ID and the installation location that can be used to locate the correct entry in the WatchList.properties file.
To change the logging directory, the command line entry for this connector must be edited as follows:
process.name[2]=CNN101 process.command[2]=/usr/java/bin/java -Xmx256m -Xrs -DimqConnectionType=TLS -Djava.library.path=/opt/SUNWisw/lib:/usr/lib/mps/secv1 -Djava.util.logging.config.file=/var/opt/SUNWisw/resources/Log.properties -Dcom.sun.directory.wps.logging.directory=/export/isw/logs/adConnector -DPSWHOME=/var/opt/SUNWisw -DWPSCNFG=resources -classpath /opt/SUNWisw/lib/common.jar:/opt/SUNWisw/lib/connector.jar: /opt/SUNWisw/lib/db.jar:/opt/SUNWisw/lib/ldapjdk.jar: /opt/SUNWisw/lib/manager.jar:/opt/SUNWisw/lib/registry.jar: /opt/SUNWisw/lib/watchdog.jar:/var/opt/SUNWisw/resources: /opt/SUNWisw/locale/resources:/usr/share/lib/jms.jar: /usr/share/lib/imq.jar:/usr/share/lib/mps/secv1/jss3.jar: /usr/sfw/share/lib/xerces-200.jar:. com.sun.directory.wps.controller.AgentHarness CNN101 process.delay[2]=120000 process.interval[2]=60000 |
After this change is made, the Identity Synchronization for Windows daemon (on Solaris) or service (on Windows) where the connector is running is stopped and restarted for the changes to take effect.
Isolating Problems in Directory Server
For detailed conceptual and configuration information related to logging options in Directory Server, see the following documents:
-
http://docs.sun.com/source/817-5221/logs.html
-
http://docs.sun.com/source/817-5235/errcd.html
-
http://docs.sun.com/source/817-5235/config.html#wp20751
Isolating Problems in Message Queue
For information about understanding and configuring the Message Queue Broker log, see the Message Queue Administration Guide (http://docs.sun.com/db/doc/817-3727).
Isolating Problems in Active Directory
Active Directory logs information to the Directory Service event log on each domain controller. To increase the amount of logging, change the Windows registry entries. There are several diagnostic values under the HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\Diagnostics key. They default to 0 = no logging. other permitted values are as follows:
-
1 = minimum
-
3 = medium
-
5 = maximum
Note –To isolate problems with Identity Synchronization for Windows, the values to set are Directory Access and LDAP Interface Events.
- © 2010, Oracle Corporation and/or its affiliates