Lost All SAP Admin Access? Activate Virtual Super-User SAP* in Minutes
A New Feature That Has Become a Lifesaver for Regaining Access to SAP Clients
Have you lost access for all privilege users in your SAP AS ABAP system? No fallback in place and all the business operations are on hold?
Losing access to all privileged users is more than an inconvenience — it can bring critical system operations to a halt. Whether caused by accidental deletions, expired passwords, or misconfigurations, such scenarios demand a fast and secure recovery process.
If you've faced a scenario like this, you're not alone—many SAP administrators have encountered similar challenges.
What is SAP* User and Why Does it Continue to Matter?
The SAP* user is a built-in super-user in every SAP system client, originally intended for emergency access and initial configuration. By default, it has full administrative privileges, making it a critical backdoor for system recovery.
The SAP* user poses significant security risks if not properly managed. Its default credentials are widely known, making it a common target for unauthorized access. If the user is unintentionally active—especially after system restarts or misconfigurations—it can become an easy entry point for attackers. Additionally, because of its high privileges, any misuse can lead to full system compromise. For this reason, SAP recommends locking or replacing the default SAP* account and using controlled activation methods only when necessary.
Read through SAP Note - 68048 - Deactivating the automatic SAP* user.
But what can you do in a situation where you don’t have access to SAP*, and when none of the usual recovery options are available?
The good news!!
SAP now provides a solution to regain administrative access via the powerful virtual super-user SAP*. There are two options and this blog walks you through both recovery options, emphasizing the recommended approach for modern SAP landscapes.
Method # 1:
If you are on kernel release 790 and above, you can take advantage of a virtual, time-limited, client-specific version of SAP*. It offers a secure, auditable, and restart-free emergency access path.
The SAP* user is client-specific, time-restricted, and protected by a random one-time password. The most important point is that it doesn’t need a system restart. The steps to activate are as follows:
To create a virtual SAP* user, follow the steps mentioned below:
Login as sidadm and navigate to SAP profile directory.
Run the command dpmon pf=<profile name> to open the Dispatcher Monitor.
Note that without profile name, you can't run the dpmon command.
Once in dpmon, choose ‘M’ to open the Menu, then ‘U’ for user functions. Select ‘L’ to view the existing virtual agents list.
Next, press ‘C’ to create a new virtual user and choose the client and press Enter. Type # of minutes (between 10 to 30 minutes) to set the access validity, then confirm with Y.
This creates a virtual SAP* account in the selected client which can be used to address any emergency issues. Go through the following video:
Remarks for this option (as per SAP Note 3303172 - Activating a Super-User SAP*):
Any password based logon attempt for user SAP*, regardless if successful or not, invalidates the one-time password immediately.
You can (re-)activate the user using dpmon any time and will obtain a new one-time password. This is needed for example if you had a typo in your attempt to use the one-time password and could not logon.
Within dpmon you have further the possibility to see in which clients a virtual super-user does currently exist, which one still has a one-time password, their remaining existence and you are able to delete them prematurely.
An existing user SAP* (and an emergency super-user SAP* activated by the second option) is superimposed by an existing virtual super-user SAP* in a client.
A maximum of 20 virtual super-user SAP* can exist in parallel in different clients.
NOTE: The above content is extracted from the SAP note. Further, this is SAP's preferred approach since it follows today's security and business continuity principles.
Method # 2:
If you are below 790 Kernel release, you may choose this option. However, this method is applicable starting from kernel release 700.
Note that you need to delete the user account SAP* in the client you want to logon with a virtual SAP* ID from the database using the below SQL statement:
DELETE FROM USR02 WHERE BNAME = 'SAP*' AND MANDT = '<client>';NOTE: You should set the profile parameter login/no_automatic_user_sapstar=0 in the instance profile for this solution to work.
Incase if the profile is changed, restart the application server to activate the parameter change.
Remarks for this option (as per SAP Note 3303172 - Activating a Super-User SAP*):
It is strongly recommended to deactivate the super-user immediately again when it is no longer needed. For this, revert the parameter change and restart (or stop) the application server again.
Recommendation: create in all clients a user account SAP* and lock it.
Everybody knowing the fact, that this user was activated can make use of it and log on using the well-known hardcoded password.
Because of this, if possible, you should start an additional application server temporarily which has set the profile parameter login/no_automatic_user_sapstar=0
Keep this additional application server out of the load balancing.
Although still functional and practical in an emergency situation, it is less secure, more difficult to manage, and involves operating downtime.
As mentioned, SAP recommends to use the first option as:
There is no need for an application server restart as no static profile parameter needs to be changed.
The user has no hardcoded known password but gets a new random one-time password after each activation. The one-time password is a 25 byte pseudo random base32 encoded value (40 characters).
The user activated is client-specific.
The user existence is limited in time, its validity is chosen during its activation within dpmon (the allowed period is between 10 and 30 minutes), and the user can also be deleted within dpmon already before its expiration.
Bear in mind: A user deletion has no influence on an already established session. A session does continue to run.
Both activation and usage of the virtual super-user are logged in the security audit log event EUP (purpose 2).
Conclusion:
Loss of privileged SAP access is a matter of high risk—but in response, SAP has created a safety net that is secure, under control, and reliable. Where available in your system, use latest-generation activation through dpmon. It is quicker, more secure, and has fewer risks of errors.
Still using an older kernel? Take it as a wake-up call to upgrade your infrastructure—and check your emergency access policies while doing it.