Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Administrate usergroup SUPER (Db-query)

Former Member
0 Kudos

Hello,

I´d like to do an authority check which returns the users, who are allowed to administer usergroup "SUPER".

The results should not be generated with a transaction, but with database querys as I have to write a script which queries the db.

As far as I know, I need S_TCODE with value "SU01". But I can´t find the proper db-tables. I've thought of using TSTCA and combining it with UST10 to get a link from the T-codes to the profiles, but I don´t get any further.

Can anybody help?

Thanks

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Usergroup administration is via transaction SUGR. Anyone with access to that transaction and the underlying auths can modify usergroup SUPER.

If your requirement is what I think it is then you are looking to see who can modify users in group = SUPER. To be honest, I agree with Julius that what you are being asked to do will produce results that are relatively meaningless from a security or control point of view.

Why is the requirement to directly query the DB? It's reinventing the wheel. SAP provide transaction SUIM as a "cockpit" to a load of other reports, one of which is "Users by complex selection criteria". You can perform a selection based on transaction SU01 and auth object S_USER_GRP, Activity = 05, User Group = SUPER. You could even save it as a variant so it could be run really easily. Furthermore you could link that variant to a custom transaction in SE93 to make it super-simple for your client.

From a table point of view you could reference table AGR_1251 for the S_TCODE and S_USER_GRP auths and x-ref against USR02 for users, but the validity of the data still remains in question.

Unfortunately, it wouldn't actually prove much, the following are some of the reasons:

- There are lots of ways of accessing functions in SAP. Valid entry points could be SA/SE38, SE37, SE84, various OY* transactions, RFC calls etc.

- User group = SUPER can be changed without any ill effects in general. You may want to classify your sensitive users as something different. Checks on user group = SUPER are hardcoded in but in 10 years I've only bumped into them once or twice.

- Your Basis admin could easily change the user group at the DB level

I suppose that my point is that you can get a rough & ready report but in reality, for this particular situation it isn't really going to give you any particularly useful information in my opinion.

12 REPLIES 12

Former Member
0 Kudos

Obviously you don't have the faintest idea what you are doing...

> Can anybody help?

For exactly this reason SAP provides function module BAPI_USER_GET_DETAIL --> no tcode required, no DB table dependencies beyond the stable interface of the function, not error prone to interpreting single fields of possibly incorrect data, etc).

Cheers,

Julius

Former Member
0 Kudos

Yes, you´re right, I don´t have the faintest idea. I don´t have any experience with SAP user authorizations, but I got the task to write this script for a customer without any knowledge.

It would be nice if you could help me, but if you just like to make dumb comments, save your breath.

0 Kudos

Fair enough, it wasn't very polite of me...

0 Kudos

Allright.

So, it´s not possible to identify this users with a db-query?

0 Kudos

It would be futile and (also) dumb.

Just being honest...

0 Kudos

You mean the effort´s too big?

The function module has no use for me, I extract data from SAP and analyze it afterwards.

Edited by: Greenhorn on Nov 27, 2009 12:03 PM

0 Kudos

> You mean the effort´s too big?

>

> The function module has no use for me, I extract data from SAP and analyze it afterwards.

>

> Edited by: Greenhorn on Nov 27, 2009 12:03 PM

The effort is not too big, just that the data that you want to analyze is relatively meaningless from a control perspective.

0 Kudos

No, the effort of downloading some tables or querying them is very low and easy bait.

It is the meaningfullness of the result which is futile and over time obsolete (new tables, new fields, new semantics, etc), not to mention that many of such tools are themselves a security hazard (e.g. unprotected access to the data including fields other than the usergroup, leaving the results around on file systems and external databases, SQL injection vulnerabilities in the code itself, etc...).

Have you considered that there is standard functionality in SUIM which does exactly this, if you give it the correct selection values?

For example:

User group changes or password resets for ...

OR

Role assignment for ...

OR

Profile assignment for ...

OR

Executing development objects for ...

OR

Import of transport requests for ...

