Authorizations for a RFC-User for Seeburger Application

[Former Member]

Dear all,

I have a request from Seeburger to establish a RFC-user between ERP 6.00 and PI/XI systems. Seeburger refuses to make any statement regarding the authorisations such a user would need and demand I give them SAP_ALL and SAP_NEW, otherwise they refuse to guarantee the working of their 'solution'. All arguing was to no avail ... so I come here asking:

Has anybody of you ever worked with Seeburger and was able to work out what kind of authorisations their RFC-user would need? is there more than the usual S_* ... application authorisations, probably?

Thank you all in advance.

Cheers,

Mylène

P.S. to the mods: if you feel, I should have asked this in the PI forum, please feel free to move this thread.

[jurjen_heeck]

> demand I give them SAP_ALL and SAP_NEW

Oh dear, wanting SAP_NEW with SAP_ALL is a really bad sign. Very appropriate of you to put quotes around the word solution. Can't help you out with your real question, sorry 'bout that.

[Former Member]

That, combined with a hardcoded pwd is a "hole in the head" solution...

[Former Member]

I didn't work with Seeburger, but isn't it possible to trace the RFC-user with ST01 when he logs into system to find out what he is doing and what authorization he needs?

Regards,

Julia

[Former Member]

Hello,

I am not sure what SEEBURGER has to do with a RFC connection between PI and ERP, however from experience with our RFC/IDOC adapter (not used in XI) we know that it is not always easy to describe what rights the RFC user should get. This is especially true if some hooks/userexits or special function modules are used.

Using a user with brought rights like SAP_ALL is "not the best solution" from a security perspective and you should of course avoid it in production. You can start small like "S_RFC" and add all other rights until the operation you want to execte works.

Maybe the tracing solution Julia mentioned works as well. If you want to have help here which If you want to restrict the rights, I think the trace solution Julia mentioned is the best way to find out the required permissions.

Greetings

Bernd

[Former Member]

Thank you all for your answers, especially Julia and Bernd. Of course I am aware that I could trace the whole affair, if only Seeburger would see fit to allow it. They don't. I have an E-Mail from them telling me that security is none of their concern - which I find slightly strange.

Julius, would you please point me to information regarding that PWD problem of Seeburger's? Is there another hidden trap somewhere? Thank you in advance.

Again, thank you all for taking the time to help me. I shall leave this thread open a little longer ... for that PWD information ... if you can think of something else, I would appreciate your comments.

[Former Member]

> from experience with our RFC/IDOC adapter (not used in XI) we know that it is not always easy to describe what rights the RFC user should get. This is especially true if some hooks/userexits or special function modules are used.

From my experience, this is exactly the reason why a developer of an application which is going to be remote enabled should develop the role together with it, such that only documented and intended features of the 386033 function modules in my system can be used.

If someone wants to enhance the application, they need to enhance the role as well.

If someone wants to use the same connection for a different application, then they need to build their own role for it.

Anything less than that can only lead to SAP_ALL, cardinality problems, D-o-S attacks, data leakages, system inconsistencies, etc.

If you add hardcoded passwords which are the same in all systems of all customers to that, worldwide... then you have caused a big, BIG problem and history has shown that it is just a matter of time until it backfires on the vendor.

At the very least I would expect a vendor to deliver and maintain a template role for the customer to copy into their own namespace and "tune" to their requirements - like SAP does.

Cheers and please keep us posted on any progress,

Julius

[Former Member]

>

> From my experience, this is exactly the reason why a developer of an application which is going to be remote enabled should develop the role together with it, such that only documented and intended features of the 386033 function modules in my system can be used.

We are not talking about an developed application (at least I think so, the original poster did not yet disclose the pplication we are talking about). The SAP IDOC Adapter is calling the RFC method to book IDOCS. This is converd by B_ALE_ALL and S_IDOC_ALL. However booking those IDOCS require more steps (based on the mode the IDOC is delivered, the message type and even the content of the IDOC). SAP themsef is very unspecific about the rights you need to book a IDOC for this reason. I am not sure how, why and what SEEBURGER can recommend here.

Greetings

Bernd

[Former Member]

> Julius, would you please point me to information regarding that PWD problem of Seeburger's? Is there another hidden trap somewhere? Thank you in advance.
> 
> Again, thank you all for taking the time to help me. I shall leave this thread open a little longer  ... for that PWD information ... if you can think of something else, I would appreciate your comments.

