Sun Access Manager

• Collecting Config Files/ install and log files

Please collect the following files located in the base directory for Access Mnager(Note: This is the same directory which is given while going through the installation of the product)

- Collect  /opt/SUNWam/bin/amadmin --version

    Sun Java System Access Manager 7.1 (Thu Jan 18 05:59:21 2007) SunOS}}


- Collect the following information by entering the following url in the browser location

      http://fqdn.of.the.AM.server:port/deployuri/SMSServlet?method=isRealmEnabled

      eg: http://myserver:8080/amserver/SMSServlet?method=isRealmEnabled

      this will return

      * true if server is running in realm mode
      * false if server is running in legacy mode

- From following directory

      /etc/opt/SUNWam/config/

        collect

            AMConfig.properties
            serverconfig.xml

- Zip/tar following directories

            /var/opt/SUNWam/debug
            /var/opt/SUNWam/log
            /var/opt/SUNWam/stats

- Collect
            # pkginfo -l SUNWamsvc
            #  showrev -p | grep SUNWam


- Platform services screen shot (if the more than one AM is deployed and is part of the site (load balancer)   
- Web container access and error logs.

• Deployment Architecure information

It is a good idea to provide a JPEG file which covers the deployement diagram, clearly showing following components.

• All the Acess Manager server instances in the deployment
• Various Agents and their versions used against these access manager servers
• CDSSO (if used)
• Load Balancers/Firewalls (specify SSL termination if applicable)
• Directory servers
• Session Failover enabled or not
• Hostname / ipddresses (of above components)
• Web container name and version

• Hardware platform and operating system with version information

Please make sure you know what Operating System the affected component is running on.

For Windows, you can get version information from the System Properties dialog box. Right click on My Computer, and choose Properties. Note the Version and Service Pack (if any).

For Unix, the flavor (Solaris, HP-UX, AIX) and the major version and minor version numbers, if applicable. The command

uname -a

will usually tell you what you need to know if you don't already know it.

For Linux, please collect the distribution information. If you don't already know this, the most reliable and accurate source of the distribution can be got by executing the command from the command line.

cat /etc/*release

• Problem Description

Please provide as much information as you think is relevant: by all means be concise, but don't do so at the expense of facts.

• Is this impacting a Production/Staging/Development system?
• What has recently changed in your environment? for ex: including but not limited to firewall rules change, DS/LDAP changes etc..
• If you are aware that there has been an external system configuration change recently, a migration, or a change of vendor, please let us know.
• Frequency that the issue occurs
• If you're having a problem that occurs repeatably and predictably, then that's useful information.
• Reproduction steps (if applicable)

Support may need to duplicate your issue in-house, particularly if there is going to be a fix. Quality Engineering will verify that fix does what we expect it to do, and can only do this if they have a procedure for recreating the issue and then verifying that the fix changes the behavior so that the issue no longer occurs.

Please try to keep the procedure as simple as possible. The more complex the steps are, the more likely it is that they will be misunderstood or somehow followed slightly wrong, and we will not be able to duplicate your results without repeating the process and refining it. This can delay resolution significantly.

• Business impact

Again, this helps us to set the priority of the issue. It can also help justify the urgency of a fix.

• Additional information

If available, please provide screenshots, log files, or any other information you think would be helpful to Support to expedite the troubleshooting process.

• Verbose Debug log level collection (AM Server)

- Change the directory to "/etc/opt/SUNWam/config"
- Edit "AMConfig.properties"

    from
         "com.iplanet.services.debug.level=error"
    to
         "com.iplanet.services.debug.level=message"

- Save and restart the web container in which access manager is deployed.         
- The default debug logs directory is "/var/opt/SUNWam/debug"  but is governed by the value of    
  com.iplanet.services.debug.directory config attribute in "AMConfig.properties"

Once the log level is changed, reproduce the issue and collect the time stamp  when the issue was seen 
and the entire debug directory as well as container logs.

• Verbose Debug log level collection (J2EE Agents)

- Change the directory to "PolicyAgent-base/AgentInstance-Dir/config"
- Edit "AMAgent.properties"

     from
          "com.iplanet.services.debug.level=error"
     to
          "com.iplanet.services.debug.level=message"

- Save and restart the web container in which Agent is deployed.         
- The default debug logs directory is /opt/j2ee_agents/appserver_v81_agent/Agent_001/logs/debug but is 
  governed by the value of  com.iplanet.services.debug.directory config attribute in "AMAgent.properties"

Once the log level is changed, reproduce the issue and collect the time stamp  when the issue was seen 
and the entire debug directory as well as container logs.

• Verbose Debug log level collection (Web Agents)

- Change the directory to "PolicyAgent-base/AgentInstance-Dir/config"
- Edit "AMAgent.properties"

     from
          "com.sun.am.log.level="
     to
          "com.sun.am.log.level = all:5"

- Save and restart the web container in which Agent is deployed.         
- The default debug logs directory is /opt/web_agents/apache22_agent/Agent_006/logs/debug/amAgent but 
  is governed by the value of  com.sun.am.policy.agents.config.local.log.file config attribute in 
  "AMAgent.properties"

Once the log level is changed, reproduce the issue and collect the time stamp  when the issue was seen 
and the entire debug directory as well as container logs.

• IIS Logs collection (applicable if you have AM/SSO agent for IIS)

To determine where your IIS log files are stored, please perform the following steps on your server:

1. Go to Start -> Control Panel -> Administrative Tools
2. Run Internet Information Services (IIS).
3. Find your Web site under the tree on the left.
4. Right-click on it and choose Properties.
5. On the Web site tab, you will see an option near the bottom that says "Active Log Format." Click on the Properties button.
6. At the bottom of the General Properties tab, you will see a box that contains the log file directory and the log file name. The full log path is comprised of the log file directory plus the first part of the log file name.

For example, if the dialog box displayed the following values:

• Log file directory: C:\Windows\System32\LogFiles
• Log file name: W3SVC1\exyymmdd.log

Collect and send the above log file.

• Client (Browser) Side Log collection

This log collection is required when the issue is with the setup where agent and/or CDSSO is involved (multiple redirects of users requests)

• Pl install "TamperData" Firefox AddOn and use FireFox browser to reproduce the issue.
• Make sure there is only one instance/tab/window of Firefox is running to avoid the clutter in the snooping.
• Record the Time stamp and start the "usecase" and reproduce the issue.
• Select all the communication segments from the top of the TamperData window and Right click ---> Select Export XML All and save it as "ClientComm.xml" and send it to support along with all the above dataset

Ref Screen Shot:

• Product FAQ

http://developers.sun.com/identity/overview/faq/index.jsp

• Access Manager Forum

http://forums.sun.com/forum.jspa?forumID=760

• Access Manager Email Alias

amfm-technical-ext@sun.com

• J2EE agent Troubleshooting

http://wikis.sun.com/display/OpenSSO/J2EEAgentTrouble

• Trouble Shooting Tips for Policy Agents 2.2 for Sun Application Server 9.x or GlassFish

http://wikis.sun.com/display/OpenSSO/GlassFishAgentTrouble#GlassFishAgentTrouble-installfailnotnoticed

• Web Agent Troubleshooting

http://wikis.sun.com/display/OpenSSO/WebAgentTrouble

• Policy Agent Issues

If you have problems when installing, or configuring an agent, there are a couple of places you can start looking and some ways to get more information to determine the problem:

1. Installation Logs

During installation, all the activity is stored in a special set of log files. Look inside the log files under j2ee_agents/<container-name>/Agent_00x/logs/debug and j2ee_agents/<container-name>/Agent_00x/logs/audit to see all the activity that is logged during installation. Check for any exceptions or unsuccessful installation messages.

2. Agent Run-time Logs

During run-time, the agents log all the debug info in the agent instance debug directory in different files, under the j2ee_agents\<container-name>/Agent_00x/logs/debug directory and you can look in those files for any error messages or exceptions.

3. Increase Debug Logging Level

Customize the debug logging level settings to get more info. You must stop your application-server domain, then edit the j2ee_agents\<container-name>/Agent_00x/config/AMAgent.properties file or the Agent configuration on the console, for the agent instance, and change the property com.iplanet.services.debug.level to message level. This will enable a lot more information to be printed in the logs.

4. Application Server Logs

Besides the agent logs, you could also check the application-server logs. Each application-server domain has a separate logging directory, for instance in Glassfish the glassfish\domains\domain1\logs\server.log contains some useful information. You can look in that file for exceptions and error messages.

• Cookie Encoding/Decoding Issues

http://blogs.sun.com/madan/

• Known Issues

http://docs.sun.com/app/docs/doc/819-4673/ggbai?a=view