Handle the default users and their initial passwords
Use system recommendations to introduce security
A far more elaborate way is the identification via the business roll customising. Here you first identify the technical name of the area start page or the logical link in the customising of your business role in the CRMC_UI_PROFILE transaction. If you have an area start page, check the technical name of the corresponding logical link. The next step is to switch to the navigation bar customising in the transaction CRMC_UI_NBLINKS and identify to the technical name of your logical link the corresponding target ID in the View Define logical link. If you use the target ID as the search parameter in the CRMC_UI_COMP_IP table, you will get the information about component name, component window, and inbound plug as the search result.
If you want to export the movement data of the productive system to a development system, you should first export user master records and the permission proposal values and archive the complete change documents. After importing, you can then delete the imported change documents, in analogy to the client copy, and then reload and index the original change documents of the development system. The activities described here require administrative permissions for the change documents (S_SCD0 and S_ARCHIVE) and, if applicable, for the table logs (S_TABU_DIS or S_TABU_NAM and S_ARCHIVE). These permissions should be considered critical, and you should assign them to a small circle.
Prevent excessive permissions on HR reporting
Standard users such as SAP* or DDIC should also be implemented correctly in accordance with the authorization concept or SAP's recommendations. An important preparatory action here is to check whether the passwords have been changed for all standard users.
The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").
Authorizations can also be assigned via "Shortcut for SAP systems".
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
This only takes into account the applications that are maintained in the role menus of the selected PFCG roles.
You have already created roles for SAP CRM and would like to add additional external services? Nothing easier than that! Create PFCG roles for the SAP CRM Web Client, typically so that you complete the customising of the CRM business role before creating the PFCG role, based on this customising.