Change management
Reset passwords using self service
In the SAP system, passwords are locked when the maximum number of allowed password login errors is reached. This counter is reset with a password each time you successfully log in. In addition, an initial password can be locked when its validity has expired. Both the validity of the initial password and the maximum value for password login errors are set using profile parameters. For details, see Tip 4, "Set password parameters and valid passwords characters". A password lock only prevents a user from logging in via his password, because the number of errors is only evaluated if the login is done by password. If a login is now made via other authentication methods (such as SSO), these are not affected by the password lock. This also applies to internal expiration procedures (such as background jobs) because you do not need to register a password. This prevents, for example, denial-of-service attacks, which first cause a password to be locked in order to block internal processes. Eine Ausnahme von dieser Regel gibt es allerdings: Auch wenn andere Authentifizierungsverfahren genutzt werden, prüft das System, ob der Benutzer dazu in der Lage ist, sich mit einem Passwort anzumelden. Wenn dies der Fall ist und das Passwort gerade geändert werden muss, wird diese Änderung vom Benutzer abgefragt. Diese Abfrage können Sie aber auch mithilfe des Profilparameters login/password_change_for_SSO ausschalten.
The system checks direct access to the contents of tables, for example, with transactions SE16, SM30, or SE16N with authorization checks on a table authorization group, object S_TABU_DIS. If there are no suitable authorizations for the table authorization group, the system checks the name of the table or view, object S_TABU_NAM. When making changes to client-independent tables, the system also checks the authorizations for object S_TABU_CLI. If you have configured line-based authorization checks in Customizing, the system also checks authorization object S_TABU_LIN. Assign tables or views to a table authorization group using transaction SE11 or SE54. You can also define table authorization groups using transaction SE54. If your customer development implements direct access to a table, use the VIEW_AUTHORITY_CHECK function module to perform the authorization check. For more information about generic access to tables, see SAP Note 1434284 Information Published on SAP Site and the online documentation for the authorization objects mentioned above.
Identify Executable Transaction Codes
Transaction PFCG also offers you the option of automatically collecting permissions. Not every transaction entered into a single role via a role menu necessarily needs its own permission entry in the permission tree, because some transactions have identical or similar permission proposal values.
The first line defines that access to all files is forbidden unless other settings have been made for them in the other lines. The asterisk (*) is in the first place here and in this case for all files and paths. If the asterisk is in a different position, it is interpreted as part of the file name, which is not allowed in Microsoft Windows, for example. In our example table, setting the switches FS_NOREAD = X and FS_NOWRITE = X for all paths prohibits reading and writing. This makes the table a white list. This is preferable to a black list for security reasons. SPTH, on the other hand, becomes a Black List if you remove the first line with PATH = * in our example or if you do not set any of the switches FS_NOREAD, FS_NOWRITE or FS_BRGRU. The second line with PATH = /tmp allows read and write access for all files starting with /tmp, similar to a permission value /tmp*, as an exception to the access ban defined in the first line for all files and paths. This setting is not limited to subdirectories, but includes, for example, all files whose name starts with /tmp-xy. The third line with PATH = /tmp/myfiles defines a permission group with FS_BRGRU = FILE, triggering the subsequent permission check on the S_PATH object. The SAVEFLAG = X switch defines that these files will be included in a backup procedure; however, this is not relevant for the permission award.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Parallel enabled permissions (ST01 or STAUTHTRACE transactions) can be used to identify the required permissions and assign them to the user through the appropriate roles.
In addition, to ensure that you do not lose information with your upgrade work, you can write and release the data from the SU24 transaction on step 3 (customer table transport) in the SU25 transaction to a transport order.