PaulHomes Tracker

Re: Metadata Migration Preserve Permissiosn

PaulHomes — Sat, 18 Jan 2025 02:04:32 GMT

In a manual migration, when you import the metadata package (.spk file), you get a choice as to whether you want to include/import access controls or not. The access controls are always exported in the spk file but you get to choose whether you want to import them or not.

Although there may not be any manually added access controls on the content in your user folders there will be some access controls added automatically by SAS when the user folder was created. You will see an ACT (Private User Folder ACT) and a set of explicit permissions on each users "My Folder" and "Application Data" folders. This sample screenshot of the Metacoda Permissions Tracer shows them and their impact on a users My Folder:

It is these automatically added access controls which prevent users from seeing inside each others user folders but allows them to add content to their own. You will most likely want to retain that setup in the new environment by importing the access controls. Alternatively if you get each user to login into the new environment so that SAS automatically creates and secures the user folders then you can import the user folder contents later without access controls and let permission inheritance do its work.

Thanks @Nigel_Pain for mentioning our plug-ins. As mentioned, you might find these useful to review and/or test the metadata security implementation in your old and new environments. If you want to try them out you can register to get a free 30 day evaluation license at https://www.metacoda.com/en/evaluation/

Re: Question on Metadata Server Backup Schedule

PaulHomes — Sat, 28 Sep 2024 21:52:01 GMT

Most daily metadata backups (without reorganization) have no downtime. Metadata backups with reorganization involve the metadata server going offline for a short time to do the reorganization work (purging logically deleted metadata objects that are taking up storage space). Because reorganization means some unavailability it is scheduled by default for Monday 1am (or overnight Sunday if you look at it another way) when the likelihood of anybody being affected is lower.

You can find out more in the documentation section "About the SAS Metadata Server Backup and Recovery Facility" and subsection "About the Reorganize Repositories Backup Option" at https://go.documentation.sas.com/doc/en/bicdc/9.4/bisag/p16vd44w7smqlsn1a4eygd88gm6f.htm#n0pgxrqfbt5kr1n1audbuwgkq0w5 It includes the caution "The Reorganize Repositories option should be used only during times of little or no user activity. The metadata server is paused during the reorganization process, and any update transactions that are issued during this process will fail." and the note "The Reorganize Repositories option is ignored if it is used on a metadata server that has been started with clustering."

Re: Metadata and ObjectSpawner log record headers ?

PaulHomes — Wed, 18 Sep 2024 23:12:26 GMT

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:

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.

Re: List of all metadata users and the libnames that each one has access to

PaulHomes — Wed, 07 Aug 2024 22:48:16 GMT

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.

Re: Read only Permission to Redshift table via SAS DI studio

PaulHomes — Mon, 27 May 2024 03:38:00 GMT

@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

Re: Read only Permission to Redshift table via SAS DI studio

PaulHomes — Mon, 27 May 2024 03:29:11 GMT

@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.

Re: Read only Permission to Redshift table via SAS DI studio

PaulHomes — Mon, 27 May 2024 02:06:49 GMT

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.

Re: Tools option unavailable in SMC

PaulHomes — Thu, 18 Apr 2024 05:40:39 GMT

As @SASKiwi suggests access to plug-ins and menu items in SAS Management Console is controlled by roles and their associated capabilities. The SAS Administrators group is by default a member of the Management Console: Advanced role which gives them all capabilities in SAS Management Console including the catch-all Access Unregistered Plug-ins capability (which can include menu items in the Tools menu). There is also a Management Console: Content Management role, which has the SASUSERS implicit group as a default member, which does not grant access to Access Unregistered Plug-ins capability. Someone who is not a member of the SAS Administrators group (in the absence of any other relevant role memberships) would not get access to the Access Unregistered Plug-ins capability and so not see the Tools menu.

