About ronan

ronan · ‎06-04-2015

If you follow this link, you'll find a previous thread which dealt with this question somehow : Some context : the internal security provider inside the SAS Metadata (MD) Server is called "@saspw" Authentication Domain. Logins with @saspw suffix have their corresponding passwords stored in the SAS metadata repository. So that users with internal accounts authenticate 'against' the SAS MD Server. https://support.sas.com/documentation/cdl/en/evug/67886/HTML/default/viewer.htm#n1hqkzr5rsoxgln114bntk81fpgx.htm#p1bhl79nwpfzj3n14ibklr66s6ja SAS has taken a different approach than BO : user management identity & credentials are administrative tasks that usually only the Admin team can perform; It's not user-centric, rather centralized management. To carry ou thes tasks, Admins rely on the SAS Management Console (SMC) User Plug-in or also in the Web console named Environment Manager.I am not sure this will do with non-administrative users, Managing User Access :: SAS(R) Environment Manager 2.4: User's Guide Consequently, SAS doesn't provide out of the box a tool or a set of tools with a user friendly interface (Web) that fit your need, namely that can create/update/purge SAS user account along with their internal login password. SAS provides the Open Metadata Interface (OMI) available as a JAVA API or XML/SAS language API and, depending on your offer Web capabilities to create the identy management tool (SAS Stored proces server etc.). In the above-mentioned discussion, it seemed workable to create such a tool, namely to update @saspw passwords using sas code. I am still unsure if it is supported by SAS Institute so be careful Other options to consider : 1) Reuse previously created user identity and automate synchronisation process between company Directory server (Active Directory, LDAP) and SAS MD https://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/p1ar98lajfgm4jn1wa1h6e19jjre.htm http://www.metacoda.com/en/2015/05/metacoda-identity-synchronization/ 2) create some user-centric web interface enabling the final user to enable her/his directory account in the SAS Metadata Server, using the LDAP interface provided by SAS : https://support.sas.com/resources/papers/proceedings12/377-2012.pdf Usually, the company Directory authentication provider (MS Active Directory for instance) comes with password mangement tool already set up so that once the user (external = Active Directory in this example) login has been created in the SAS MD Server, the user can open the SAS session without having to manage any extra password for SAS. This kind of tool can be further extended to copy the user's attributes (1st name, email etc) stored in the company directory into SAS MD server Personnaly, I would't recommend assigning the final user the privilege to authorize himself on the SAS Server using @SASPW accounts : too difficult to maintain. But authorizing the user in the Company Directory with a specific group (Company\SASUSER etc.) and providing a simple web identity manager that can propagate this access into SAS looks like a good solution.

ronan · ‎06-02-2015

As the Americans used to say, let's call it a day, then. I have used up all my tricks in vain, now I can show you where I got my inspiration :smileymischief: (not from the SAS Doc !) : SCHOPENHAUER'S 38 STRATAGEMS, OR 38 WAYS TO WIN AN ARGUMENT

ronan · ‎06-01-2015

Jaap Karman wrote: @Ronan, the FDA Approval for using R is requiring fine grained controls at the OS-level and they are possible. Could you, please, elaborate .How do you finely control 'system commands' at shell level ? OS-level is too broad to be meaningful in my opinion; for instance, fine-grain permissions at filesystem level are often possible but that's not the point. Jaap Karman wrote: What is behind the problem of xcmd/noxcmd is lot of misunderstanding and lack of system-knowledge. Get your hands on the IT security-policies of your company as it must reference IES/ISO 27002:2013 (normally used financial regulator). When you found please give some details on the background why a shell should not be allowed. I have seen those and there is no reason for not allowing. That's your personal interpretation. Could you, please, tell me where in the ISO 27002 referential is it explicitly allowed to provide a remote shell acess to every user ? Compliance to an ISO standard is optional by definition in a free country so that it won't apply to every use case. And, please, once & for all , Jaap, don't try to transfer the burden of the evidence : if you argue that an ISO standard implies/dictates a shell access (why not ?) then prove it ! He who asserts must prove.

ronan · ‎06-01-2015

