Users Created ...

[Former Member]

1. I recall a discussion where it was mentioned that a user can be created even by system users.

2. That is to say the users can be created even by those who neednot be a dialog ?

How can this be accomplished?

Thanks

[jurjen_heeck]

> 1. I recall a discussion where it was mentioned that a user can be created even by system users.

Indeed they can.

> 2. That is to say the users can be created even by those who neednot be a dialog ?

Exactly, thats how CUA works for the child systems, in the background

> How can this be accomplished?

Have a look at BAPI_USER_CREATE.

Jurjen

[Former Member]

1.Thanks..I did see a few posts on BAPI_USER_CREATE but pardon my question-- where do I see this BAPI_USER_CREATE ?

2.Let me rephrase my first post ;

--> If I have a SYSTEM User OR a Communication User ,Can this user be "USED" to create a Dialog user ? if so how ? -Just schedule a batch job to execute SU01? -TCD/PGM if so what will be the log in credentials?? I hope the reader can grasp the magnitude of the impact if this is possible.

Thanks

[Former Member]

Hi George,

It would be a trivial matter to create a program which creates a user with certain credentials which is scheduled as a background job to run under a system user.

You can see BAPI_USER_CREATE via SE37 (it's a function module) and can be accessed via RFC. It's not a huge task to create a spreadsheet with VBA code to use this BAPI to create a user (or easier to use an FM to copy or clone a user) as long as you know the system or comm user ID & password. They also need to have S_RFC and the background auths.

[Former Member]

There are several function modules and a number of reports via which you can generate users in SAP.

Some require config to set up the scenario, many dont. Some require very obscure authorizations to start the reports... so you might want to rethink roles or profiles based on copies of sap_all...

If not explicitly requested, the default user type is Dialog.

A potential soft-spot is that if not explicitly requested, the default user group for administration of the user (S_USER_GRP) is not defined, which means that only the activity field is usefull...

I will not tell you how you can misuse those report... but I will tell you how you can with relatively low effort prevent an easy misuse of them:

- be very carefull with the S_USER_GRP activity authorizations, regardless of the transaction or rfc authority of the users.

- check (manually?) that all users are assigned to correct user groups for admin purposes.

- the above applies to all users, including system users for batch jobs only and rfc users, and ddic etc.

- the above applies to all clients.

- be carefull with your password rules and do not set any rules which cannot be enforced (see SAP notes 832661 and 915488).

- protect your US* tables, as there is sufficient information in them to "crack" some passwords if the failover mechanisms of the too-strict-password rules are used.

- only install, configure and grant authority for the functionality which you use.

- users with known or saved logon data should have very minimal authority. Document the use cases.

- try to seperate the user generation from the user / authorization administration (S_USER_AGR and S_USER_PRO in particular) in such scenarios.

- be carefull with S_BTCH_NAM and naming conventions for SYSTEM user IDs.

- respect "cardinality" of RFC connections and SYSTEM or SERVICE users in them.

- S_DEVELOP is stronger than almost all other objects... particularly so once the user is "on the inside".

Monitoring is of course also important... => security audit log and SUIM change documents, as examples.

[Former Member]

Thanks a million!1 I was waiting for these inputs.

My driver for thesequestions was that ;

1. I am up against - all by myself- against granting sweeping authorizations irrespective of if its a system id or a communication s or what ever!

2. I didnot have technical back up statements go in to the meeting and oppose the biggies !!

3. Now that i have -THANKS to SDN -- Ican fight !!

4. But What really surprises me is why doesnt the managers understand the risk !! and just agree !!

Thanks All !!

[Former Member]

One way of doing it is pointing out to them (in a nice way, without starting a fight) that, in the absence of sustainable and reasonable preventative and detective controls, someone could cause mischief in the system using their ID, or the ID's of the business processes they are responsible for and have not documented all user cases for... - and they might be held liable as there might not be a way for them to prove that it was not themself, personally.

Infact, if severe security problems occurred due to neglecting or disregarding security, and it could be proven, then the shareholders and others might get nervous... (an ancient Chinese curse: "May you come to the attention of the authorities")

There are a lot of "mights" in there, and they might mention cost benefit ratios etc... but good luck and hang in there for a good cause.

I guess the biggest challenge for all is to understand the risk before making decisions, judgement calls, strategies... (that goes same for programmers and management).

Cheers,

Julius

[Former Member]

Juius,

You are more than a moderator !! you are a counselor too !! I see so much joy to be advised by folks like you !!

I am sure, so many are being benefitted by your guidance !!

PS: Please underatsnd that I ask stupid silly questions --as I have never had an education in this topic, I learned it all in this forum !!The eagerness to know constrained by time and "search " results is what makes me genuinely ask these Simple questions !!