Daniel Berlin on Security Insight on SAP security, development stuff… and all the rest

28Mar 13

SAP security policies

Hi there.
This time I'd like to present a hot new SAP feature to you: Security policies!
( Available starting from ERP 6.0 EHP6. )

Effect

The system behavior regarding password rules and logon restrictions is controlled by profile parameters, e.g. "login/min_password_lng" for the minimum password length. These parameters are valid system-wide and could not be overridden by any means.
With the new security policies, it is now possible to define different sets of password rules, password change policies and logon restrictions and assign these policies to users.

This provides the flexibility to segregate users and assign an appropriate policy to each of those groups of users!
For instance, you can enforce strict rules on the global level (= profile parameters) and loosen them on user level via a security policy (e.g. increased validity period of unused initial password for users, who use SAP less frequently).

For users with a security policy assignment, the attributes defined therein override replace the profile parameters – for users without a SecPol the parameters stay relevant.

Creation

The administration of security policies can be performed via the new tcode SECPOL, which is secured by two brand-new authorization objects: S_SECPOL is checked during the maintenance of the policies themselves, while S_SECPOL_A is used to define the values that may be assigned to the security policy attributes.
First of all, let's create a new policy:

Security policy creation

… then mark it and switch to the attribute maintenance screen by double-clicking on "Attributes".

Attributes

The following attributes are available:

TypeSecurity policy
attribute
Corresponding
profile parameter
Description
Password rulesCHECK_PASSWORD_BLACKLIST( none )Check the password blacklist
MIN_PASSWORD_DIGITSlogin/min_password_digitsMinimum number of digits
MIN_PASSWORD_LENGTHlogin/min_password_lngMinimum password length
MIN_PASSWORD_LETTERSlogin/min_password_lettersMinimum number of letters
MIN_PASSWORD_LOWERCASElogin/min_password_lowercaseMinimum number of lowercase letters
MIN_PASSWORD_SPECIALSlogin/min_password_specialsMinimum number of special characters
MIN_PASSWORD_UPPERCASElogin/min_password_uppercaseMinimum number of uppercase letters
Password change
policies
MIN_PASSWORD_CHANGE_WAITTIMElogin/password_change_waittimeMinimum wait time for password change
MIN_PASSWORD_DIFFERENCElogin/min_password_diffNo. of different characters when changing
PASSWORD_CHANGE_FOR_SSOlogin/password_change_for_SSOPassword change requirement for SSO logons
PASSWORD_CHANGE_INTERVALlogin/password_expiration_timeInterval for regular password changes
PASSWORD_COMPLIANCE_TO_CURRENT_POLICYlogin/password_compliance_to_current_policyPassword change after rule tightening
PASSWORD_HISTORY_SIZElogin/password_history_sizeSize of the password history
Logon restrictionsDISABLE_PASSWORD_LOGONlogin/disable_password_logon,
login/password_logon_usergroup
Disable password logon
DISABLE_TICKET_LOGON( none )Disable ticket logon
MAX_FAILED_PASSWORD_LOGON_ATTEMPTSlogin/fails_to_user_lockMaximum number of failed attempts
MAX_PASSWORD_IDLE_INITIALlogin/password_max_idle_initialValidity of unused initial passwords
MAX_PASSWORD_IDLE_PRODUCTIVElogin/password_max_idle_productiveValidity of unused productive passwords
PASSWORD_LOCK_EXPIRATIONlogin/failed_user_auto_unlockAutomatic expiration of password lock

The button "Effective…" shows the relation of the policy values to the default ones (=, ≠ or not set), while the "Superfluous Entries" button identifies unnecessary entries (i.e. identical to the default ones).

Security policy attribute maintenance

Assignment

To assign the newly created security policy, just edit a user in SU01, switch to the "Logon Data" tab and enter the SecPol name in the "Security Policy" field:

Security policy assignment via SU01

Mass-assignments via SU10 are of course possible, too!

To be able to assign a SecPol, you'll need the authorization object "S_SECPOL", which behaves similar to S_USER_AGR – i.e. activity 22 (assign) and the policy's name are checked.

If you want to select users by their security policy assignment, you can simply use the User Information System:

SUIM » User » by Logon Date and Password Change

Central user administration

The security policy ↔ user assignment is supported by the CUA and its distribution can be configured via SCUM as usual.

See you next time!

23Feb 13

Cross-client SAP user listing

Hello!
You might be faced with the task to create a really comprehensive user listing for a SAP system with several productive clients – even including 000 and 066.

This is usually a boring task, as you have to log in to every client… gather the list… proceed to the next client… and so on…
Apart from dying of boredom you might run into the problem of not having access to all clients (e.g. 066). 😕

Mediocre solution:

Write a report like this:

REPORT.
TABLES: usr02.
 
SELECT * FROM usr02 CLIENT SPECIFIED ORDER BY mandt.
  WRITE: / usr02-mandt, usr02-bname.
ENDSELECT.

Pro: Easy, simple, fast.
Con: Has to be transported, protected… and using "CLIENT SPECIFIED" is considered bad code by many companies!

Slick solution:

Use the report RSUVM005, which is intended for system measurement: it gives you a list of (almost!) all users on the clients you specify on the selection screen.
Still the list is missing a few users, because SAP quite rightly considers them irrelevant for licensing — they are automatically filtered out by the report (or more specifically: by the function module SLIM_EXCLUDE_USER):