KurtBremser wrote: ; your system is either secure (and will withstand any stupidity done with system exits) or not; if it is not, get rid of the incompetent "admin". Oversimplified. Shell access doesn't generally allow for fine-grained controls, so that the dichotomy 'secure' / 'not secure' is baseless : interactive shell sessions are by default unsecure because - my guess - this interface was originally designed for Unix administrators and not for everyone else, untrained. For instance, ask your Unix/Linux System admin how to prevent, for instance recursive deletes (rm -R) or permissions changes (chmod -R, umask etc.) in interactive shell sessions. If he's unable to provide a practical answer for all these issues, surely, that doesn't imply he's incompetent : he cannot be held responsible for all the unprevented misuse that untrained (un-checked) users can inflict on his system. Unix/Linux command line terminals, and perhaps Windows terminals as well are not playgrounds for non admin developers so don't expect anything good if the two populations intermingle somehow.

ronan · ‎05-29-2015

Kurt gives you the correct explanation : standard installation prevents you to run 'system commands' in your remote or even sometimes local SAS session. As regards remote session running on servers, take my advice : this is for your own good, please dont'try to remove this safety net. Like Casey Smith from SAS ( see https://support.sas.com/resources/papers/proceedings12/297-2012.pdf ), I recommend every SAS admin to just say no to shell access requests ! The paper you are quoting gives you the proper workaround, albeit for Unix/Linux only: SAS code ; see page 3, (2) File Functions : You can try the sample code provided in this page : SAS Filesystem Toolbox - sasCommunity

ronan · ‎05-28-2015

It's not built-in generally. Two general requirements : 1. being able to retrieve each user's email, from the metadata repository (if, by any chance, this information is stored with the user acccount ?) or from the user authentication directory (eg MS Active Directory) using a join with user's id 2. is your SAS computing server configured with SMTP ? Then two ways I can think of to implement this kind of thing : A. write a stored process which retrieves the emails list and sends a message to the mailing list : example 36567 - E-mail last error/warning message that were generated during a SAS program B. Use the publishing framework (SMC Publishing framework plug-in). Rather old-school and a little bit cumbersome. HTH

ronan · ‎05-28-2015

yes, I also found it quite confusing & elusive. As far as I know, 'Literal' in SAS usually defines a Literal expression (quoted expression) however in this context, USER is rather used as a special language keyword.:smileyconfused:

ronan · ‎05-27-2015

Thanks a lot for sharing, I find the article very instructive. One can also define rowfile-level access at server level using the LOCKDOWN Mode's (whitelist) assigned by Restricted options based on Usernames (Windows + Unix/Linux) or User Primary Group (Unix/Linux) : https://support.sas.com/documentation/cdl/en/biasag/63854/HTML/default/viewer.htm#n23000intelplatform00srvradm.htm see page 12 : https://support.sas.com/documentation/installcenter/en/ikfdtnwx6cg/66385/PDF/default/config.pdf see page 9 : https://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf The where clause based on User Group you are showing in the particular case of the SPDS server is already available at Foundation level within the Proc SQL (it's called USER Literal) : https://support.sas.com/documentation/cdl/en/sqlproc/65065/HTML/default/p020urejdmvi7vn1t9avbvazqapu.htm#p0agzfbvntgbwdn1srzm2y3xg07g [edited 1 time]

ronan · ‎05-27-2015

Jaap Karman wrote: ... Back to the service accounts. When you have SP or PWS defined or a batch server those shared ! service accounts (outbound) are stored in "general servers" group. No not at the account definition but at the group. The bad thing is you can do a login (inbound) with those shared accounts at the group level. There can be a need for that as being the owner of the data. this relates to the uniqueness constraint stated above: a login must be unique in metadata, so that it woulnd't be possible to add the same service login to every user account as a supplementary (outbound) login; the same generic service login must be shared at group level which is a better solution (less faulty, easier to track & change, more secure). I am not sure being able to do a login in metadata using this kind of special account is a bad thing. Internal sessions in metadata are based on those connections. The distinction between inbound and outbound login is controlled by Authentication Domains, which means security scope really. A service account defined with a proper Authentication Domain won't do much harm imho. Of course, this can be very damaging in the wrong hands : just think of sharing a service account with a unrestricted Group of users; this opens the possibility of impersonating an unrestricted admin if the service account credentials are known to the bad guy.

ronan · ‎05-26-2015