OR

Foreign batch scheduling for ...

OR

Client side RFC connections for ...

OR

Password for ...

You will need to find the value(s) of ... each time from the previous output. A DB query on TSTCA for 'SU01' would be futile...

Cheers,

Julius

Former Member
0 Kudos

Usergroup administration is via transaction SUGR. Anyone with access to that transaction and the underlying auths can modify usergroup SUPER.

If your requirement is what I think it is then you are looking to see who can modify users in group = SUPER. To be honest, I agree with Julius that what you are being asked to do will produce results that are relatively meaningless from a security or control point of view.

Why is the requirement to directly query the DB? It's reinventing the wheel. SAP provide transaction SUIM as a "cockpit" to a load of other reports, one of which is "Users by complex selection criteria". You can perform a selection based on transaction SU01 and auth object S_USER_GRP, Activity = 05, User Group = SUPER. You could even save it as a variant so it could be run really easily. Furthermore you could link that variant to a custom transaction in SE93 to make it super-simple for your client.

From a table point of view you could reference table AGR_1251 for the S_TCODE and S_USER_GRP auths and x-ref against USR02 for users, but the validity of the data still remains in question.

Unfortunately, it wouldn't actually prove much, the following are some of the reasons:

- There are lots of ways of accessing functions in SAP. Valid entry points could be SA/SE38, SE37, SE84, various OY* transactions, RFC calls etc.

- User group = SUPER can be changed without any ill effects in general. You may want to classify your sensitive users as something different. Checks on user group = SUPER are hardcoded in but in 10 years I've only bumped into them once or twice.

- Your Basis admin could easily change the user group at the DB level

I suppose that my point is that you can get a rough & ready report but in reality, for this particular situation it isn't really going to give you any particularly useful information in my opinion.

0 Kudos

Thanks Alex, that was very helpful.

First of all, the requirement is what you specified (Users, who modify users in group SUPER).

I already performed the search for users with complex criteria and also SE93.

Now to your question why "reinventing the wheel": Our customer gave us SAP auditing guidelines. The guidelines describe audits within SAP. Our customer wants us to realize as many guidelines as possible with the software he uses for auditing. He doesn´t want to do complex transactions in SAP, but just wants to execute one of our scripts, which run the audits automatically with data extracted from the system.

But thanks to your answer, I can tell him that the data which is generated is not valid.

0 Kudos

It is interesting to see that they have taken this approach. In the grand scheme of things, this particular example is a relatively simple one compared with what else I would expect to be queried.

In general, for extracting the data the RFC suggestion by Julius would be my first choice, another alternative would be to create all your report variants via SUIM and schedule them to run and drop the file in a particular location. You could then pick up the file and do all your processing on that. At least that way your queries would be able to reconcile to SAP reports 100% (this is something the auditors would do some checking on )

0 Kudos

... for extracting the data the RFC suggestion by Julius would be my first choice ...

Also worth considering is that the BAPI makes the correct checks in the correct tables to determine whether you are authorized to audit the "SUPER" users. SUIM does the same and lets you know if something was excluded...

DB table queries generally dont do this (and the auditor might find that...) as well as all the files scattered around with critical user information in it.

A good auditor would take a closer look at what Stephan describes as:

He doesn´t want to do complex transactions in SAP, but just wants to execute one of our scripts, which run the audits automatically with data extracted from the system.

... and how that "interface" works, as well as how secure the extracted data is.

From my experience in technical audits, such "auditing tools" are a greater hazard to the system security than what a few authorizations are. They are typically also client side tools and make a grand mess of your network security options when a dependency on connecting directly to the DB is created.

All round bad idea, particularly if you have no idea which tables, fields and values to use in combination for the risk.

My initial comment to this thread was also based on the fact that "Greenhorn" has also asked many "What is the table for this and that ..." type questions. Each of those are release and patch level dependent (which we dont even know!) so I shudder at the thought of how many futile queries there are out there "in the wild" ...

Cheers,

Julius