RFC Users & Authorisations

[Former Member]

In the profiles of the RFC users it was noticed that SAP_ALL was present. In order to remove this, :

1.its needed to know what other authorisations need to be assigned.

2. This is the bottle neck. How does one understand which are the activites that are being performed.

Thanks

[jurjen_heeck]

>

> 1.its needed to know what other authorisations need to be assigned.

That depends on the actual answer to your second question.....

> 2. This is the bottle neck. How does one understand which are the activites that are being performed.

A trace may give some clues but you really need to know what the rfcuser is (supposed to be) used for and that means finding out which interfaces and or connections depend on this user. I do not think there's an easy 'technical' way to get this information.

If you build roles purely based on trace information you're bound to oversee an interface that runs only once a month or year......

Jurjen

[Former Member]

Yes! I agree totally. On eway is to ask the owner himself, but again they will say they cannot work if they dont have SAP_ALL in the profile of the RFC user. What is the independed way to reach there.

[jurjen_heeck]

>

> What is the independed way to reach there.

Well, as I said, you could try a system trace (ST01) while the interface(s) is/are running but you're almost guaranteed to miss some stuff.

The independent way is to send the person who told you to get rid of SAP_ALL to the person who claims he cannot work without it. Let them do the fighting. At some point one will have to give in (probabely the owner of the interface/rfc-user) and give you the information needed.

Good luck!

Jurjen

[Former Member]

The intended way is to document requirements for RFC interfaces and build a role limited to those requirements (not ALL...).

But people are very often not aware of the risks, so I would recommend explaining to them that their RFC interface with limited requirements represents a risk to the entire system as an unknown body of users can do anything to the SAP system at will, which is only limited by the skills of those persons or their fear of being found (multiplied by a severity coefficient of the consequences).

This is a polite way of going about installing "ownership" of the RFC user and responsibility for the authorizations.

Good luck!

[Former Member]

Thanks Juluis!! Now here we trip on a very important question point...How does the Unkown body of users get acess to the RFC id /pwd ? Unless its compromised personally ?

What specifics are the potential impacts the compromised id do ?

On the sidetrack , the auditors are moved with RFC users !! Why would that be , to my auditor I put forth the question the answer was " they are not Dialogue users !"

[Former Member]

>

> Now here we trip on a very important question point...How does the Unkown body of users get acess to the RFC id /pwd ?

Chances are good that they do not need the id / pwd. They only need the name of the RFC destination (for which the id / pwd is saved in SM59, already) and the ability to run "the" or "an" interface (or generate a dialog session).

Another option is not to save the logon data in the destination, and request that the current user running the interface in the source enter their own (valid) id / pwd for the target.

>

> Unless its compromised personally ?

Not necessarily necessary, but that does often add a new dimension to the risk, as the folks have a wider choice of sources from which they can "run an interface" using the id, and a wider group of folks (who talk to each other...).

>

> What specifics are the potential impacts the compromised id do ?

You mentioned before that it has SAP_ALL?? Go figure what that means...

>

> On the sidetrack , the auditors are moved with RFC users !! Why would that be , to my auditor I put forth the question the answer was " they are not Dialogue users !"

See above (SAP_ALL). The user could change itself to a dialog user... I can think of approximatly 300 thousand reasons (just off the top of my head) why your auditors are <removed_by_moderator>

Most likely they have, much like the interface user owner you described before, been told this and have not questioned it. Or the thought never crossed their minds that the id would not be required at all if it cannot "logon"...

[Former Member]

PS: What do you mean by "moved"?

[Former Member]

Juluis,

that word got in as I was drafting the question....I wanted to write " worried' "bothered". Apart from SAP your english too is good !!

Cheers

George

[Former Member]

Perhaps they have heard something, but might not be sure (yet) what it is?

Auditors in some countries are however not allowed to consult or provide solutions... this places them at an additional disadvantage, as finding the problem is often half of the solution and vis-verse

Cheers,

Julius

[Former Member]

Juluis,

I am going hammer & tongs to implement this. Our concern must not be the audit or auditors opinion but larger security of the corporation & associated data.

[Former Member]

While remaining a nose-length ahead of the auditors is widely considered a benchmark, I completely agree with your approach as a more sensible and sustainable goal.

Cheers,

Julius