It depends whether you want to synchronise every user account or some of them only, in other words does the scope of your syncho process involves a restriction list ? The %MDUCMP user import macro can take into account such exceptions list. In order to run safely the synchronisation task based on "importpw.sas", you should then procede in 3 or 4 steps : 1. backup your metadata 2. define your exceptions list, if any. This might require updating the user account 'external identity' information with the SMC (General Tab) 3. purge every user account registered in metadata - proc metadata, metadata data step or manually using SMC - excepted the above mentioned exceptions in addition to the @saspw default technical accounts ! 4. run the syncho code once, then regularly. The initialisation step no.3 should prevent any conflict with existing accounts. Now, as regards the authentication process, take care to use one source directory and only one for your users account. Having two or more competing authentication domains for your user accounts is not recommended, ACFARRER above asks a good question : you might also strongly consider isolating service accounts with a specific Auth. Domain. Have a look at this clear-cut paper by Charyn Faenza, presented at the last Global Forum,even if it adresses Windows authentication issues, it could be helpful for Unix/Linux as well : 3479 - SAS® Metadata Security 101: A Primer for SAS Administrators and Users Not Familiar with SAS https://sasglobalforum.activeevents.com/2015/connect/fileDownload/session/9CF651E6B76F88D03DC9B600BBA81366/3479_Faenza-Paper%203479-2015_Faenza.pdf

ronan · ‎05-12-2015

Good point, Andrew. I interpreted - perhaps completely off the mark - the need in terms of usage statistics with complete coverage. Launching, on a regular basis , system commands on the filesystem storing SAS tables would give the information, of course, but only part of it : that kind of reports would display the size of permanent SAS tables; let's figure out a counter-example : if, between two audits (daily, weekly, monthly ?), the user removes or shrinks any SAS table permanently stored then the corresponding information would be missing altogether. That's why it all depends on the admin's needs or expectations : the ARM API for instance, properly used, could provide extensive coverage of any SAS tables accessed , not only the SAS tables permanently stored but any version of it stored at any time and even the temporary tables used in SASWORK and deleted in the ensuing process. I know this distinction sounds a little bit like hair-splitting but, sometimes, admin experience SASWORK saturation caused by some reckless users who don't spare any space in their SAS EG session or even caused by concurrent SAS batch sessions consuming too much SASWORK put together. The complete coverage approach relates more to tracking & disk footprint measurement than simple auditing, sure. In that regard, being able to measure up the maximal footprint of a SAS session seems very useful for the admin though difficult to get. I know only of the ESM developed & sold by UK based Boemska company which gives this kind of (precious) details : https://boemskats.com/esm/ Good point also for reminding us about ALLOWXCMD. In the meanwhile, system commands can be replaced with SAS code for getting SAS tables sizes, even recursive research on large folder hierarchies : SAS Filesystem Toolbox - sasCommunity

ronan · ‎05-11-2015

Not easy to tell if you don't specify which product you are in charge of. There was a collection of reports called "SAS Audit and Performance and Measurement" to be implemented to your EBI installment ,now installed with the SAS Platform : SAS Audit, Performance and Measurement I am not sure this reporting tool included a metric about Dataset size (measured in Bytes and/or in Number of observations). Then there is the ARM logging API provided with SAS Foundation. Using this, you can enable your own logging but it requires some further coding & parameter changes : 35165 - Using restricted options to create dynamic Application Response Measurement (ARM) log files in UNIX environments https://support.sas.com/rnd/scalability/tools/arm/arm.html SAS® 9.4 Interface to Application Response Measurement (ARM) :: SAS(R) 9.4 Interface to Application Response Measurement (ARM): Reference I've become quite familiar with the ARM interface (on Windows, but this applies also broadly speaking to Unix/Linuw as well); A few guidelines : - be careful if you enable the whole set of ARM subsystems (eg ARM_ALL) : your ARM log files shall grow very quickly in size; it's better to select the minimal subsystem which gives you the so-called 'metrics' (performances measures) you need & only thoses ones - with ARM_DSIO + ARM_PROC, you could trace the SAS table size in bytes (source table and target table) - the ARM refererence documentation (see above) itself does not cover everything; in particular, not only OLAP cube requests but SAS Data set size metrics are also recorded by ARM in addition to the volume of memory (RAM) used, for instance. I had to build my own technical doc in order to understand this Another possibility if you already have SAS batch sessions logs files at your disposal : enable FULLSTIMER option and parse the log files to store the relevant information. One last trick :you can request on-the-fly at any time the largest SAS table created in your session using the TABLES dictionary view proc sql; select max(filesize) as maxsize,libname,memname from dictionary.tables where not(libname in ('SASHELP','MAPS')) group by memname, libname order by maxsize descending ; quit; But, obviously, this is of a limited usage if you are looking for the largest SAS table created/accessed during every SAS session.

