In reply to Chris Hemedinger.

Chris, Thanks for your reply. I agree with your explanation and that was the reason for my reaction. I have experienced that, are recognizing elsewhere. What I see:

a/ Setting op security on user accounts at OS level is seen as very difficult within many organizations. They have to think about it to conform to existing procedures and guidelines. Mostly it is done by RBAC (Role Base Access Control) that is fundamental different to the SAS RBAC that is controlling the menu’s, SAS should call their approach MBAC and then getting aligned to RBAC.
b/ The other too difficult part is “priviledged access management” that is saying you should not grant more access rights to a person as normal is needed. Administrator actions should be centrally monitored as. The way SAS (BI/Di) is working, forking processes and setting rights (root level) is a replacement for the standard terminal way SSH way of working at the OS level.
The monitoring on elevating access rights is missed as this is normal SUDO usage. Sorry for the technical Unix terminology, the concepts at Windows and Mainframe are globally the same.

As a kind of reaction on this issues with all those difficulties the reaction of people not knowing “SAS” at this level well, are proclaiming to forbid use of personal keys. The users/analysts are not allowed to login at the OS and “SAS” should solve all the original requirements.
Marvelous to see instructions popping up that users analysts should directly login to the OS in some cases and expecting analysts to process data (flat files) to be placed there. Seeing all the cautions being mentioned about power users (Eguide) in Sas documentation. I have even experienced some design failures in metadata security concepts.

There is a contradiction by expectations, misunderstandings and lacking knowledge and failing consulting and explaining. Instead of granting some technical I would prefer to have this solved.