Cybersecurity
DevOps Cloud
IT Operations Cloud
The NetIQ User Application is a complex product with many disparate moving parts, and a conglomeration of different technologies. Considering all the moving parts it usually works quite well.
When it does not, how do you troubleshoot it? Well, if you are an Identity Manager pro, your first thought should be, show me the trace! Of course, the engine dstrace output is not there for User Application, but it does have a log that is very useful, if you know the correct log levels to enable.
Details on the logging configuration can be found in the "User Application: Administration Guide"
https://www.netiq.com/documentation/idm402/agpro/data/b6iiw3v.html#b6ij1qt
There also is a logging section, that it is referring to the Event Logging of things that can be sent via OpenXDAS to Sentinel at this page:
https://www.netiq.com/documentation/idm402/agpro/data/b2iix14.html
Log in to the User Application web interface (Often https://server:8443/IDMProv but can differ) as the User App admin account, click on the Administration tab along the top, then the Logging tab along the left side.
DEBUG is usually the best log level for troubleshooting and shows copious details, that make it hard to read.
If you wish the log setting to persist a restart, then click on the Persist settings button at the bottom each time you save the changes.
The logging is inherited, so a parent class enabled, should apply to classes below it as well. So in principle to identify an unknown issue, you could enable DEBUG level tracing at the com.novell and com.sssw levels you should see every message, which would potentially run your disk out of space. But if run for a short time, and turned off while you read the logs looking for the error might help.
The Identity Manager user application implements logging by using log4j (http://logging.apache.org/log4j/2.x/), an open-source logging package distributed by The Apache Software Foundation.
The configuration files can be found in the path "[application server]/server/IDMProv/conf" (e.g., "/opt/novell/idm/rbpm/jboss/server/IDMProv/conf") as
'''jboss-log4j.xml'''
and
'''idmuserapp_logging.xml'''
See http://logging.apache.org/log4j/2.x/manual/configuration.html for interpreting the configuration file syntax.
There are at least three possible web application servers and the settings are slightly different. The location is customizable through the log4j configuration file, and typically is defined there as something like "${jboss.server.log.dir}/server.log"
This is usually in a path like:
/opt/novell/idm/rbpm/jboss/server/IDMProv/log/server.log
The exact path may vary (the rbpm is there if you did an Integrated installer with 4.x but might not be via a more manual or older install) but that should give a good idea of where to find it.
It is important to remember that the User App is a complex product. Some parts can be logged, like actions in workflows (PRD's), and Role/Resource/Entitlement granting and management.
But some parts, execute on the client side, and do not directly happen in the context of the User Application web server and thus cannot be logged the same way. For example, most Form processing happens on the client end. That is, an onload event or onchange event happens in the context of the users browser, not in the User App web server. Thus errors in rendering the form or processing scripts cannot be directly logged. However as always, it is work noting that IDVault queries performed from a form (or the Start Activity Preactivity) can be loggged, at least the User App side of it.
Now we come to crux of the issue. There are at least 48 different classes listed, that could be logged at different levels. What does each log class handle? When should you turn it on? What kind of work would this class troubleshoot for you? Lets see if collectively we can figure out as many as we can.
Here is the list as I copy out of my 4.02 Patch C User Application. (If there are more, feel free to add them.)
I found an interesting Javadoc for the Extend Director product that has some interesting info about some of these classes.
http://www.novell.com/documentation/extend52/Docs/help/Director/javadoc/overview-summary.html
Parent of other Identity Manager user application logs
From JavaDoc: Provides helpers for the Portlet Aggregation (Portal) System for the Director product.
Messages related to portal page processing. This can help debug portal rendering issues. Might see trace such as:
2017-06-29 12:59:47,639 [http-bio-8180-exec-4] DEBUG com.novell.afw.portal.aggregation.EboPortletProxyHelper- [RBPM] Thread [http-bio-8180-exec-4] about to render portlet [SessionTimeoutWarningPortlet] [SessionTimeoutWarningPortlet] 2017-06-29 12:59:47,641 [http-bio-8180-exec-4] DEBUG com.novell.afw.portal.aggregation.EboPortletProxyHelper- [RBPM] done rendering portlet [SessionTimeoutWarningPortlet] [SessionTimeoutWarningPortlet]
Messages related to the persistence of portal data (including portal pages and portlet registrations)
Messages from the portal core portlets and accessory portlets
Messages from the portal import/export and navigation portlets
Messages related to portlet rendering
Messages related to the core portlet API
Messages related to the persistence of portlet data (including portlet preferences and setting values)
Messages related to the registration and configuration of portlets within the portal
Messages related to utility code used by portlets
Messages from the theme subsystem
Messages related to portal utility classes
This is useful when looking for Code Map refresh debugging to see some details of how it queries the various drivers in the driverset for the entitlementConfiguration object, parses it, and translates that into Entitlements that can be used to assign to Resources. This needs the com.novell.idm.nrf.service class as well as a companion.
This is useful when looking for Code Map refresh debugging to see some details of how it queries the various drivers in the driverset for the entitlementConfiguration object, parses it, and translates that into Entitlements that can be used to assign to Resources. This needs the com.novell.idm.nrf.persist class as well as a companion.
This is useful when working with Integration Activities to see part of the process. Needs com.novell.soa.ws.impl as a companion. SOA= Service Oriented Architecture, AF seems to be an old name for Workflows. AF=Approval Flow
Messages from the approval flow (provisioning workflow) subsystem
Workflow log activities use this package with a logging leve of "INFO", e.g.,
10:57:38,866 INFO [STDOUT] INFO [RBPM] [com.novell.soa.af.impl.LogEvent:logAFEvent] [Workflow_Forwarded] Initiated by System, Process ID: f6e65 ...
Scripting engine
EcmaScript Engine
Workflow ECMAscript handler
This is useful when working with Integration Activities to see part of the process. Needs com.novell.soa.af.impl as a companion. SOA= Service Oriented Architecture, AF seems to be an old name for Workflows, AF=Approval Flow.
Messages from the Requests & Approvals web application (actions and tags)
Messages from the core identity portlets and password portlets
Messages from the identity-related utility portlets
Messages from the UI control framework’s ajax servlet and ajax services
Messages from the UI control registry API and approval form rendering
Messages from the directory abstraction layer
Messages from the UI control registry API
When logging forms, recall that most of the form processing happens on the client web browser and thus not a lot can be logged. However, the IDVault query functions are pretty much all AJAX calls and thus there is a component on the User App they talk to, which can be logged.
This parent class is a quick way to get some errors to show up. It would be nice to know exactly which more specific classes are responsible, so as to minimize the amount of logging to read.
From the JavaDoc: These classes come from the SilverStream Director Framework.
Messages related to the framework core subsystem
Messages related to the framework directory subsystem
If you see the below log message in the logs then the LDAP SSL Socket connections are cleaned-up properly.
TRACE [com.sssw.fw.directory.realm.impl.jndildap.LdapSSLSocketFactory] (LDAP Socket Cleanup Task) [RBPM] Completed LDAP SSL Socket Cleanup, no. of sockets remaining..
Also, we can reduce this cleanup thread running interval with the below property configuration in ism-configuration.properties file.
com.novell.idm.ldap.socket.cleanup.interval = 10 (if this property is not configured in ism-configuration.properties file, then the default value is 60 minutes that is set by the application)
Messages related to the framework event subsystem
Messages related to the framework factory subsystem
Messages related to the framework persistence subsystem
From the JavaDoc: Provides an exception that is thrown when an error occurs in a resource set.
Messages related to the framework resource subsystem
Messages related to the framework security subsystem
Messages related to the framework server subsystem
Messages related to the framework servlet subsystem
Messages related to the framework session subsystem
From the JavaDoc: Provides interfaces for working with the User subsystem (user personalization and customization).
Messages related to the framework user subsystem
Messages related to the framework utility subsystem
Messages related to the Portal Manager
Messages related to portal persistence