ronan · ‎05-05-2015

Yes, the system/security folder hierarchy has been available since 9.3 to include new objects like ACTs, Groups, User or Roles in the Package export/import process. http://bi-notes.com/2013/11/sas-administration-migration-users-groups-roles/

ronan · ‎05-05-2015

Yes, I was curious to test quickly how the XML extraction process worked in order to use it in a batch step for updating the passwords. Then I discovered things were not so simple : SAS stored @saspw password in two components (1) Hash String / (2) Salt key. Since I am not well versed in encryption/hacking wizardry, I can't tell how difficult this would be to reproduce the process. For me, at first sight this is not a piece of cake. Back to the original question, I suggest two possible workarounds : 1) change the user authentication directory : instead of internal (@saspw) authentication, use the company (Active Directory, LDAP etc.) exernal user database; this would take some time, but it is definitely safer and easier to maintain imho. It's not a recommended practice to create a separate user Directory, distinct from the default Directory because this opens a possibilly of hacking user's credentials and (unwisely) assigns to the SAS Admin the responsibility to prevent the security breach. Authentifying against the external Directory, like Active Directory can further improve both user's experience with SAS and password security if you implement Single Sign On (if available in your organisation) 2) Change the password updating process and transfer the task to the end user with the Password Update Utility / Personal Login Manager (if still available in 9.4).

ronan · ‎05-05-2015

Sure, Kurt, but this would be a little bit like reverse-engineering at random : SAS might have re-used standard encryption techniques based on Unix (eg shadow), RSA etc. but it might have done otherwise, as well. :smileyconfused: If you have a copy of the technical specs, out of curiosity I'll be very interested to have a look . I think this is typically grey area where no one outside the Dev team should have acces.

Online Status	Offline
Date Last Visited	3 weeks ago

Re: Accelerating SAS9 to Viya Migration with Log Intelligence

Installing SAS 9.4 for Linux in WSL2

Re: Accelerating SAS9 to Viya Migration with Log Intelligence

Re: Kubernetes Storage Patterns for SASWORK – part 1

Re: Accessing SAS Content with FILENAME FILESRVC in SAS Viya

Re: Now I see you, now I don’t. How to prevent users from seeing other...

Re: Now I see you, now I don’t. How to prevent users from seeing other...

Re: SAS Viya Administration documentation PDFs

Re: Data Encoding Impacts in SAS Viya

Re: can we capture any events (or run a script) at compute pod end?

setting sas.logon.initial password in sitedefault.yaml during SAS Viya...

Introducing the SAS Container Runtime Batch Agent

Fixing Broken Hearts and Macros: A Character Variable Check

Data Factory Inventory Mastery: Optimizing Stock with Enterprise Sessi...

Building Dynamic Lineage: From Factory Floor to Viya’s Control Room

Re: SAS Viya 4 storage from Red Hat OpenShift Data Foundation

Re: SAS Bowl XXXI, SAS Support Communities

Re: SAS Bowl XXVII, CAS Actions

Re: Join our upcoming live workshop on SAS Viya 4 Administration

Re: Why is SAS Viya single instance only?

Installing SAS 9.4 for Linux in WSL2

Re: Enforce Row Level Access

Re: Enforce Row Level Access

Re: User self service interface

Re: How to create a list of files in a network folder on another machi...

Re: How to create a list of files in a network folder on another machi...

Re: How to create a list of files in a network folder on another machi...

Re: How to create a list of files in a network folder on another machi...

Re: Is there a way to send a message to EG User?

Re: Enforce Row Level Access

Re: Enforce Row Level Access

Re: Help with xml on proc metadata

Re: Help with xml on proc metadata

Re: How do I find the stats of the largest dataset created by a user?

Re: How do I find the stats of the largest dataset created by a user?

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4