Hi David,   Thanks for sharing this. In addition to your 5 GEL security papers, this is another very useful best-practice post that I think many SAS administrators will benefit from. It's also something I can very much relate to for a couple of reasons:   Firstly, because you mention our Metacoda Identity Sync plug-in - thank you! 🙂   Secondly, because I have personal experience with this whilst an adminstrator of a SAS 9.1.3 platform many years ago... For some reason, on a Saturday night, AD returned no users/groups and no errors. It looked like all AD-sourced users and groups had been removed and so the sync process dutifully deleted them all from metadata. On Sunday nobody was working so nobody noticed. On that Sunday night AD then returned all the users and groups as normal. This was processed by adding everything back in as NEW users and groups in metadata. On Monday, at first glance, it looked like nothing had changed. All of the users and groups appeared to still be there but, of course, all of the carefully crafted access controls had disappeared! This event is partly the source of my preference for 1) Tag-Deletion instead of actual deletion, and 2) a history of audit reports for every sync operation (both of which are also features in our Identity Sync plug-in).   In Tag Deletion, we intercept the user and group deletes and turn them into updates instead: by adding a prefix in front of the display name, removing group and role memberships and removing logins. An administrator can review the tag-deleted identities from time to time and then explicitly delete them if appropriate. The benefit of tag-deletes are they are automatically reversed when the users and groups are synced again (as would have happened in the story above) and crucially, because the users and groups are not deleted, their metadata relationships with things like access controls are never lost.   Before following the tag-deletion method I did try the shadow groups method but was never entirely comfortable with it. It potentially doubled the number of groups in metadata. It added a manual burden in terms of creating shadow groups for the dynamic groups, which syncronization was intended to alleviate (this may not be much of an issue if there are a small number of groups with low frequency of changes). It also made the identity hierarchies for users more complex than necessary. It was this uncomfortableness that led me to settle on tag-deletion as my preferred option.   Some other areas where the automatic removal of dynamic groups (and dynamic users) can cause problems include: The automatic removal of explicit permissions (ACEs). Whilst a good security implementation will limit the use of ACEs, they are still used automatically/necessarily in several key areas including: Portal permission trees. Private user folders. Permission conditions in OLAP cubes for member-level security. Permission conditions in Information Maps for row-level security. Permission conditions in LASR Tables for row-level security. The automatic removal of dynamic users/groups as members of roles. The loss of the association of dynamic users with their old private user folders and the automatic creation of new ones. I hope these anecdotes are also of use to the community.   Cheers Paul ... View more

Thanks for sharing this Erwan. I've only just started with Ansible, after being introduced to it via a SAS Viya install, so am keen to see your follow up posts with more examples.   Cheers Paul ... View more

What you have done sounds about right for ensuring appropriate metadata permissions but you will also need to consider file system permissions too, being aware of the difference between creating physical tables (SAS datasets) in the physical directory in the file system and (optionally) registering those tables in metadata folders. You can create physical tables without registering the tables in metadata (and vice-versa). You might also want to submit a "libname _all_ list;" in EG to see how all of the libraries have been assigned and what engines are being used.   You wont be able to create tables in a MLE library uless you use one of the metaout options that supports it.   As you have found, this is quite a complex area with all of the various considerations. I would suggest one of the best ways to get a handle on this is to attend the SAS Platform Administration Fast Track course which covers many of these concepts.     As has been suggested by others, the 2 main options that admins use to control access to metadata and physical layers is to align metadata and file system access controls or use metadata bound libraries (to enforce the use of the metadata authorization layer). ... View more

... and don't forget that table objects in metadata inherit permissions from the metadata folder in which they are contained and not the metadata library in which they are registered. For consistency you can assign permissions to a metadata folder containing both the library and the tables. Also keep in mind metadata security recommended practices and assign permissions, ideally via ACTs, on the folder, for groups (not users), only denying permissions broadly (to PUBLIC or SASUSERS) and then granting back to appropriate groups.   You will also want to consider how the library is being assigned: which engine: native or Metadata Libname Engine (MLE), and where necessary the MLE metaout value, and the AssignMode extended attribute value. ... View more

When you say it is working fine, do you just mean you are able to log in to SAS Management Console as sastrust@saspw? Have you verified that all of the SAS mid-tier applications are working too? I ask because if you didn't use SAS Deployment Manager to change the password (and propogate the change out to those components that use it) then it is unlikely that the entire platform will be working corrrectly (unless the new password is the same as the old one). ... View more

Also consider that if you change the password for the SAS Trusted User using SAS Management Console, without changing all the instances of it's use using SAS Deployment Manager (as Juan suggested), the account is probably going to get locked again as the SAS platform services that use the old sastrust@saspw password continue to provide a now-invalid password to the SAS Metadata Server.  ... View more

Whilst this question is several years old now, I stumbled on it while investigating slow performance when using the SAS JDBC driver for lots of updates. For the benefit of others who may find this thread in future, I'll add my own findings too. Like the original poster I found that using JDBC batch didn't help much. In my case I found it was significantly faster to handle my own batching and spawn a workspace server session to submit proc sql code to do a batch of inserts/updates instead. ... View more