SAS Metadata – Page 4 – platformadmin.com

Tracing Permissions for SAS Metadata Security

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.

So what business problems does the Permissions Tracer solve? It expands on Continue reading “Tracing Permissions for SAS Metadata Security”

Identity Sync: Finding Your Keys

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 screenshot above, Continue reading “Identity Sync: Finding Your Keys”

Identity Sync: Multiple Active Directory Domains (Single Forest)

Recently I’ve been working on using the Metacoda Identity Sync Plug-in to synchronize SAS platform identities (users and groups) with their counterparts from multiple Microsoft Active Directory (AD) Domains contained within a single Forest. In a future post I’ll talk about extending this to multiple domains from multiple trusted forests.

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.

I’ll show a relatively simple example. This might help other people who need to sync SAS users from multiple AD domains. The diagram below summarizes the Active Directory deployment: Continue reading “Identity Sync: Multiple Active Directory Domains (Single Forest)”

Protecting your Metadata Protections: Part 2

In a guest post on blogs.sas.com in January, I wrote about protecting your metadata protections. In that post I said that “Ideally, a SAS® metadata security plan should address both ACT permissions and access to the Authorization Manager.” and went on to explain a method for addressing Access Control Template (ACT) permissions.

In this second part, I’ll talk about reducing access to the SAS Management Console Authorization Manager plug-in as further protection for your ACTs.

Of course, for some smaller SAS sites, and those with simple security requirements, this might be overkill. However, for other possibly larger organizations, those with potentially sensitive data/content, and perhaps those with specific regulatory requirements, it might be a necessity to implement a comprehensive metadata security implementation with multi-layered protections like these.

In the default metadata security implementations for SAS 9.3 and SAS 9.2, all SAS users have the capability to access a limited set of features in the SAS Management Console. This includes access to the Authorization Manager plug-in where any accidentally unprotected ACTs could be modified. In order to be able to take advantage of this capability, and modify an ACT, a user has to be able to fulfill all of the following requirements: Continue reading “Protecting your Metadata Protections: Part 2”

SAS Stored Process Code in Metadata

With SAS® 9.3 the SAS code for a Stored Process can be located in metadata rather than located the file system (as was required with earlier versions). I had often wondered whether this meant the SAS code was really in metadata or whether it appeared to be in metadata but was really kept in the SAS Content Server (as is done with SAS Web Report Studio report definition .srx XML files). I don’t like not knowing the answers to questions, even ones I ask myself, so today I went looking for an answer. Continue reading “SAS Stored Process Code in Metadata”