Mass deletion of SAP roles from users

[antonio_steinhuser]

Hello All,

i need to delete all assinged roles from a big number of users. I know the users but not the roles which the users have. I need to delete all roles from the users-id's.

I know SU10 and i can select all my needed users. But in the role tab i can not work with roles-names like Z* to delete. I can select all z*-roles and select "remove" but when i click to save, i get the message no changes made on the users???

Any idea?

Gruß

Toni

[Bernhard_SAP]

fast solution...
try it the other way round.
Write a small wrapper report which passes the user names to the FM bapi_user_actroups_assign. Let table ACTIVITYGROUPS empty and execute.

All role assignments will be gone.

b.rgds Bernhard

[Former Member]

Hi Bernhard

Is using the FM option a standard security level of access or is it viewed as an EAM type access?

Kind regards

David

[Former Member]

BAPI function modules are released Business Application Programming Interfaces. Generally you can call them remotely, their import parameters are the same as the equivalent transaction function (in this case SU01), they are dialog free and make the same authority-checks (with the exception that S_RFC is checked and not S_TCODE).

SAP provides these BAPIs for customers and partners to be able to implement their own applications (z-reports) to access SAP data, but in a way which SAP controls.

Function modules which have names like Z_NAUGHTY_UPDATE_ROLES are on the other hand not released, stable and mostly don't make the same authority-checks as the equivalent transaction...  🙂

So it is perfectly OK to write an own program which calls a BAPI function for dialog free mass processing. We do that almost every day here.

Cheers,

Julius

[Former Member]

Hi Julius

Sorry to be a 'clog in the machine' 🙂

I am just trying to raise the awareness that clever options can so very easily run away with the user if the don't fully understand how the process is being run. Something as trivial as removing SAP roles from users could turn into a massive problem as far as I am concerned - the "Ah - it's just a case of put those users in that column and press 'Go'" especially in PRD makes me shiver.

We have a script to do lots of things but it still makes me hide behind the sofa Doctor Who like 🙂

best wishes

David

[Former Member]

Yes, you must protect it via powerful authority-checks - but if authorized you have a powerful tool.

That is much better than scripting with dubious authority-checks and commits and screens which change.

