Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAP*: Recording the activites of the built-in account

Former Member
0 Kudos

Greetings Community,

I currently have a question regarding the tracking of activities performed by the user account SAP*.  As you may be aware, there are two SAP* accounts in a typical SAP system:

1.  The "regular" account that exists as a user master record, which can be administered by t-codes such as SU01.

2.  A "built-in" account with the password "PASS" which does not have a user master record and is hard-coded in SAP.

Here is the scenario on one of my systems:

- The SAP* user master record has been deleted.

- The parameter login/no_automatic_user_sapstar = 0 (built-in SAP* is active).

I have two questions around this:

a)  Am I correct in assuming that the built-in SAP* ID (with password "PASS") can now be used for login purposes?

b)  Does anyone know if the tables CDHDR/CDPOS record activities performed by this built-in SAP* ID?

Thanks all and kind regards,

Bartz

1 ACCEPTED SOLUTION

Frank_Buchholz
Product and Topic Expert
Product and Topic Expert
0 Kudos

> a)  Am I correct in assuming that the built-in SAP* ID (with password "PASS") can now be used for login purposes?

Yes

> b)  Does anyone know if the tables CDHDR/CDPOS record activities performed by this built-in SAP* ID?

As soon as you logged on using SAP* / PASS there is almoust no difference to usining a regular user - except that all AUTHORITY-CHECK statements produce 'ok' result.

- If SAP* changes master data, than create change records in CDHDR/CDPOS which are assigned to SAP* are created

- You can see the activities of the user SAP* in the Workload Statistics, transaction ST03N

- If you have activated the Security Audit Log, transaction SM19 / SM 29, than you can see the activities of the user SAP* there, too (*)

(*) Generally we recommend at least following settings of the Security Audit Logs:

1. Log critical events for everybody in all clients and 2. log everthing for special users like SAP* in all clients, too.

Kind regards

Frank

4 REPLIES 4

Frank_Buchholz
Product and Topic Expert
Product and Topic Expert
0 Kudos

> a)  Am I correct in assuming that the built-in SAP* ID (with password "PASS") can now be used for login purposes?

Yes

> b)  Does anyone know if the tables CDHDR/CDPOS record activities performed by this built-in SAP* ID?

As soon as you logged on using SAP* / PASS there is almoust no difference to usining a regular user - except that all AUTHORITY-CHECK statements produce 'ok' result.

- If SAP* changes master data, than create change records in CDHDR/CDPOS which are assigned to SAP* are created

- You can see the activities of the user SAP* in the Workload Statistics, transaction ST03N

- If you have activated the Security Audit Log, transaction SM19 / SM 29, than you can see the activities of the user SAP* there, too (*)

(*) Generally we recommend at least following settings of the Security Audit Logs:

1. Log critical events for everybody in all clients and 2. log everthing for special users like SAP* in all clients, too.

Kind regards

Frank

0 Kudos

This is an excellent answer and addresses what I was asking.  Thank you very much for your response!  It's good to know that, in terms of logging and audit trail, that the built-in SAP* ID is tracked the same way as any other user master record.

0 Kudos

"If you have activated the Security Audit Log, transaction SM19 / SM 29, than you can see the activities of the user SAP* there, too (*)"

Just incase anyone overlooks this, some programs (such as the Sm19 audit log) perform an existence check on the user ID. You must therefore ensure that the user exists and to be in the safe side create a general filter for (*) users in (*) client so that it also catches the SAP* user activities for the cases when the user master record does not exist and is excempted from the results of authority-checks.

You can in higher releases also use RZ10 parameter rsau/user_selection to trap more than the general filter for user SAP** (see the docs) without exploding your log for the other SAP* named users.

To be sure that you both catch and can select on the user, it is best that it always exists in all clients or delete the client (eg. 066) completely.

Cheers,

Julius

0 Kudos

Thanks Julius, that's a good heads-up for configuring the system monitoring!