SAP – SU24 is the blueprint for your security setup

A key element in maintaining SAP roles correctly is knowing how your transactions and authorization objects are linked. In technincal terms SU24. It is an aspect that many underestimate, mainly because it is hard to get a grip on. With this post I want to clarify why it is important to use and which aspects needs to be taken into consideration – in coming posts I will take a deep dive into each of the aspect.

1) Why is an updated SU24 base important?

The only place that transaction codes are linked to authorization objects and suggested values are in SU24. You can use this information for a number of things, but especially during maintenance of roles is an updated SU24 database important, cause how will you otherwise know which objects and values to add into your roles? If you don’t update SU24, you might as well not use PFCG and just create profiles.

The following areas emphasizes why this is an important area

2) Understand and use the authorization object status in connection with PFCG

Status on the authorization objects inside each role has a clear meaning. If you don’t understand the message each status represents you will run into problems with maintenance. Especially you need to have an eye on objects with status changed or manually – but more on this in a coming post :)

3) Build a process for reviewing roles after each SU24 update

Once you have a hold on SU24 and the authorization object status you need to have a process for reviewing all roles containing the transaction that has been updated in SU24. This includes updates you do in the daily maintenance and house cleaning, but also when you update the system. Only by reviewing and updating all affected roles will you have full control over you concept. In another coming post, I will dive into details on how to use the role maintenance options on the authorization folder in PFCG.

4) Information is king

Once SU24 is fully updated, utilize the information any way you can. I often use the information to identify currently used authorization objects, obsolete own developed objects, optimization of test and many other things. In any case the foundation is an updated SU24 data base.

SAP: Password wizard

Out of the box SAP only accepts password based logon as the mechanism for authentication. But the standard password wizard in SAP gives you a generic password containing about 40 characters – inlc. special characters, capital letters and other complication mechanisms.

So to use the standard password wizard is more or less impossible. Or is it…

Table PRGN_CUST gives you the possibility of customizing the rules for the password wizard. So you can now control the rules for a default generated password. Meaning that it is now usable for the administrators and the end users can understand the password.

Following parameters can be used within table PRGN_CUST:

• GEN_PSW_MAX_DIGITS
• GEN_PSW_MAX_LENGTH
• GEN_PSW_MAX_LETTERS
• GEN_PSW_MAX_SPECIALS

…. at the same time remember to review the rules for illegal passwords. They are implemented in table USR40  :)

How many RFC connections do you have and which users authorize the connections?

Management of RFC usually lives its own life – sometimes under stringent control, but more often without any or highly limited control or documentation.

In a new environment it is easy to start in the right way with a controlled solution. But how to start the analysis of which RFC connections actually exists and from a security perspective, which are the users authorizing the connection?

Good news, SAP actually offers a standard report to collect and present all the information. The report can be executed using the standard transaction code RSRFCCHK.

Once you have executed the report on every system, you have a good starting point for aggregating the information across your entire SAP environment. The combined information will allow you to gain a unique inside into not only which connections actually exists, but also which users authorize the connections and thereby the authorizations for each of them.

Happy RCF hunting!

SAP: Mass deletion of roles – using a standard program

Mass changed in role management is never easy and usually no standard solutions for it exists. Before I found the standard approach I always used and LSMW or eCatts – But a standard “out of the box” solution is always better!

SAP note 313587 explains the process

It’s easy – and only takes the below steps to complete.

1. Open the suggested sourcecode in the file Z_DEL_AGR.txt
2. Create a report with the suggested code
3. Create a transport
4. Add the roles you want to delete to a transport
5. Delete the roles using the report
6. Release the transport to the other systems
7. Done! all roles in the transport have now been removed from the systems :)

 

 

SAP: How to manage user licenses

SAP user licenses are often the most expensive in the IT operation budget, hence using the licenses correctly can mean large savings. The problem is that managing the license structure is complex, so the right expertise is needed.
Therefore I always encouraged my clients, to invest in outside help for the initial setup of the license structure. Once the initial setup is completed, maintaining it is a manageable task.

But how is the user licenses counted in SAP?
Of course it depends on the SAP contact, which can be built on several different license models. Typically I either run into unit contract, where any SAP user has the same price. It is simply a matter of counting the number of SAP users. The other typical license model is a solution where the users’ accesses determine the cost. So if a user only recording time in SAP, has a lower license cost than a hard-core finance SAP user.

So how can I optimize our license usage?
It’s quite easy – if a user has a large number of accesses, an expensive license is needed. So to save on the license cost, optimization on the authorization concept is needed. Often I run into clients where 30% or more of the users’ accesses have not been used for a full year. Unfortunately, that does not mean that it’s possible to cut 30% of license costs. But typically a review of assigned accesses result in around 5 to 10% user license saving.

Below is my quick guide you can use to asses you SAP licenses

1. Get your hands on the SAP license contact
2. Read and understand the license model
3. If you have a unit license model, count the number of SAP users, if your SAP population is below the number of licenses, concentrate on other areas than licenses – no savings are possible
4. If you are billed on user types, take 50 random users and evaluate if they have accesses assigned that they are not using
5. If you can save on at least 1 of the 50 users, your business case for the remaining SAP population has already written it self
6. If you don’t have any SAP license experts – get outside assistance to complete the initial setup
7. Update SOP for SAP license management
8. Continuously review and update access (and license) allocation

SAP, whats the meaning?

Seeing it’s Friday I figured it was time for some fun – in the SAP sense. Thanks to a colleague I can now share with you what SAP means.

SAP = Slow and Painful

Then I googled a bit and found this website www.internetslang.com/SAP-meaning-definition.asp. Their interpritation of SAP is “Sad And Pathetic”… 

I encourage you all to share if you have any good interpretations of what SAP really means.

The “official” Wikipedia interpritation is:

en.wikipedia.org/wiki/SAP_AG

In June 1972 they founded Systemanalyse und Programmentwicklung (“System Analysis and Program Development“) as a private partnership under the German Civil Code.^[5] The acronymwas later changed to stand for Systeme, Anwendungen und Produkte in der Datenverarbeitung (“Systems, Applications and Products in Data Processing”).

Have a great weekend :)

SAP: Table Access Management

A small change with big effect fra SAP has come in the area of table security.

SAP standard solution for table security has always been to group tables into authorization groups, which users then where granted access to using object S_TABU_DIS. Thereby granting access to all tables in the authorization group. For many years this has been the only standard solution for management of table authorizations.

A clear disadvantage has always been; what criteria should the table groups be based on? Criticality? Business area? Or something else? Regardless, management of the table groups means spending many resources on management of the table structure.

SAP’s solution is the introduction of security management on table name basis. So instead of grouping tables in authorization groups and then granting access to them, SAP has now made it possible to utilize S_TABU_NAME and directly assigning access to a specific table.

FANTASTIC!

See SAPs description in the below link or OSS note 1481950

http://help.sap.com/saphelp_nw73/helpdata/en/4c/a0ac7a68243b9ee10000000a42189b/frameset.htm

“To also protect tables that are not assigned to an authorization group, you can also use the authorization object S_TABU_NAM. It is integrated into the authorization check of the central function module VIEW_AUTHORITY_CHECK. In this case, the system first checks S_TABU_DIS. If this authorization check is not successful, the system also checks S_TABU_NAM.”