SAP_ALL SAP_NEW

[Mike Pokraka]

Hi Ed,

Just to add my 2p: On more than one occasion I've also had errors that
seemingly had absolutely nothing to do with auths, but in the end was due
to a missing SAP_ALL and took several days to hunt down.

Point them to the official SAP doco on the matter, which is quite explicit
about SAP_ALL. As Jocelyn already indicated, the use of WF-BATCH in first
place is often to INCREASE security by not allowing the users to perform
certain actions directly. The fact that different people all develop
workflows means they now all need to keep WF-BATCH auths up to date -
maintenance chaos.

Lastly, IMHO, putting a rougue piece of code into production is a far
easier and less noticeable way to do dirty deeds than trying to hack
WF-BATCH passwords unnoticed, so we're really chasing s hypothetically
very difficult scenario. It's a bit like locking your bathroom door to
stop someone breaking into your house!

Cheers,
Mike


On Fri, June 3, 2011 1:46 pm, Edward Diehl wrote:
>
> Thank you so much Mike, this is exactly the kind of feedback I was looking
> for.  Whether this will "get through" or not, only time will tell, but at
> least they have some information from the real world.
>
> Also, Jocelyn, I appreciate your comments and passed them along with
> Mike's.  Hoary is right!
>
> Ed
>
> From: madgambler at hotmail.com
> To: sap-wug at mit.edu
> Subject: RE: SAP_ALL SAP_NEW
> Date: Thu, 2 Jun 2011 22:39:29 +0000
>
>
>
>
>
>
>
>
> My sympathies.
>
>
>
> I've seen 2 clients try and fail dismally to not give WF-BATCH SAP_ALL and
> instead try and cobble together their own profile for a while in the
> misguided belief it would be a more 'secure' approach.
>
>
>
> In both cases the urge was brought on by some Audit report that overlooked
> the need to keep system user profiles up to date with authorisation object
> changes or face potentially huge work backloads trying to sort out the
> mess when inevitably someone missed something they couldn't be expected to
> have spotted coming through via an OSS Note of custom change or whatever.
>
>
>
> In the end, the amount of new software patches, enhancement packs and
> upgrades forced them to change their minds and instead invest some
> confidence in their SAP Basis people to keep the Workflow password setting
> under lock and key - just as they would normally do with other user
> profiles like the 'normal' BATCH.
>
>
>
> I hope sense prevails eventually for you...
>
>
>
> Mike GT
>
>
>
>
> From: edwarddiehl at hotmail.com
> To: sap-wug at mit.edu
> Subject: RE: SAP_ALL SAP_NEW
> Date: Thu, 2 Jun 2011 15:23:22 -0500
>
>
>
>
> Yes, thanks Mike.  What we're dealing with here is a bureaucracy.
>
>
>
> From: madgambler at hotmail.com
> Subject: Re: SAP_ALL SAP_NEW
> Date: Thu, 2 Jun 2011 21:02:04 +0100
> To: madgambler at hotmail.com
> CC: sap-wug at mit.edu
>
>
> Ah my bad, you explained your WF-BATCH user hasn't been given this for
> some reason? Um, why would you do that? Surely you need your Workflows to
> have almost superuser auths?
>
>
> Mike GT
>
> Sent from my iPhone
>
> On 2 Jun 2011, at 21:00, Madgambler <madgambler at hotmail.com> wrote:
>
>
>
>
>
> Presumably you have tried regenerating SAP_ALL in the target system?
>
>
> Worth a mention just in case somebody forgot?
>
>
> Mike GT
>
> Sent from my iPhone
>
> On 2 Jun 2011, at 20:41, Edward Diehl <edwarddiehl at hotmail.com> wrote:
>
>
>
>
> Thanks, Eddie, but therein lies the problem.  We've applied the note and
> we are still left with tasks failing because of no-authorization - and
> these failed to show up on the Security's authorization trace.
>
> As I asked, is anyone out there successfully using workflow where WF-BATCH
> does not have SAP_ALL AND SAP_NEW?
>
> Ed
>
>
>
> From: eddie.morris at sap.com
> To: sap-wug at mit.edu
> Date: Thu, 2 Jun 2011 20:54:19 +0200
> Subject: RE: SAP_ALL SAP_NEW
>
>
>
>
>
> Hi Ed,
>
> Take a look at note 1251255 which introduces SAP_BC_BMT_WFM_SERV_USER. It
> takes care of the authorization for the workflow runtime but you still
> need to add application specific authorizations.
>
> KBA 1574002 also gives details.
>
> Regards,
> Eddie
>
>
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Edward Diehl
> Sent: 02 June 2011 19:33
> To: sap-wug at mit.edu
> Subject: RE: SAP_ALL SAP_NEW
>
> Is anyone out there successfully using workflow with WF-BATCH carrying
> something other than SAP_ALL & SAP_NEW security roles?
>
> I'm sure many of you have confronted this issue.  I would be interested to
> hear your experience(s).
>
> Thanks,
> Ed
> _______________________________________________ SAP-WUG mailing list
> SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________ SAP-WUG mailing list
> SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug
> _______________________________________________ SAP-WUG mailing list
> SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>