If you look in the SAS servers logconfig.xml file e.g. /opt/sas94m8/config/Lev1/SASMeta/MetadataServer/logconfig.xml you will see a ConversionPattern line like follows:   <param name="ConversionPattern" value="%d %-5p [%t] (%c) %X{Client.ID}:%u - %m"/>   The item you are asking about is %t which is documented in the SAS 9.4 Logging: Configuration and Programming Reference, t Conversion Character section at https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/logug/n1p9fotibfkw4en11pdrjiu32a84.htm as "the identifier of the thread that generated the log event." I don't consider the value itself to be meaningful but that log lines with the same thread id come from the same process/thread. ... View more

Thanks @AhmedAl_Attar and @carl_sommer for mentioning Metacoda!   @Maicfel - we have some commercial Metacoda Plug-ins that can be installed into SAS Management Console to provide additional views of the SAS metadata security implementation that SAS platform administrators find useful. Of the various plug-ins that we provide, the ones that might provide the answer you are looking for are the Object Permissions Explorer (pick an object, like a library, and see all users/groups and the effective permissions/access they have on that object) and the Identity Permissions Explorer (pick a user/group and see a collection of objects, such as all libraries, and the effective permissions/access that user/group has on all those objects). These views can be exported into HTML and CSV formats. If you see a combination of permissions you don't expect then you can right click on a row to access the Permissions Tracer plug-in which will list all of the relevant permission settings, from ACEs and ACTs on the object and all of its parents, for that user and all of its groups, ordered in terms of precedence, with the definitive or deciding permissions highlighted so you can see what it driving the decision.   I have written a couple of blog posts about these specific plug-ins that might help: Sneak Peek at our new Effective Permissions Explorers: https://platformadmin.com/blogs/paul/2012/04/effective-permissions-explorers-sneak-peek/ Tracing Permissions for SAS Metadata Security: https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/ If this is of interest, and you would like to try the software out in your own environment you can register for an free 30 day evaluation at https://www.metacoda.com/en/evaluation/ and, of course, if you would like to have a web meeting to see a demo I would be more than happy to help. ... View more

@YNWA1 - I also forgot to mention that, being a new SAS Admin, I would recommend you avoid denying permissions to any groups other than PUBLIC or SASUSERS otherwise you can end up with conflicts that can be hard to understand and troubleshoot.  I would thoroughly recommend reading up on best practices for SAS metadata security such as https://communities.sas.com/t5/SAS-Communities-Library/Golden-Rules-for-Security-Model-Design/ta-p/373542   ... View more

@Patrick Yes, you can have 2 different logins in the same auth domain on 2 different groups and let SAS automatically pick the right one for you. There is nothing special that has to be done to secure them - you only have access to logins on your own identity or on any group within your identity hierarchy (unless you are unrestricted in which case you can see all logins but have no access to their passwords). When SAS (9.2 onwards) needs a login it will walk your identity hierarchy and find the login for the required auth domain that is closest to you in your identity hierarchy i.e. on your identity, then your direct groups memberships , then second level via nested groups etc.  I just verified this with 2 different users in 2 different groups where those groups have different logins in the same auth domain. I created a made up ODBC library for a made up ODBC data server tagged with that same auth domain. When the libname is not pre-assigned, so you can use Display Libname Statement in SAS MC Data Library Manager, those users see their correct shared logins.   When the library is pre-assigned, and used in a normally configured SAS Workspace Server, it should use the metadata identity of the launch user to find the appropriate login in the same way. I don't have a readily available SAS/Access accessible ODBC database to hand to double check this all the way through to the database itself but that is my understanding. ... View more

I think your primary issue relates to understanding how the Read/Write/Created/Delete/... metadata permissions are implemented. ReadMetadata, WriteMetadata and CheckInMetadata are used to control the ability to view and update SAS metadata for the library and Read, Write, Create and Delete can be used to control the ability to view and update the data behind the library, but only in certain circumstances. In order for Read, Write, Create and Delete to be enforced, the library has to be assigned using an engine that supports and enforces them, such as the SAS Metadata Libname Engine. You also need to consider the possibility of users attempting to bypass the use of that library engine. The simplest and most robust thing to do is to instead enforce those data level permissions in the underlying data source itself, in this case Redshift. Since you are already using 2 possible shared logins, one for read/write access and one for read-only access, I would suggest making sure those logins in Redshift only have that level of access to the data. That way the data level permissions are enforced there and in SAS metadata you just need to make sure that users only have access to one appropriate shared login. Use a single Redshift authentication domain and put the shared read/write access login on one group (Redshift Write Users) and the shared read access login on the other group (Redshift Read Only Users). Finally, ensure a user is only a member of one group or the other (either via direct or appropriate nested membership) depending on the access they should have. ... View more

Thanks for the mention @MarcoGhiglieri It's nice to hear you've found that code useful. ... View more

