In my first blog on the SM50 logon trace scenarios, I demonstrated how to correctly setup the logon trace.
In this blog I will show some common entries that can be found in the logon trace, when password-based logon is used.
A correct password-based logon
If you don’t use any SSO form in your system, then your end users will have own passwords. When they access the system with the correct password, then you can find entries similar to these in the logon trace:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N productive password is still valid (expiration period=0 / days gone=41)
N codvn=H => password is case-sensitive and up to 40 chars long
N chckpass: correct password
N Get_RefUser(ccc,userID) =>
N password logon is generally enabled (default)
N productive password is still valid (expiration period=0 / days gone=0)
N password change not required (expiration period=0 / days gone=716)
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N syssigni: checking for multiple dialog logons
M ThEppGetConnectionCounter: read connectionCounter 0 from epp 0
N dy_UserLocalTimeInit ()
N DyISignR: return code=0 (see note 320991)
…”
The important message: “return code=0”! This means that no error happened while providing the user ID and password to access the system.
What happens if the incorrect password is used? Well, the return code is, obviously, different than 0:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N productive password is still valid (expiration period=0 / days gone=0)
N codvn=H => password is case-sensitive and up to 40 chars long
N chckpass: incorrect password ==> increase lock counter:1
N send_usr02_refresh_req : send info
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N DyISigni: return code=1 (see note 320991)
…”
You can read that an “incorrect password” was used, causing the lock counter to increase (a new feature, per SAP KBA 1894688).
There are more information about the possible return codes in SAP note 320991.
Preventing multiple GUI logons
You decided to follow SAP note 142724 and prevent multiple logons from users when they use SAPGUI.
The profile parameter login/disable_multi_gui_login was set to 1.
In this case, if someone tries to logon a second time (a concurrent session), the “License Information for Multiple Logon” screen appears, with the following options:
“…
User userID is already logged on in client ccc
(Terminal xxx.yyy.zzz.aaa-TerminalName , since dd.mm.yyyy, hh:mm:ss)
Note that multiple logons to the production system using the same user
ID are not part of the SAP licence agreement.
You can:
( ) Continue with this logon and end any other logons in system
When ending any existing logons to system, unsaved data is lost.
(*) Terminate this logon
…”
The logon trace reflects the parameter being set:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N productive password is still valid (expiration period=0 / days gone=0)
N codvn=H => password is case-sensitive and up to 40 chars long
N chckpass: correct password
N Get_RefUser(ccc,userID) =>
N password logon is generally enabled (default)
N productive password is still valid (expiration period=0 / days gone=0)
N password change not required (expiration period=0 / days gone=716)
N usrexist: update logon timestamp (M)
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N syssigni: checking for multiple dialog logons
…”
The system forbids the second access: only one logon is possible, except if you use login/multi_login_users (this parameter should be used for an exception list).
New password checks
What happens when you create a new user in the system and an initial password is provided? What happens in the first logon?
These are the logon trace entries:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N codvn=I => password is case-sensitive and up to 40 chars long
N chckpass: correct password
N Get_RefUser(ccc,userID) =>
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N password change required (initial password)
N usrexist: partially update logon timestamp (M) – see note 441453
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N syssigni: checking for multiple dialog logons
N dy_UserLocalTimeInit ()
N DyISignR: return code=0 (see note 320991)
N ext_pwdrules_new: 2(0) digits, 6(0) letters, 5(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa
N password_distance_ok: determined 8 different chars (required: 1) in old/new password
N No outdated USRPWDHISTORY records found for <ccc,userID >
N syssignc: update logon timestamp (M)
N send_usr02_refresh_req : send info
…”
The 5 last rows show what happened: the new password should abide to the password rules set in the system. There is no specific configuration defined.
It is possible to see that 2 digits and 6 letters were used, and no special character.
As there is no password history, the password set was accepted and the logon data and history data were updated in the database.
And what about when the password was reset by the administrator, so a new password must be informed?
If the user tries to use the same password causes a popup:
“…
Choose a password that is different from your last
5 passwords
…”
In the logon trace:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N codvn=I => password is case-sensitive and up to 40 chars long
N chckpass: correct password
N Get_RefUser(ccc,userID) =>
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N password change required (initial password)
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N syssigni: checking for multiple dialog logons
N dy_UserLocalTimeInit ()
N DyISignR: return code=0 (see note 320991)
N ext_pwdrules_new: 2(0) digits, 6(0) letters, 5(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa
N password_distance_ok: determined 8 different chars (required: 1) in old/new password
…”
Here the action was interrupted by the popup above.
After entering a new valid password:
“…
N ext_pwdrules_new: 1(0) digits, 7(0) letters, 6(0) lower-case, 1(0) upper-case, 0(0) special chars determined (required) in new pa
N password_distance_ok: determined 7 different chars (required: 1) in old/new password
N No outdated USRPWDHISTORY records found for <ccc,userID >
N syssignc: update logon timestamp (M)
N send_usr02_refresh_req : send info
…”
Here the password and the history were updated.
In another example, the password was reset again by the administrator. A third different password should be informed, as login/password_history_size = 5.
Four other parameters were also set:
login/min_password_lng = 12
login/min_password_digits = 2
login/min_password_letters = 4
login/min_password_specials = 2
The resulting logon trace shows:
“…
N DoW MoY dd hh:mm:ss yyyy
N DyISigni: client=ccc, user=userID , lang=E, access=A, auth=P
N DyDoSncChecks: client/user/access/auth :ccc/userID /A/P
N AcceptInsecure : Login without SNC accepted, reason: Profile parameter
N snc/accept_insecure_gui = Y
N usrexist: effective authentification method: <client,username,password>
N chckpass: client=ccc, user=userID , accesstype=A
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N codvn=I => password is case-sensitive and up to 40 chars long
N chckpass: correct password
N Get_RefUser(ccc,userID) =>
N password logon is generally enabled (default)
N initial password is still valid (expiration period=0 / days gone=0)
N password change required (initial password)
N save user time zone = >BRAZIL< for user >ccc> / >userID > into spa
N syssigni: checking for multiple dialog logons
N dy_UserLocalTimeInit ()
N DyISignR: return code=0 (see note 320991)
N ext_pwdrules_new: 1(2) digits, 5(4) letters, 4(0) lower-case, 1(0) upper-case, 2(2) special chars determined (required) in new p
…”
As the minimum length was not observed, then the popup below is displayed:
“…
Password is not long enough (minimum length: 12
characters)
…”
A new (and valid) attempt:
“…
N ext_pwdrules_new: 2(2) digits, 10(4) letters, 7(0) lower-case, 3(0) upper-case, 2(2) special chars determined (required) in new p
N password_distance_ok: determined 14 different chars (required: 1) in old/new password
N No outdated USRPWDHISTORY records found for <ccc,userID >
N syssignc: update logon timestamp (M)
N send_usr02_refresh_req : send info
…”
More information
You can find more information about logon-related profile parameters in the following SAP notes:
2467 – Password rules and preventing incorrect logons
622464 – Change: Password change requirement for user type “SYSTEM”
862989 – New password rules as of SAP NetWeaver 2004s (NW ABAP 7.0)
1023437 – ABAP syst: Downwardly incompatible passwords (since NW2004s)
If you have a particular password-based example that you would like to discuss, then please use the comments and I will be glad to improve this blog.
Stay tuned for my next logon trace blog, involving SSO with logon tickets.
New NetWeaver Information at SAP.com
Very Helpfull
