A little bit of History....
If you've administered, or even worked on, any release of R3 or the other ABAP powered SAP systems, you'll be familiar with the user-ids of SAP* and DDIC. The SAP* user, in particular, is very powerful, but early releases of R3 had some flaws in how the SAP* password was stored or calculated. You created a SAP* userid, with it's own password (encrypted and stored, just like all the other passwords) or you used the default settings (including the default password) for SAP*. The problem was that if I didn't know the SAP* password, but could access the database (via telnet as most R3 systems were some UNIX variant back then), all I had to do was delete the SAP* user record (using SQL) and logon using the very well known defaults.
R3 is a business system, owned by the business, and us technical people have no right to go poking around where we are not wanted (OK, a bit tongue-in-cheek, but there's more than a grain of truth in there). To help resolve this issue, somewhere around version 3.0, SAP introduced the profile parameter login/no_automatic_user_sapstar which, when set, meant you had to have an explicitly defined SAP* user record.
Of course, if you really have to login as SAP*, and you know a password from another user for the same client, you can still modify the existing SAP* user record via SQL. Changing passwords via SQL isn't as risky as you'd think, so long as operating system access to the database is restricted. When I have done this, it's been on behalf of the System Administrators, because they or we (ok I) forgot or lost the password, or got locked out, or someone changed the password and went home without telling anyone else.
Back to the 21st Century...
Now, this was all pre ABAP v Java (sorry, that should probably be "ABAP vs Java" or "ABAP and Java"). In the dual-stack systems, the day-to-day Java equivalent of the SAP*user is the J2EE-ADMIN user, which is usually (but not always) defined in the ABAP engine. In a Java only system, it is the Administrator user, which is defined in the UME link from http://server:port/index.html. The Java engine, whether on its own or part of a dual-stack system, also has a SAP* user, but it comes with some extra properties...
1. The system is configured, by default, to not allow access via SAP* at all,
2. When the system is configured to allow SAP* to log in, no other user can login,
3. and, of course, configuration changes require a restart..
Now, if you loose or require the Administrator or J2EE-ADMIN password, you can reset them via the SAP* user; But this requires the following steps;
- Enable the SAP* logon via the Config Tool,
- Restart the Server (to allow the previous step to take effect),
- Reset the affected passwords
- Disable the SAP* logon via the Config Tool, and
- Restart the Server
Sumit Madral has very recently published a good article on how to perform the reconfiguration for SAP* on java systems so I won't go into any more detail. It is enough to say that this requires two server restarts before you can start the work you were tasked with in the first place.
...and the whole point of the blog is ...
I work for an SI which means we have a lot of systems to keep track of the user and passwords for. Many of us use simple algorithms to keep track of our passwords, such PASSWORD = 'a phrase' + SID + incremental-value. However, if you've read this far, you may have guessed that I've been caught out by incorrect or locked passwords a few times, including the Administrator and J2EE-ADMIN users.
When it happened once too often, I decided I needed a preventative measure. Now, on any Java systems I support, I create an Admin_Backup user, with limited authority, to be used solely for resetting / unlocking the Administrator and J2EE-ADMIN users. It is a backup mechanism; I know I'll make mistakes, so I prepare for them.