Hi,   If you can provide a bit more info about your environment, like host opsys, SAS versions etc, then we can provide more targeted links.   For SAS 9 authentication I would start here: SAS 9.4 Intelligence Platform Security Administration Guide, How to Facilitate Authentication and for SAS Viya 2024.01 I would start here: SAS Viya Platform Authentication and Authorization   If you search for SAS authentication you will also find a bunch of SAS blog posts on the topic such as https://blogs.sas.com/content/?s=authentication. I would recommend reading posts by Stuart Rogers https://blogs.sas.com/content/author/stuartrogers/   I have also written a few SAS and AD related posts on my blog too: https://platformadmin.com/blogs/paul/tag/active-directory/   I hope these provide a good starting point. Let us know if there is anything more specific you are looking for.   Cheers Paul ... View more

I realized you can also use Windows Subsystem for Linux (WSL2) as an alternative to using MobaXterm if you want to run SAS Management Console directly on a Linux server with the windows appearing locally on a Windows workstation.  This is one of the ways you can use different maintenance levels of SAS Management Console from a single client. I wanted to try it out for myself first and wrote up a blog post about it in case it is of interest: https://platformadmin.com/blogs/paul/2023/08/remote-sas-management-console-using-wsl2/ ... View more

As @SASKiwi mentioned I have seen many SAS customers use mismatched server/client maintenance releases. They usually click through the warning and, as far as I am aware, have not run into any issues. I personally don't like doing it and prefer to ensure they are matched.   There are a few ways I have used to achieve this in the past:   1) The SAS servers will have the matching SAS Management Console versions installed on them so you could use remote access (RDP for Windows servers and X11 for Linux Servers e.g. MobaXterm) and not bother installing SAS MC on the workstation at all. I have seen several SAS customers use this approach too.   2) It's a heavyweight approach but you could use Virtual Machines (local or remote) and have a different VM (or snapshots) with the SAS clients for each maintenance release you have to support.   3) A hacky method I have used in the past when testing on different versions of SAS MC was, before installing a new maintenance level, make a copy of the SASManagementConsole directory (e.g. SASManagementConsole94M5) then edit the config files and shortcuts to refer to this new copy and then install the latest maintenance allowing it to overwrite the original directory. sasmc.ini will need changes and it also refers to sassw.config so you will need a copy of that too. You may need a copy of the VJR too if the old version jars are no longer present. I don't use this method any more and so am not sure how it would go with the larger changes in M8 with Java 11.   Since #3 would not be a supported method anyway, I would recommend #2 if you want to run them side by side on a workstation or #1 for the least amount of effort - bearing in mind SAS MC via X11 over SSH is not always the nicest/fastest of interfaces.   I hope this helps.   Cheers Paul ... View more

I suspect the issue you are encountering is that you are using the SAS BASE engine to access data which ignores the R,W,C,D metadata permissions. Also whether the ReadMetadata permission is considered depends on how the SAS library is being assigned.   To enforce metadata "data" permissions you need to add a layer on top such as the SAS Metadata Libname Engine (see Metadata LIBNAME Engine https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/lrmeta/part-3.htm) or SAS Metadata Bound Libraries (see SAS 9.4 Guide to Metadata-Bound Libraries https://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm#seclibagwhatsnew94.htm).   Controlling access to data through SAS metadata can be complicated and I think this is in part because with SAS 9 they had to walk a fine line between providing access via metadata but also maintaining backward compatibility for decades of legacy code that was written before the SAS Metadata Server existed. A SAS administrator can try to control access through the metadata authorization layer but needs to be aware that those access controls only work in some scenarios and that savvy coders can try to bypass them using traditional techniques with SAS libname statements. There are a variety of ways to try and prevent this but, as @SASKiwi mentions, it comes with complexity and maintenance overheads. Deciding on which technique to use also depends on to what extent are you trying to secure access to data: are you doing it for convenience or user experience where you want to limit access by default but are not concerned if some knowledgeable people can bypass it?; or are you doing it for security where you don't want anyone to be able to bypass it? For the former I would suggest the Metadata Libname Engine and for the latter I would recommend SAS Metadata Bound Libraries.   Of course another technique is to use a SAS/ACCESS engine and house the data in a 3rd party database which has it own authorization layer. ... View more

I can't say I have ever tried the install with them as the same external account, so cannot say whether it would cause any installation errors. I would recommend against it regardless, as the work to undo it after installation would be more effort than creating an extra account in the first place. ... View more

As @gwootton says they should be different accounts. To add some security context, the SAS installer account (e.g. sas) is the owner of the installed software and deployments and can therefore make changes to them. The SAS Spawned Servers account (e.g. sassrv) is the process owner for spawned processes for shared services like the SAS Stored Process Server and SAS Pooled Workspace Server. If one were to use the same account for sas and sassrv then you have the possibility that an unprivileged user could author a stored process which when executed could make changes to the installed SAS software, configuration files and running SAS server processes. For example, among many other things, they could write a stored process to make themselves a unrestricted user by writing to the adminUsers.txt file (owned by the SAS Installer) and restarting the SAS Metadata Server. ... View more