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