This document details on ways of troubleshooting SIN.
The information is organized under the following headings:
If you cannot start the IAF service, proceed with the following check-list:
Make sure that the following service and daemon are running:
Windows
Software AG Integrated Authentication Framework
UNIX
iafsrv
You can start the iafsrv
daemon from
Software
AG_directory/bin/iafdstart.
Make sure that the ports are available.
Make sure that the configuration name is correct. The attribute file name has to be the same as the directory name including an extension .attr. The broker-id has to be the same as the directory name as well.
If you cannot see IAF integrated within SMH administration web user interface, see Installing System Management Hub over an Integrated Authentication Framework Installation
If you see Integrated Authentication Framework Service but you cannot do anything else, check the user in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Software AG\System Management Hub\Products\Integrated Authentication Framework\Users. The user in the registry key must be the same as the user that you used to log on the system.
There is a patch by HP, that has influence on the stack size and requires larger stack size to be configured. The patch ID is PHCO_33173. The fixes introduced with PHCO_33173 require more local storage on the stack. Multithreaded applications that use the default stack size (of 64K for PA and 256K for IPF) or a smaller custom size, may fail with SIGBUS after PHCO_33173 is installed.
To prevent this, increase the thread stack size manually by at least 64K. For applications that use the default stack size, this can be done by installing PHCO_34718 (or a replacement of that) and setting the corresponding environment variable before launching the application.
You can monitor the actual values of the stack size and iafnuc about the real stack size requirement by using external monitoring tools.
When you install CentraSite on a network file system (NFS) which is mapped to the local one, the local policies do not allow access rights, such as root or setuid to the remote installation. As a result, the sagssxauthd2 executable does not work properly despite the properly configured root and setuid rights.
To resolve the issues with the remote sagssxauthd2 executables
Copy the sagssxauthd2 executable on the local file system.
Set its root and setuid rights.
To use the sagssxauthd2 on the remote installation of CentraSite, you must replace the remote executable files in the corresponding directories with symbolic hyperlinks that point to the locally copied executable.
SIN uses the log4j package for logging data.
Ensure that the log4j logging level for
com.softwareag.security
is set to DEBUG. If this does
not help you to solve the problem yourself, contact Software AG Customer
Support.
To set the log level in log4j using the property style file:
Use the following:
# Set log level for package com.softwareag.security to DEBUG: log4j.logger.com.softwareag.security=DEBUG
To set the log level in log4j using the XML file:
Use the following:
<logger name="com.softwareag.security"> <level value="DEBUG"/> </logger>
You can configure Security Infrastructure login modules to log information into an external file on the file system.
Note:
It is recommended to use these logging settings to resolve only
severe issues or system crashes. These logging settings have impact on the
system performance and if you configure the system to log information
constantly this leads to reduced overall performance.
To switch on logging, you must include the following properties into the properties list of the first login module of the stack in the login context (JAAS configuration):
useLog="true"
logLevel="debug"
logFile="<path_to_the_log_file>
"
Thus, you enable DEBUG severity logging on all modules that are included in the JAAS configuration context. The result file contains the entire debug information generated during the login process, role management and user repository management.
When you specify the path to the log file, make sure that the directory is not write-protected for the user who executes the Java Virtual Machine. On Unix based operating systems it is recommended to use /tmp directory.
It is recommended that you switch off the logging after you collect sufficient information about the issues. If you do not change these logging settings, the system keeps logging information in the file which leads to greater file size and reduced overall performance. Alternatively, instead of configuring external logging on Security Infrastructure, you can also check the system logging.
Setting the log4j configuration can be tricky in an Apache context. Tomcat uses log4j but it is possible you deploy other web applications that also use log4j configuration files. Usually, the log4j of the web application that is loaded first is the one that is used. In such cases, you must configure your system to use a specific log4j configuration.
Following is a sample development scenario that is valid for webMethods products (for example, CentraSite):
To use a specific log4j configuration
Provide the log4j you want to use.
For example, use the following:
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> <appender name="Console" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{ABSOLUTE} [%t] %-5p %c %x - %m%n"/> </layout> </appender> <root> <priority value ="INFO" /> <appender-ref ref="Console" /> </root> <!-- Infos for the security - set level to DEBUG if needed. --> <logger name="com.softwareag.security"> <level value="DEBUG"/> </logger> </log4j:configuration>
Put the file in your Tomcat installation directory under common/classes.
Modify the path names to the log directories according to your installation.
Search in your Tomcat webapps to see if there are log4j.xml configuration files you do not need.
Rename them temporarily.
Restart Tomcat.
Note:
Debug logging takes time and fills your log files. Remember to
switch the logging level back to INFO once you are done.
SIN uses JAAS to determine which LoginModules
to
call. The configuration of the JAAS environment may be done by a configuration
file that is located in the conf directory in the standard
installation.
To verify the JAAS configuration
Check the file to verify that all paths and URL in it are valid.
For UNIX platforms, check if the path to the ssx auth daemon is correct and if the executable it points to has the S-bit set.
CentraSite uses the PluggableUI LoginContext
.
Ensure that it is set up correctly.
If the previous steps did not help you to solve your issues with a web application using SIN for authentication and role management, install the testjaas web application.
To verify the JAAS configuration using the Testjaas web application
Download testjaas.war from the Software AG Community Website > Suite Downloads at http://techcommunity.softwareag.com/ecosystem/communities/public/webmethods/products/suite/downloads/.
Install the testjaas.war in your tomcat webapps.
Point your browser to
http://yourhost:yourport/testjaas/testjaas and save the output in a
file. You can manually verify the working of the different
LoginContexts
by pointing your browser to
http://yourhost:yourport/testjaas/InputForm.html and by providing
the LoginContext
and the logon credentials.
Save the output in a file.
Send the saved files to Software AG Customer Support.
If things are still not working for you, send the following information to Software AG Customer Support:
The jaas_configuration.properties file
The output of the log4j that is set to DEBUG
logging level for com.softwareag.security
The output of the test servlet if this is applicable for your case.