In this post, we’ll analyze the most important SAP authorization limits. If you came across this page, you probably know that they exist – and may have made an unpleasant acquaintance with them.
However, did you ever wonder about the reasons?
Profiles per user
A maximum of 312 profiles can be assigned per user.
This includes standalone profiles (SU02) as well as role profiles; composite profiles (like SAP_ALL) count as one; roles may consist of more than one profile (see below).
The profile-to-user assignment is stored in table USR04; the relevant fields are BNAME (user name) and PROFS (list of assigned profiles).
The field PROFS has a length of 3750 characters and the first two characters are reserved for the user’s change flag (“C” = created, “M” = modified) plus a space character. The remaining 3748 characters hold the list of profiles names (12 characters reserved for each, shorter names are right-padded with spaces).
Thus, the maximum number of profiles is:
(3750 – 2) / 12 = 312,3… ➜ 312
Remark: on “older” systems this limit used to be 300 due to a hard-coded limitation (see SAP Note 841612).
Authorizations per profile
The maximum number of authorizations per profile is 170.
The authorizations assigned to a profile are stored in table USR10, which holds the profile name in field PROFN and the list of authorizations in field AUTHS.
Analogous to the profile-to-user assignment, this field is 3750 characters long and starts with two reserved characters: the profile’s change flag (“C” = created, “M” = modified) plus a space character.
Each entry in the remaining space consists of the authorization object (10 characters) plus the authorization itself (12 characters).
Hence, the calculation is:
(3750 – 2) / (10 + 12) = 170,36… ➜ 170
Profiles per role
One single role may consist of up to 101 profiles holding the authorization data.
When generating a role, one profile is created for every chunk of 170 authorizations.
Those profiles are “numbered” using a two-character appendix starting with ” ” (two spaces), then “1 “, “2 ” … “10” …
When the appendix reaches “99” it is incremented to “*0” (asterisk-zero), because it’s not an integer but a character variable. After the next 170 authorizations, SAP tries to increment it again – which is impossible, since the variable is not numeric any more.
This leads to a “CONVT_NO_NUMBER” short dump in PFCG and SUPC.
Hey, Daniel. Thanks for this great article, 11 years later im still having a good time diving into this topic.
For example, Im working with a business role Y_ADMIN, it has a generated profile T-JP795250. Due over than 170 authorizations inside, subprofile T-JP7952501 was created by the system as AGR_1016 shows me.
Exploring authorization tree of Y_ADMIN i realized that there is some standard authorization instances for S_DATASET (T-JP795250 01 , T-JP795250 02… till… T-JP795250 09) i also observe that these auth id instances repeats for every authorization objects and get increased as far as su24 push new duplicated objects with different field values.
01) I suppose that i can have up to 99 auth instances per auth object(…T-JP79525099) due 12 characters limitation and the last two characters is only relevant as a index, am i right?
02) Whereas different auth objects have same id auth instances(S_TCODE T-JP795250 09 , S_SPO_ACT T-JP795250 09) , kernel authority check reads id and object name to works, right? So, we will never see same auth objects with same auth id instance(two entries of T-JP795250 09 for S_DEVELOP), since it would conflict and overlap authority checks, right?
03) There is no relashionship between auth id instances entries and his distribuition over subprofiles. Subprofile is an abstract instance that work as a shell for each bunch of 170 authorizations, as far as i delete authorization reducing the amount to less than 170, T-JP7952501 entry will no longer be needed, will desappear from AGR_1016?
I hope there is no limit (312) to assign the profiles, we can assign any number of profiles right?
in SAP_BASIS Rel. 7.50 or higher, the limit of 312 profiles per user has been removed. In lower releases it is still relevant.
this is really a great piece of information, we are actually investigating one of the role issue happened to our organization related to the subprofile. Hope you can help me for some advise.
We are using the parent-child role concept, and we have a parent role that has 3 profiles.
There are 5 child roles linked to that parent, the issue happened when we changed the parent role, generated and cascaded it to the child roles. We don’t know why one of the child roles changed the sub-profile name (for example, from xxxxxxxxxx2 it changed to xxxxxxxxxx3) but for the other child roles there are no changes. What do you think is the reason? Hope to hear from you, thank you.
I have two questions.
1) If new profile is generated after the 170 authorizations whether the old profile become inactive
2) In user master data both profile will be there or only one??? If only new one, then what about the authorizations saved in the old one… how user can access those?
1) nope – before SAP_BASIS 7.50, you can have up to 101 profiles with 170 authorizations each, and all of them are considered.
2) as I said: up to 101 profiles are possible. After that you won’t be able to generate the role. And again, this is only valid up to SAP_BASIS 7.50.
Please check SAP notes 2838243 and 410993.
Great information! One question, could you suggest what should be the remedial action if we have assigned 312 roles to user and still more number is required.
SAP note 2838243 offers 3 possible solutions:
1. When you use roles exclusively, the number of profiles per user can only be doubled by assigning a reference user.
2. If you also use manual profiles, you can combine these to form collective profiles.
3. Upgrade the system to SAP_BASIS Version 7.50 or higher; in these releases, the restrictions of 312 profiles per user master record and the restriction of the single values per authorization are removed.
thanks for this post.
For basis version 7.50, in which table user profile assignments are stored? Table USR04, PROFS is blank…
In FAQ – 2293683, SAP mentioned that 312 limit has been removed. Please help to understand how this is achieved.
beginning with SAP_BASIS 7.50, the profile-to-user assignments are stored in table UST04 only.
Change documents are not stored in table USH04 anymore, but rather in the central change documents (object class IDENTITY).
That’s also how SAP overcame the famous 312 limit: the profile assignments are not stored in a single field (with limited space) anymore, but as separate lines in UST04.
Best regards, Daniel
Hello sir, 101 profiles and 170 authorizations in each profile is it still the same for SAP 7.6?
it is not – please check the SAP note mentioned → here and the information → here.
totally loved the way you explained the logic behind this.
One question: Let us suppose there is only one object (suppose S_TCODE) in the role.
How many transactions can we add in the role (I guess unlimited – as per the explanation – but this is not possible).
So after adding how many t-codes second profile will be created and why?
Thanks in advance 🙂
the authorization values for S_TCODE are (among other places) stored in table USR12, field VALS.
Since the length of this field is limited, new lines are created once the preceding line is “full”. The exact amount of tcodes per line differs depending on their lengh; in my test 332 tcodes with a length of 10 characters fit into a single USR12-line, but only 608 tcodes with 5 characters length (due to an increased overhead).
Once 99 lines are filled (number 00 … 98), a new line with number 99 would be created – but in this case subroutine CREATE_AUTH in include LSUSBF01 detects an overflow and skips all further actions.
As a result your profile is not fully generated and PFCG issues an error message like this one:
Have fun, Daniel
could you please clarify: as far I know, there can be a maximum of 150 authorization in a role.
that’s not true… a role can contain 101 profiles with 170 authorizations each.
So we have a maximum of 17170 authorizations per role.
can you please explain what exactly you mean by maximum number of authorizations per profile is 170?
It will great, if you will give us such some real scenarios 🙂
an authorization consists of an authorization object and its values; since standalone profiles are (hopefully) not used anymore, you usually add such an authorization to a role. If you add 170 authorizations to a role, the next one will make SAP create a second sub-profile for the role in question – you won’t notice this, since PFCG reserves the last two characters of the profile name to number the profiles of the role (up to 101 – see above). If you go to table AGR_1016, you can see the profiles, which belong to a role – so you can check the stuff above yourself. Simply add 170 authorizations, then compile and check AGR_1016 (→ 1 profile). Then add another auth. and check again (→ 2 profiles).
Have fun, Daniel
I would like to know, how can I calculate the benefits of removing more than 2.000 roles of production environment (storage, performance, etc.).
Is there any way to know the size of a role in terms of storage?
roles are nothing more than entries in a number of AGR_* tables (e.g. AGR_DEFINE); to get a rough(!) idea of the database space a roles consumes, you could could download it from PFCG to a text file.
To cut a long story short: it’s not worth the effort!
Apart from that there is no performance gain, when you delete roles…
thank you for sharing. 🙂
Hey. Thanks for the incredible piece of information…
One question (might sound silly) that pops up in my head is that when we talk about the number of authorizations per profile to be 170, then it would also count in deleted authorizations right… cause the entries are still being occupied???
If we’re talking about profiles that belong to roles (the ones in the “Authorizations” tab in PFCG):
➡ active authorizations are stored in the profile – no matter whether the values have been partially or fully maintained
➡ inactive authorizations are not stored in the profile (i.e. they do not affect the maximum number of 170 authorizations)
If we’re talking about “standalone” profiles (SU02):
➡ all objects in a profile count (no matter whether an authorization exists or values are maintained)
Thanks for the response… you are awesome 🙂
Great info, Daniel.
There are some exercise, but SAP note 410993 says that 150 authorizations per profile. However, we do understand sequenced profile will get generated when more than 150 or 170 authorizations are added, but how can I find that how many authorizations a role contain and is there any table which can help?
a role can have up to 101 profiles with 170 authorizations each… so the answer to your question is: a role can consist of up to 17170 authorizations (which should be sufficient in most cases 😉 ).