Determine Permissions Error by Debugging
Authorization concept of AS ABAP
Service users are used for multi-person anonymous access, such as Web services. This type of user is also dialogical, i.e. it can log on to the SAP system via SAP GUI. With a service user, multiple logins are always possible, and password modification rules do not work. This behaviour has changed with the introduction of security policy. Because previously all password rules for the service user were invalid, and now the rules for the contents of the passwords also apply to the service user (see Tip 5, "Defining User Security Policy" for details on security policy). The password of a service user always has the status Productive and can only be changed by the user administrator.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.
In such a case the last error is displayed in SU53 or the display is empty. Then you can't avoid analyzing the error message of the transaction. One more tip in the end: Instruct the user to take the screen shot with , this will put the whole active window on the clipboard and you can see which transaction, system and context of the transaction it is. Smaller "SnagIt "s are mostly useless and lead to unnecessary queries.
Authorization concept
Different users in your SAP system will have different password rules, password changes, and login restrictions. The new security policy allows you to define these user-specific and client-specific. It happens again and again that there are special requirements for password rules, password changes and login restrictions for different users in your SAP system. There may be different reasons for this.
If you want to set up a new client or take over the movement data of the productive system in a development system, you should also consider the modification documents. If you have a client copy, you should first delete the indexing of the change documents (table SUIM_CHG_IDX), since you can restore the indexing after the copy. To do this, use the SUIM_CTRL_CHG_IDX report without selecting a date and check the Reset Index box. After the copy has been made, delete the change documents that are dependent on the client; This also applies to the client-independent change documents (e.g., proposed permissions, table logs) if you have copied the client to a new system. In addition, you should remove the shadow database alterations before copying the client and complete the index build after the copy. In any case, check the Reset Index box in the SUIM_CTRL_CHG_IDX report!
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
For example, this is the case in the Activity field.
For these loggers you need different recording filters and, if necessary, the possibility to select generic clients or users.