The BAPIs are stable interfaces. SAP can extend them but cannot normally change them (there are a few exceptions - but the USER BAPIs are very stable and well supported - latest because SAP IDM and GRC uses them as well, so it is a good horse to bet your money on when you decide which coding approach to use for processing which SU01 and SU10 don't offer.

God bless BAPIs..  🙂

Cheers,

Julius

[Former Member]

Dear

Select all the users in SU10,

put in all the roles, select delete. The trick here though, is to put

a start date that is before the first assignment, and an end date that

is higher than the highest end date. So an interval could be

01/01/1900 to 31.12.9999 for all roles.

that should work

Regards

[antonio_steinhuser]

Hello Rajendra,

i do not know the roles. I select all Z-Roles in the role tab. But how can i change the date for all roles?

Gruß

Toni

[Former Member]

Dear

in roll tab you can Z* and date filed you can date as 01/01/1900 to 31/12/9999

try this

Regards

[antonio_steinhuser]

No,

this will  not work, when i only put Z* and the dates in the role tab, i get the Info "no changes made to user" ...???

Gruß

Toni

[antonio_steinhuser]

Here is pic from the role tab

Gruß

Toni

[former_member82556]

Hi Antonio,

Instead of using Z*, you need to copy and paste all the role names that start with Z.    The start and end date should automatically populate, and you shouldn't have to adjust it. 

[antonio_steinhuser]

Hello Salim,

i also paste all Z* roles. You are right, the start and end date is automatic filled. But this will not help, because to delete the roles, you must change the dates like this 01/01/1900 to 31/12/9999 (how described by Rajendra). When you not change the date you will get the message "no changes made to user....)

Gruß

Toni

[former_member74904]

it has been a while since I last used SU10, but when I did I had to remove the corresponding profiles (in the profile tab) as well as the roles themselves.

also, the roles would not be removed as such but be delimited. you'd have to run report PRGN_COMPRESS_TIMES in order to really remove the roles from the users.

good luck!

[m_coenjaerts]

Another option would be the use of 'Batch Input Maps" (BIM): a tool in SAP which does a kind of "screen scraping": it simulates user input. It is used quite regular, even by SAP standard transactions. These BIM's are managed via de SM35/SHDB transactions. You could "record" a BIM (so executed the action in SU01 once) and then using the "mail merge" functionality in word you could create a BIM script for all the involved users.

In SU01 you can delete all the roles of the users in one shot: by opening the user in change mode, go to roles tab, click on the "SELECT ALL ROLES" button and then click on the "DELETE ROW" button. Using BIM recording you could record this action, and then with mail merge in word and a list of users ID's in excel, you could create a BIM that executes the same for all involved users.

See SAPTechnical.COM - How to do BDC without writing BDC program for more information or

[Bernhard_SAP]

Batch Input does not work anymore for su01 in the actual releases for role assignments...

[m_coenjaerts]

Hello Bernhard,

Thanks for the information. Do you know if this somewhere documented (in the release notes or sap notes). What is exactly not working? Is it BDC/SIM in general for SU01 or just some parts.

[mvoros]

Hi,

SAP refreshed the code behind SU01 which is really good. Unfortunately, it caused some negative The only part that is not working that I am aware of is role assignment. They used different component for a table of roles that is not visible during batch input run. This regression is documented in note 1864062.

Also the rewrite created some new bugs in SU01 so do not assume that SU01 is such an old transaction that is battle tested.

Cheers

[tobiasharmes]

Hi Toni.

I'm doing these kind of changes with a z-report. For the question which user has which role I'm using always SE16 and Table AGR_USERS.

Maybe this helps a bit.

Cheers, Tobias

[Former Member]

Hi Tobias

I take it this is being run in PRD? What checks are being carried out during the table entry deletions and are you 100% happy sitting at your keyboard when pressing the 'run' button?

Is there an easy way back to the previous state should it go wrong and how do you explain it to the auditors if needed that you assigned-number of roles in PRD against your own user ID possibly with no CDHDR/CSDPOS entries to back you up.

Sorry for the 'negative vibes' but I don't like direct table maintenance in PRD for security.

Best wishes

David

[tobiasharmes]

Hi David.

David Berry wrote:

I take it this is being run in PRD? What checks are being carried out during the table entry deletions and are you 100% happy sitting at your keyboard when pressing the 'run' button?

Changes are made in PRD. The program was tested and is approved by each customer.

Is there an easy way back to the previous state should it go wrong and how do you explain it to the auditors if needed that you assigned-number of roles in PRD against your own user ID possibly with no CDHDR/CSDPOS entries to back you up.

Sorry for the 'negative vibes' but I don't like direct table maintenance in PRD for security.

Best wishes
David

The way back is uploading the old role assignment previously exported from AGR_USERS. The program takes an excel sheet. In addition this excel sheet is attached to the change requests.

From risk perspective we say (and experienced): mass changes through copy and paste lead to much more errors and faulty authorizations.

Regarding direct table maintenance: standard function modules are used (like the one mentioned above) and the changes are visible in the change documents, Therefore the auditors grant an exception for using such tools.

Cheers, Tobias

[Former Member]

"Changes are made in PRD"

Just so that it is clear - user assignment to roles changed in PROD is always done in PROD. Whether you use SU01, or SU10, or CUA, or a BAPI... it makes little difference if the user which runs the code is correctly authorized for it (or not... and gets an error message).

The only exception is transporting roles with user assignments. That should ideally be deactivated by default and greyed out in DEV already if not enabled. It would be another way to toast the assignments - it certainly assigns them, but I never tried to use it for unassigning.

Anyway... I suspect the requirement here is to remove a whole bucket of old roles from users who now have new ones. A more efficient way of doing that is to use mass deletion of the roles themselves. That will torch the user assignments and the composite role assignments as well when you run PFUD and execute the "zero problems" program to clean up all the obsolete data in the USR* tables.

As long as all the users have the new roles (so the selection is not user based anymore), then using a role based solution is a more efficient option.

Perhaps we can have more infos about the requirement? Is a complex selection based on users and / or roles needed? Much like Tobias, we have built our own programs using BAPIs and released function modules which do this - you can do anything you want to as long as you know what result you want to achieve from it.

Cheers,

Julius

[antonio_steinhuser]

Hello,

thanks a lot for all the infos.

I think i have found a solution. Test in DEV was successful

a) select all locked user in SU10 and add all Z* roles for remove for all users

b) when you now save, all roles in the users  get a new until date (day -1)

c) then you can run the report PRGN_COMPRESS_TIMES , the reports delete all elapsed roles

Gruß

Toni

[Former Member]

Ahh.. an "outside the box" thinker... cool! 😉