For most SSO issue, the Logon Trace is needed to find the root cause.
In ABAP system, actually, the logon trace is the development trace of work process. Normally we use the important Note:
#495911 - Trace analysis for logon problems
After get the trace, we can use the Security Audit Log to locate the work process which handled the logon to find the real reason why logon failed.
But sometime, if the security audit log is not active or there is no entry logged in audit log, it becomes difficult to find the work process.
For HTTP Logon issue, I found we can use ICM trace to locate the work process.
Firstly, Raise the ICM trace level to 3.
This can be done in the SMICM, use menu “Goto -> Trace Level -> Set”:
(Also remember go to SM50 to raise trace level to 3 on “Security” component for DIA work processes.)
Then reproduce the issue, and after that change all the trace levels back to default value.
Now let go to check the ICM trace. Use the reproduce timestamp to find related trace:
(Here I recommend the free software Notepad++, it can search large text file very fast. Show the result in list and can locate to position of file by double-clicking.)
Then we can search by such keyword “IcmHandleOOBData”, in the result following lines are what we need:
[Thr 140080821593856] IcmHandleOOBData: Received data on 1st MPI (seqno: 1, type=6, reason=Request processed in wp(6)): 42/23079/0
[Thr 140080821593856] IcmHandleOOBData: request will be processed in wp 6
Here the "wp 6" mean the work process number 6 handled this logon.
Then we can go to check the dev_w6 to find the related trace, we can use timestamp or keyword "note 320991" to search:
In these logon trace, we can find the root cause of why logon failed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
4 | |
3 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 |