SAP clientExcluded user
000DDIC
001
066EARLYWATCH
( all other clients )ALEREMOTE
SAPCPIC
ITSLOGIN
J2EE_ADMIN
J2EE_GUEST
SAP*
SAPSUPPORT
TMSADM
WF-BATCH
WFTEST

To get the comprehensive user listing, we just need a cross-client selection for those excluded user names in addition.
Fortunately you can simply achieve this via tcode SM21 and (mis-)use the "User" field to check for the existence of the missing users on other clients.

SM21 cross-client user selection

Now you can compile the cross-client user listing from within one client…
😎

9Feb 13

Audit-proof versioning of programs: VERS_AT_IMP

Hi there,
let's have a look at a very handy system parameter, which is nevertheless not checked as frequently as others in audits — the tp parameter VERS_AT_IMP.

In a default installation this parameter is set to »NEVER«, which means that no new version is created when transporting a program to a target system; the code is simply overwritten there.
If the parameter is set to »ALWAYS« (which is the only other valid option), a version history is maintained analogous to the development system.

Btw.: not only reports are affected by this, but actually all workbench objects that support versioning.

Functionality of tp parameter VERS_AT_IMP

Why does that matter?

The legal codes of many (all?) countries prescribe a duty to preserve records, which is also relevant for program code – the German HGB (Handelsgesetzbuch) for instance. Therefore it is a risk to allow old program versions to be deleted (due to a lack of knowledge – or on purpose).

Developers are usually allowed to execute all reports on a development system, which also includes RSVCAD03 and RSVCAD04. These reports allow the deletion of a program's version history (they're NOT assigned to any program authorization group and the program code does NOT contain any AUTHORITY-CHECKs ← read comments below).

Update: Meanwhile SAP has added an authorization check for S_CTS_ADMI with value TABL to both programs. Anyway, this authorization is checked in many places and chances are high that a number of users have (and need) this authorization for other purposes. So this does not change the general recommendation of this article…

So your options are:

  • if you want to keep the version history on the development system: do whatever it takes to secure RSVCAD03 and RSVCAD04 (just removing S_CTS_ADMI from all roles will not work, especially on non-productive systems) and be careful when restoring the system; you might lose versions (think of reinstallations)
  • set VERS_AT_IMP to »ALWAYS« on the productive system and keep your version history there (of course the above reports have to be secured as well)

As you probably guessed, the second option is favorable, because:

  • authorizations on production are much more limited, so protecting the reports RSVCAD03/04 is much easier there
  • the continuity of a productive system can be ensured, while this is not true for a development system

Where to check it?

Start report RSTMSTPP, enter the productive system's SID and go for it.

Where to set it?

Go to STMS → System Overview. Then double-click in your productive system and switch to the "Transport Tool" tab.
If the parameter does not appear there, it is set to the default value »NEVER«!

Update: Effect on installation of support packages

SPAM settings: Object versioning during support package installations
Switching the parameter to ALWAYS has no automatic effect on transaction SPAM. In other words: installing support packages does not lead numerous (useless) versions of SAP standard objects.
The simple reason is that SPAM allows you to choose whether to create versions of the objects in support packages or not (→ disabled per default).
To enable it, setting VERS_AT_IMP to ALWAYS is a prerequisite — check out SPAM → Extras → SettingImport queueCreate object versions during import — but be aware that this might have an impact on performance and database size.

So long!

26Jan 13

What do SAP and a punkrock band have in common?

Hi folks.
Nothing, you say? Nope – that's not exactly right.
I just made a cute find, while playing around a bit… 😆

If you're interested in the lyrics of Blink 182's song "Obvious" (I am not), have a look at the SAP report RDDPUTJZ_REQUEST_COMP_CHECK3 and scroll down to the bottom:

Blink 182 song lyrics: Obvious

Someone at SAP must've been very bored!

Categories: Fun 6 comments
24Dec 12

Find obsolete SAP roles (not assigned for X days)

Hi authorization admins,
from time to time I get in the mood to clean up one or two SAP systems – and lately I was looking for obsolete roles, which weren't assigned to anybody for ages (e.g. used at least 365 days ago).

While looking around in SUIM and change documents, the developer inside me became more and more delighted – because there is no SAP standard solution for this → time for some R&D. 😛

Report

Here we go:

  • Create a new report in SE38 and paste this source code (don't forget to set a program authorization group *cough*).
  • There's no need to edit any of the selection texts, as they're defined inside the report…
  • Activate & execute the program.

Usage

The report allows you to select:

  • the role names (all SAP standard roles excluded per default),
  • the user who created the role (default exclusion: "SAP") and
  • the days since the role's last assignment to any user (default: 180).

Result

The result consists of the following columns:

  • Role: … well… the role name
  • Creation date: the role's creation date
  • Change date: the date of the role's last change
  • Removal date: the date of the last removal from a user
  • Removed by: the user, who performed the removal
  • Role name: the role description
  • 3 status indicator fields:

Role type:

The role type shows, whether it is a single or composite role (using the standard SAP icons).

Status:

This icon equals to the traffic light icons on PFCG's "Authorizations" tab (→ green: generated, yellow: action required, red: not generated).
For composite roles this field stays empty (since they have no profile).

SR used in CR:

For single roles, this icon indicates if the role is assigned to a composite role (glowing bulb) or not (dark bulb).
Of course this makes no sense for composite roles – so the field is empty then.

Final words

Obsolete / superfluous / unused roles on productive systems should be removed before they get moldy!

😀 Happy Xmas 😀

Page 3 of 612345...Last »