If you want to avoid having to trace role and group memberships (and any nested/implicit memberships) to find out what capabilities a user has access to, you can register for a trial of Metacoda Plug-ins (https://www.metacoda.com/en/metacoda-plug-ins/) and view a users capabilities in the User Reviewer plug-in like so:

Roles and capabilities can be used to limit access to installed plug-ins, but another possible reason for a plug-ins being missing from the user interface is that it is not installed. If tracing roles and capabilities does not explain a missing feature then you may also want to check the SAS Management Console installation on the workstations of someone who does have access and someone who doesn't. It may be that a plug-in JAR file or picklist is missing. Compare the directories C:\Program Files\SASHome\SASManagementConsole\9.4\plug-ins

I hope this helps.

Re: SAS 94 Management Console - Cant add Login. Userid already in use by another user or group

PaulHomes — Thu, 14 Mar 2024 06:28:09 GMT

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

Re: Active Directory authentication in SAS EBI/SAS VA

PaulHomes — Sat, 27 Jan 2024 04:48:36 GMT

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

Re: Install both 9.4 M5 and M8 Management console on same client device

PaulHomes — Sun, 27 Aug 2023 06:32:10 GMT

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/

Re: Install both 9.4 M5 and M8 Management console on same client device

PaulHomes — Sat, 26 Aug 2023 00:43:57 GMT

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

Re: 9.4 ACT Not Applying Correctly

PaulHomes — Sun, 16 Jul 2023 22:17:37 GMT

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.

Re: How to find the JRE version of the SAS on linux servers?

PaulHomes — Tue, 16 May 2023 00:01:02 GMT

... and if you are on a server that has SAS software installed but not SAS Foundation you can also use the java -version command. The path will vary depending on where SAS software has been installed but on my server I can check it like so:

[sas@sas94m8 ~]$ /opt/sas94m8/sashome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/java -version
openjdk version "11.0.15" 2022-04-19 LTS
OpenJDK Runtime Environment Zulu11.56+20-SA (build 11.0.15+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.56+20-SA (build 11.0.15+10-LTS, mixed mode)

Re: SAS EXTERNAL ACCOUNTS

PaulHomes — Sat, 06 May 2023 21:08:32 GMT

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.

Re: SAS EXTERNAL ACCOUNTS

PaulHomes — Fri, 05 May 2023 22:53:11 GMT

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.

Re: User Libraries

PaulHomes — Mon, 27 Mar 2023 03:29:57 GMT

If you would like a fast point-and-click way of finding out who has access to a library, and are open to the use of 3rd party commercial software, then you might want to try our Metacoda Permissions Explorers. There is an example of the use of the Object Permissions Explorer, to see who has access to a library, in this blog post https://platformadmin.com/blogs/paul/2012/04/effective-permissions-explorers-sneak-peek/ If you also want to find out why people have the access they do then the Metacoda Permissions Tracer plug-in can show you which access controls are driving the effective permissions that you see in the Permissions Explorers. There is a blog post about the Permissions Tracer here https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/

Re: Issue while removing a certain group from Library 'Authorization' Tab and Folder having it

PaulHomes — Tue, 28 Feb 2023 10:35:41 GMT

Hi,

The 2nd screenshot is telling you that you cannot remove the group from the list because it appears from either a parent object in the inheritance path or via an applied ACT. You cannot remove the group here but you can change it's permissions (if appropriate). If you really want to remove the group from the list then it needs to be removed from the auth tab on a parent object or the permission pattern of an applied ACT (but that could have a very big impact).

The 1st screenshot I suspect is because you are denying permissions to non-implicit groups (i.e. not PUBLIC or SASUSERS) and it results in a conflict where you yourself would no longer have the ability to see the object. A best practice is to only ever deny permissions to PUBLIC or SASUSERS and then grant back to the groups that require access. See rule #3 in https://support.sas.com/resources/papers/proceedings11/376-2011.pdf. You may also want to have a look at the GEL Golden Rules at https://communities.sas.com/t5/SAS-Communities-Library/Golden-Rules-for-Security-Model-Design/ta-p/373542

I hope this helps.

Cheers

Paul

Re: How to extract SAS Management console information (SASApp - Workspace Server) in a dataset/file?

PaulHomes — Thu, 09 Feb 2023 00:22:29 GMT

It's great to hear you have it all working now. Thanks for reporting back and marking it as solved.

Re: SAS 9.4 M8 is now available!!

PaulHomes — Fri, 03 Feb 2023 11:52:47 GMT

I did an install of SAS 9.4 M8 and it did include SAS Web Report Studio. I was also able to use proc pwencode with methods sas003, sas004, and sas005.