This is just a very quick post to jot down the location of a SAS reference that I keep losing! I have the SAS Audit, Performance and Measurement (APM) package installed in my older SAS 9.4 M0 dev/test environment. The APM package is now deprecated as the functionality has moved into SAS Environment Manager (from 2.4). One of the effects of having APM installed is that my SAS Workspace Server logs have a huge number of lines that look like this:
Sometime I want to suppress those lines (without uninstalling SAS APM). I then remember there’s a SAS page that contains instructions on how to do it, and spend several minutes trying to find it. I keep looking for a SAS Usage Note, but instead it’s a gem at the end of the SAS APM FAQ page: “Why do the Enterprise Guide SAS logs contain messages related to MVA_DSIO.OPEN_CLOSE and _DISARM? How can these messages be eliminated from the SAS log for EG users?”.
Essentially you edit the workspace server’s logconfig.apm.xml and change the Threshold of the WSLogAppender to Error.
You’ll want to pay attention to the note in the FAQ that says it will disable the SAS DI Studio Job Statistics features. I don’t use that feature in this environment, but you might!
If you’re interested in extending SAS Enterprise Guide to create useful tools for SAS EG users in your organization then you won’t want to miss the opportunity to attend this course. It is written and delivered by the guy that literally wrote the book on SAS EG custom tasks after all!
SAS Global Forum 2016 is just over 2 weeks away, and I’m really excited about showing a Permissions Tracer feature we’ll be releasing in the next version of our Metacoda Security Plug-ins. Metacoda is a SASGF sponsor again this year and we’ll be showing a preview of this new version at our Metacoda stand in The Quad, so please stop and say hello if you’re going to be there too.
We’ve had some very positive feedback about how helpful our Identity and Object Permissions Explorers have been, so I’m looking forward to getting some feedback on this new feature too. One of the other reasons I’m excited is that this is something we’ve been building up to for several years as we’ve expanded our code base to help visualize the richness of the SAS metadata security model, including its interacting object inheritance paths, user identity hierarchies, and role-implied special conditions.
Using the Metacoda Identity Sync Plug-in with a new SAS installation is easy. All of the defaults are based on common practices for synchronizing Active Directory users and groups with a SAS metadata server. Using the plug-in with an existing installation, where users and groups have already been synchronized using custom code, takes a little more planning. One of the ‘key’ things to do is to configure the plug-in to use the same external identity key id attribute that was used in the custom code. If you have the custom code, you can find the prior key choice in that code. This post is about helping you find and recognize those external identity keys without necessarily having to study the code.
An external identity key is a unique identifier for a user or group in an external identity source (e.g. Active Directory). It connects users within SAS metadata to the equivalent external user, so changes to the external user (including name changes) can be applied to the SAS user at some later date/time. In choosing a key from the external source, it is best to choose one that will stay constant over time, even after user name changes, directory reorganisation etc. There are a few different key choices available, and some are more likely to remain constant over time than others. Later in this post I will show examples of some common external identity key id attributes. The key that is chosen for groups doesn’t have to be the same as the one chosen for users either. I often see sAMAccountName being used for users and distinguishedName being used for groups. At Metacoda we recommend using objectGUID for both users and groups (as explained below). Once a Key Id Attribute has been chosen it is important to continue to use the same one over time. Switching the key choice after it has already been used for a synchronization is not an easy thing to do, so it is good to carefully consider the initial choice before deciding to synchronize users and groups. Of course, sometimes you inherit the process and have no choice in the matter.
When switching from one synchronization process to another, such as custom code to the Metacoda Identity Sync plug-in, it is important to continue to use the same key choice as before. If the key choices are different you might see something like this in the Identity Sync Plug-in, where every user or group looks like it will be (tag) deleted and re-added, and there are associated validation errors that prevent the sync from proceeding.
In the recent Metacoda Plug-ins 5.0 R5 release there have been a few enhancements to make it easier to sync with multiple domains (and avoid using custom code hooks):
Members of “Included Groups” are followed into other domains within the same forest.
You can opt to prefix the SAS User and Group names with the NetBIOS domain name. You might choose to do this if you have any users or groups in different domains with the same sAMAccountName and want to avoid non-unique user/group name validation errors when they get to the SAS platform.
There are more user login options available to help appropriately qualify the inbound login for the SAS user using the domain of the Active Directory user.