I think Julius was just genrally ranting. SEEBURGER is not shipping fixed (default) passwords, and the Password for RFC users can be specified. In your case I think we are not talking about SEEBURGER Softweare at all, since the RFC connection of XI/PI is opened by SAP not SEEBURGER components. Besides: I do not now any certified vendors who use fixed passwords. That rant is just missleading and has nothing to do with your problem.

Please be more specific why you mention SEEBURGER here. I understand that you want to connect your PI to your ERP system and need an RFC user. I suspect this user is required to book IDOCS generated by the SEEBURGER EDI Adapters. Is this correct? In this case the RFC User needs some RFC, ALE and IDOC specific permissions (B_ALE_ALL and S_IDOC_ALL should cover those) and some more authorizations based on the code which is executed to book those IDOCs. The later you can sometimes find in the SAP documentation and sometimes you can find them by trial and error. Be especially aware that they varry by Version, Message Type, Function and even sometimes depending on the content of the IDOCs (if special handling is triggered).

If you are a SEEBURGER customer, your contact is the SEEBURGEr Support, which can be reached via OSS. If you get the request from an consultant, ask the consultant to specify a more aproperiate subset of authorizations objects for the role of this RFC user.

Greetings

Bernd

[Former Member]

Hi Bernd,

> We are not talking about an developed application (at least I think so, the original poster did not yet disclose the pplication we are talking about).

If there is no application, then the SEEBURGER user would not need to exist and would not need any authorizations anyway.

> The SAP IDOC Adapter is calling the RFC method to book IDOCS. This is converd by B_ALE_ALL and S_IDOC_ALL.

No, these are old manual profiles. They are obsolete - even if they still work.

> However booking those IDOCS require more steps (based on the mode the IDOC is delivered, the message type and even the content of the IDOC). SAP themsef is very unspecific about the rights you need to book a IDOC for this reason.

This was true and the odd OSS notes from older times also followed the same approach, contrary to the recommendations.

But SAP is more specific now and also delivers the required roles (or some profiles still) together with their RFC applications.

> I am not sure how, why and what SEEBURGER can recommend here.

