See Forgot or Lock Administrator or J2EE_ADMIN Password on SDN

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 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.

Please remove SE16N, or access to SE16N, from your production systems.

UPDATE

UPDATE – This topic was the subject of a blog by Kevin Wilson less than 2 weeks ago, at which time it was discussed extensively.

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16008

As long as DEBUG access is very tightly controlled, your system should be protected from the risk of this transaction….

I’ve known for a while that, in some releases of SAP, transaction SE16N can be used to change SAP tables, regardless of authorisations or security settings. It’s not something I’ve been keen to see widely disseminated, as there are major systemic risks in making changes this way. More dangerously, it provides a way to override authorisations by giving your userid (or your accomplice’s userid) the SAP_ALL role.

Essentially, you run transaction SE16N, then type &SAP_EDIT into the command field and press enter.

In the example below, I’ve changed the User Group to SUPER.

Personally, I’d recommend making the transaction unavailable (perhaps even removing it from TSTC ?) in your production system – Your firefighter userid can be given authorisation to allow the appropriate people to add it back in, if necessary.

The reason for mentioning it at all is that SAP Mental Notes and IT-Toolbox SAP on DB2 for z/OS have stated that changes using this method are permanently logged in the tables listed below:
SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data

This means, in theory, that you can can query these tables to audit the usage of SE16N to change data. Personally, my attitude is that it’s all well and good knowing Joe Bloggs has broken your system, but I would rather not have to deal with the broken system in the first place. However, there’s a bigger issue…..

When I tested this out on an ECC6 IDES system (DB2 on Windows 2003), the SE16N_CD* tables were not updated.

1 – The knowledge of this method of changing data, which is available on production systems to anyone with access to the SE16N transaction is being more widely disseminated.
2 – There appears to be at least one major platform / release that does not support audit of the method of changing data.

An ActiveX vulnerability detected in the SAP GUI may possibly be exploited by an attacker to gain access to critical files and sensitive data. According to an advisory issued by the United States Computer Emergency Readiness Team (US-CERT), the vulnerability can be exploited remotely by an unauthenticated hacker. The flaw is in the ActiveX control, MDrmSap, which could crash Internet Explorer when handling malicious code, US-CERT said. The advisory also states that the vulnerable ActiveX control can be disabled in Internet Explorer by setting the appropriate kill bit, or by disabling ActiveX in the Internet Zone,

The Danish vulnerability clearinghouse Secunia gave the flaw a highly critical rating. To exploit the flaw, an attacker must trick a user into viewing a malicious website or email message, Secunia said.

SAP issued an update correcting the flaw. If you don’t have an OSS ID, you can view a PDF copy of the note – However, the one on the SAP site is guaranteed to be up to date, whereas the one here may not be.

I had added a new developer to the customer’s HR/PY landscape, but they couldn’t see any of the Employee Data in the Development or QA system. According to SU01, the roles and profiles were identical to a developer who could see the data.

After hunting around my disks (because it has happened to me before !!), I found a note about Table T77UA, which has prompted this reminder to both myself and any one else who has to work with HR/PY Developers.

HR Security

HR Security comprises the General Authorisation Profiles as managed by Role Maintenance (transaction PFCG), plus Structural Profiles.  To assign Structural Profiles, you use table T77UA (User Authorizations = Assignment of Profile to User).  The Structural Authorisation’s themselves are specified in the T77PR table (Definition of Authorization Profiles).  You protect structures (or substructures) of the Organisational Chart by making relevant entries in this table.

1. When you use both Structural and General Authorisations , a user’s Overall Profile is determined from the intersection of the two.
2. The structural profile determines which object in the hierarchical structure the user has
   access to;
3. The general profile determines which object data (infotype, subtype) and which type of
   authorization (Read, Write, …) the user has for these objects.
4. The access mode for authorization objects in HR Master Data is determined in the AUTHC field (Authorization Level).

Steps to do Structural Authorisation:

1. Use transaction OOAC (updates table T77S0) to Activate the Structural Authorisation switch
2. Use transaction  OOSP (updates table T77PR) to Create Structural Authorisation profiles. You protect (sub)structures by making relevant entries in this table.
3. Assign regular Role Authorisation via PFCG.
4. Assign Structural Authorisation profile to User Id. Apparently, some releases have a report RHRPROFL0 that you can use to assign the object id. However, I use transaction SM30 to update Table – T77UA (User Authorizations = Assignment of Profile to User).
5. Organizational Plans are created using PPOCE