Question:
Hi John,
You wrote:
Many of SAP's "enhancemnts" cure a symptom rather than the root problem and introduce more security holes (i.e. AUTH/new_buffering.)
What do you recommend for the parameter? What does a non-valid parameter mean? The default is 4.
Many thanks,
Bob
Answer:
I recommend that you accept SAP's defaults.
_________________
bwSecurity
Answer:
I recommend you read the numerious OSS notes and decide for yourself based on your system.
The ramification of the settings NOT published are: Auth/new_buffering NE 0 allows you to add access undetected from SAP tools relatively easily on a temporary basis and semi detectable on a permanent basis.
Read the other notes to determine the best setting for you installation.
The Symtom SAP is trying to cure ( though it does not work 100% of the time) is "my users loose their access when I import a role or generate a role in prodiction". Solution, DO not import or gen in prime time and warn the users of the change to logoff before you gen or import.
Most compaies policy is to NOT allow transports in prime time so a setting or 3 or 4 does little good but open an exposure.
I opt for the higher threshold and recomment a setting of 0.
Answer:
I recommend you read the numerious OSS notes and decide for yourself based on your system.
The ramification of the settings NOT published are: Auth/new_buffering NE 0 allows you to add access undetected from SAP tools relatively easily on a temporary basis and semi detectable on a permanent basis.
Do tell. How is this possible?
_________________
bwSecurity
Answer:
Several ways and several methds using SAP tcodes like SE30, SE37 and a few others..
1. manipulation of table USREFUS, which if you believe SAP documentaion reference users cannot be used if New buffering in not 3+, I have not tested it. you can suppress the error message in SU01 in config so it becomes a bit hard to find the addition
2. changing the USRBF2 table yields a temporary access addition for up to 2 hours, cannot find in SU01, PFCG et.al.
3. Change UST04 and USRBR2 and you get permanent Acees change with a weird "I do not know what this means" icon in SU01.
Runninf PFUD, Writing an abap to execute the SYnc function module in a batch job and RHPROFL0 in batch can help "reset" this.
With new buffering set to 0 you have to manipuate USR04, not a trivial task and it shows up instantly in SU01.
Answer:
Several ways and several methds using SAP tcodes like SE30, SE37 and a few others..
1. manipulation of table USREFUS, which if you believe SAP documentaion reference users cannot be used if New buffering in not 3+, I have not tested it. you can suppress the error message in SU01 in config so it becomes a bit hard to find the addition
2. changing the USRBF2 table yields a temporary access addition for up to 2 hours, cannot find in SU01, PFCG et.al.
3. Change UST04 and USRBR2 and you get permanent Acees change with a weird "I do not know what this means" icon in SU01.
Runninf PFUD, Writing an abap to execute the SYnc function module in a batch job and RHPROFL0 in batch can help "reset" this.
With new buffering set to 0 you have to manipuate USR04, not a trivial task and it shows up instantly in SU01.
I giess most of us will never see this because we don't try to write code that directly posts to SAP tables. Thanks for sharing.
ps How did you write an entry to USBR2 (or whatever the correct name of that table is)?
_________________
bwSecurity
Answer:
I giess most of us will never see this because we don't try to write code that directly posts to SAP tables. Thanks for sharing.
ps How did you write an entry to USBR2 (or whatever the correct name of that table is)?
True, but those wanting to "infiltrate" the system do not care and perform direct updates all the time and to prove the concept you have to, in Development of course.
Sample code ( not elegent but...) assumes SAP* has logged on and has SAP_ALL. with auth/new_buffering <2 ( I believe) the table is loaded.
Report test.
Tables USRBF2.
Select * from USRBF2 where bname = 'SAP*'.
usrbf2-bname = 'anyid'.
modify usrbf2.
endselect.
now anyid has SAP_ALL.
You can actually select the records from any client and insert in any client with the correct syntax.
Answer:
[quote="John A. Jarboe"]
now anyid has SAP_ALL.
You can actually select the records from any client and insert in any client with the correct syntax.
That is an interesting strategy!
Depending on your release and package level, there can be several other ways of changing sellected entries in the table.
Bob
Answer:
[quote="John A. Jarboe]True, but those wanting to "infiltrate" the system do not care and perform direct updates all the time and to prove the concept you have to, in Development of course.
[/quote]
Nice example. I do appreciate it.
But programmers who want to hack a system usually don't take the hardest way in. There are lots of easier ways to do this and relying on unreliable (and refreshable) buffers seems to be the hard way.
I wouldn't let this dissuade me from choosing a different set of buffering alternatives.
_________________
bwSecurity
Answer:
Relying on "Other methods" and not doing something about one you know is "security by ignorance" and not recommended. If youexpect other to take another path, those avenues may be blocked and THIS one may be the one of least resistance.
If you can prevent, you prevent. True there are other as easy ways to get in, I'm worried about those ALREADY in.
Any SAP recomendation by SAP is only as good as the context in which it is made. Unfortunately you are not privy to that context, and the only apparent reason for a higher new_buffering setting is so SAP does not have to hear you complain about users loosing their access when you do not follow their other recommendations. ( though they still loose their access)
Read the other OSS noe which highlight othe "problems" incurred with the new buffering and then make an informed descision.
SAP allows you to change these values to suit your needs.
Answer:
SAP allows you to change these values to suit your needs.+
I would rather say, SAP enables you to correct the defaults, depending on how informed you are...
Bob