Assuming that this is the SEEBURGER user delivered to be called from a SEEBURGER application, then please take a look at [SAP Note 460089|https://service.sap.com/sap/support/notes/460089] which is quite specific about what is needed for each environment and release.

Cheers,

Julius

[Former Member]

> Please be more specific why you mention SEEBURGER here. I understand that you want to connect your PI to your ERP system and need an RFC user. I suspect this user is required to book IDOCS generated by the SEEBURGER EDI Adapters. Is this correct? In this case the RFC User needs some RFC, ALE and IDOC specific permissions (B_ALE_ALL and S_IDOC_ALL should cover those) and some more authorizations based on the code which is executed to book those IDOCs. The later you can sometimes find in the SAP documentation and sometimes you can find them by trial and error. Be especially aware that they varry by Version, Message Type, Function and even sometimes depending on the content of the IDOCs (if special handling is triggered).
> 
> If you are a SEEBURGER customer, your contact is the SEEBURGEr Support, which can be reached via OSS. If you get the request from an consultant, ask the consultant to specify a more aproperiate subset of authorizations objects for the role of this RFC user.
> 
> Greetings
> Bernd

Bernd,

B_ALE_ALL and S_IDOC_ALL are profiles. Profiles are no longer in use with SAP applications since 4.6C - what kind of recommendation is that, coming from a service provider and that in a release ECC 5.0/6.0 ?

I do not see why it is my part (as the Basis and Security Person) to study the SAP documentation for objects your application requires, much less find out by trial and error. I do see on the other hand, that my service vendor SEEBURGER who has implemented such dozens (hundreds) of times provides me with a template I can easily adapt. Other 3rd party products like CREFOSPRINT, SE16XXL etc are doing so ... but SEEBURGER does not - in fact, the SEEBURGER consultants I was 'communicating' with, refused (and rather rudely so) to specify anything - otherwise I wouldn't have had the need to come here and ask!!

Cheers,

Mylène

[Former Member]

>

> Assuming that this is the SEEBURGER user delivered to be called from a SEEBURGER application, then please take a look at [SAP Note 460089|https://service.sap.com/sap/support/notes/460089] which is quite specific about what is needed for each environment and release.

In the "EDI-Adapter for PI"-case there is no SEEBURGER app starting an RFC call, and there is no SEEBURGER FM called by RFC. (Thats why I said I still dont know what Seeburger has to do with this problem).

But thanks for the SAP Note, it is helpfull to configure IDOC receives. However, I miss the authorizations required for synchronous IDOC booking (which AFAIK reaches into normal business services). Do you know if this has changed with later versions, and the checks for receiving IDOCs also cover the followup processing of those message types?

Greetings

Bernd

[Former Member]

>

> We are not talking about an developed application (at least I think so, the original poster did not yet disclose the pplication we are talking about). 

I think we are talking of a service provided by SEEBURGER. Whether it is especially developed or adjusted for the customer, I do not know.

But I find that to be besides the point. My question was, and please let me state it again: if SEEBURGER requires RFC-users what kind of auths would they need if I am not willing to grant SAP_ALL ... has anybody come across such!

[Former Member]

> I do not see why it is my part (as the Basis and Security Person) to study the SAP documentation for objects your application requires

Before we continue: which application are you talking about? SEEBURGEr has a large number of add on modules and applications. I do not know any which requires an RFC user, but I might be wrong.

Gruss

Bernd

[Former Member]

> But I find that to be besides the point. My question was, and please let me state it again: if SEEBURGER requires RFC-users what kind of auths would they need if I am not willing to grant SAP_ALL ... has anybody come across such!

Please contact me (see my business card) and sent the names of the consultants or the company name you are working for and I can make sure to find out what installation we are talking about.

As I said before I dont think there is a SEEBURGER application involved in doing RFC thats why we cant tell you the authorisations. But to verify this fact, I need to know the project and the internal contact.

Greetings

Bernd

[Former Member]

> I think Julius was just genrally ranting.

Yes, generally ranting about the topic as well because I have come accross it before and much like Mylene I was not happy about it. It is usually someone with no clue about application security who then tries to bully you into giving them SAP_ALL. Some of them even intentionally do not deliver information about which access they require until shortly before go-live and then you have the whole project team on your case to give the brat his SAP_ALL. That the person asks for SAP_NEW is also a clear symptom of this, because a regenerated SAP_ALL contains all of SAP_NEW anyway...

> Besides: I do not now any certified vendors who use fixed passwords.

I do.

> That rant is just missleading and has nothing to do with your problem.

It is indirectly related, by making it worse (all authorizations for the system + publicly known password).

> I do not know any which requires an RFC user, but I might be wrong.

So, the question you need to be asking yourself is: Am I feeling lucky today...?

--> I will also contact you (via your Business Card data).

Cheers,

Julius

[Former Member]

>

> As I said before I dont think there is a SEEBURGER application involved in doing RFC ...

Bernd,

I have a written request from SEEBURGER to provide a RFC-user with SAP_ALL, SAP_NEW ... so I have to assume that SEEBURGER knows what they are requesting, don't I?

Anyway, thanks for the contact chance, I'll take it.

[Former Member]

> But thanks for the SAP Note, it is helpfull to configure IDOC receives. However, I miss the authorizations required for synchronous IDOC booking (which AFAIK reaches into normal business services). Do you know if this has changed with later versions, and the checks for receiving IDOCs also cover the followup processing of those message types?

If the RFC user is also processing the IDOCs and not only receiving them, then it will need the application authorizations as well. Nothing has changed here as far as I know.

What I typically do is that I maintain the authorization proposals in SU24 against the function module name for the scenario. The note already mentioned is a big help, and working out the rest is not that difficult. This way you only need to trace them once and can maintain the authorizations centrally if you have a multiple of RFC related roles to deliver.

It also means that you don't need to introduce any S_TCODE authorizations to the RFC user, as they do not need any.

For a "typical" integration of FICO, HR, CRM, PI and BW I usually only need about 50 RFC names in total, for which I maintain SU24 for about 20 of them.

It is always interesting to see how little they actually need and how clear it is what they are meant to be used for afterwards.

Regularly these types of connections are also being "misused" to various degrees of "naughtiness". You will find those in ST22 (Short Dump Monitor) after you have switched to a "need-to-have" role concept. Beforehand, you don't stand a chance of finding it amongst all the successfull calls.

Cheers,

Julius

[Former Member]

Looks like this little convenience (the password and the access) is reaching mainstream knowledge...

See the blog by Prateek Raj Srivastava: [PI with Seeburger - A tip for Security Administrators|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/17319] [original link is broken] [original link is broken] [original link is broken];

It also contains usefull information about where you can change the password on the connector side.

Cheers,

Julius