One of the troubleshooting options available to a WebSEAL administrator is the trace command. Specifically discussed in this blog entry are debug and snoop traces.
Detailed information of what WebSEAL sees from both the browser and the backend servers can be obtained by running trace commands. A debug trace contains header information; a snoop trace includes full information, but often is not necessary and is more difficult to review. I usually run them simultaneously so I will have already obtained the more detailed snoop trace, if it is needed.
Traces can be started in pdadmin with the following sample commands. Note the path location for the .txt file produced:
server task default-webseald-<servername>.company.com trace set pdweb.debug 9 file path=/var/pdweb/www-default/traces/pdweb.debug_LoginProblem.txt,rollover_size=100000000
server task default-webseald-<servername>.company.com trace set pdweb.snoop 9 file path=/var/pdweb/www-default/traces/pdweb.snoop_LoginProblem.txt,rollover_size=100000000
Turn off tracing with the following sample commands:
server task default-webseald-<servername>.company.com trace set pdweb.snoop 0
server task default-webseald-<servername>.company.com trace set pdweb.debug 0
9 is the highest level of tracing; 0 turns tracing off.As an example, a debug trace may show you that the customer has, in fact, logged in successfully and received the usual 302 redirect with a set-cookie command for the WebSEAL cookie, which cookie the browser includes in the next GET request. If the backend server is down, WebSEAL will immediately send a 500 error to the browser, but a 500 error could also originate with a backend server. You will be able to see this in the trace. Of course, many other possibilities for the 'can't log in' issue may exist, such as a backend server operation that takes longer than the WebSEAL inactivity timeout setting.
As a WebSEAL administrator, the trace command is definitely your friend.
