This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP ASE Job Server Error

Whilst administering a SAP ASE based SAP system, I came across an issue in the ASE Job server error log “JSTASK.log”:

00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  ct_connect() failed.
00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  jsj__RunSQLJob: jsd_MakeConnection() failed for user sapsa to server SID
00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  jsj__RunSQLJob() failed for xid 66430
00:140737317369600:140737340581728:2016/02/24 16:55:00.87 worker  Client message: ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed.

The issue was caused by a change of the sapsa user password whereby the SAP recommended method of using the hostctrl process, wasn’t followed.
The recommended method updates the sapsa user, the secure storage file plus also the external login for the Job Server.
This is mentioned at the very end of SAP note 1706410 (although it is suggested that the process in this note is no longer followed to change the passwords).
To fix the issue, follow finals steps in the SAP note 1706410:

isql -X -Usapsa -S<SID> -w999

use master

Server                 Login                Externlogin
———————- ——————– ————
SYB_JSTASK             sapsa                sapsa

Drop the SYB_JSTASK entry:

exec sp_dropexternlogin SYB_JSTASK, sapsa

Re-create it with the new password:

exec sp_addexternlogin SYB_JSTASK, sapsa, sapsa, ‘<new sapsa password>’

This should fix the issue.

HowTo: Hide SAP tables including USR02

Within an SAP system, the user account passwords are hashed and stored in the SAP schema table USR02.
If the SAP system users have access to transaction SE16, then it’s possible for them to view the USR02 table by default.

This would present the user with the opportunity of seeing the password hash values.

It would be possible to spot a commonly used password hash and provided the user knows the actual password text that generated the hash, could use it to log in as a different SAP user, maybe with higher privileges.

More importantly, if the user manages to modify the table through transaction SM30, they could set their own hashes.

It is better to create a new authorisation group for the USR02 table, then exclude this specific auth group from the user roles via auth object S_TABU_DIS and setting the “Authorization Group” field.

An example would be to create a new authorisation group “ZZND” (zz no display) in transaction SE54.
Then, still in SE54, assign all the tables you do not wish anyone to see, to the new auth group.

Use transaction PFCG to edit your roles and change authorisation S_TABU_DIS, so that the field “Authorization Group” is set to a range “$*” to “ZY*” (it excludes ZZ*):

The next time the users try to access the table, they will receive a no authorization prompt in SE16.

UPDATE 30/05/2014: The post above was based on R/3 4.7.  Later releases may have an SC auth group already defined with the USR* tables, plus others, already defined.  You may still wish to create your own ZZND auth group to ensure continuity across upgrades and for your own standardisation practices if you must customise the list of tables in the auth group.  Thanks Matt.