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.
If you use conditional grants in SAS® Visual Analytics for row level security, then you might be interested in one of the enhancements available in our recent Metacoda Plug-ins 5.0 release. This new release adds support for automated metadata security testing of the permission conditions behind conditional grants. Conditional grants, sometimes known as row-level permissions or row-level security, allow you to grant limited access to a subset of data based on an expression. If someone is in a constrained group then they only get to see the rows where the expression evaluates to true.
If you’re using conditional grants to restrict certain groups of users to specific subsets of data then you’d probably be keenly interested in making sure those conditional grants remain in place. You wouldn’t want to discover at some future time that, due to unexpected changes in the permission conditions, those groups of users have been getting much broader access to data than should have been allowed.
I’ve been spending lots of time lately on SAS® platform identity synchronizations. I’m fairly confident that I’ve done more Microsoft Active Directory (AD) to SAS Metadata Server synchronizations in the past few weeks, than I’ve done in my entire career working with SAS software! :) The reason for this is that we’ve been doing lots of testing and demos for a new Metacoda Identity Sync Plug-in we’ve built that makes it easier for people to get started synchronizing identities with SAS metadata. With all these tests and demos, the SAS metadata backup and restore facility has also been an invaluable feature for allowing us to easily rewind and repeat the process – I’ve done my fair share of backup/restores these past few weeks too :)
The idea for the Metacoda Identity Sync Plug-in came after years of writing and customizing SAS programs using the standard SAS User Import Macros (%MDU macros). I found I had built up a set of common practices I would choose from depending on the customers requirements: things like name/display-name prefixing/suffixing; tagging for deletion instead of deleting outright; login manipulation; audit reporting etc. This plug-in is a way of packaging those practices up, as configurable options, with both a point-and-click and a batch interface. The outcome is an ability to rapidly implement identity synchronization, for a new or existing SAS platform installation, in a matter of minutes (rather than hours or days of writing code).
It has been a very rewarding experience building this new plug-in, and the feedback we’ve had so far has been very positive. Some of the interesting challenges along the way included:
Making it easy to get started, but also flexible enough to handle some of the more specific requirements we see with our customers. The point and click interface includes the common options, but we also added support for customers to tweak things by dropping their own SAS code in at key points in the process too.
Letting people interactively visualize and review the changes before they are made, adding and removing exceptions as required, and building a configuration that can be used in batch processes too.
Working within AD resource limits whilst extracting reasonably large subsets of identities for synchronization with SAS. Some of our tests included pulling out many thousands of users (40K+), including groups that contained several thousand users each.
Providing support for encrypted connections to AD via LDAPS, or LDAP with STARTTLS.
Generating audit reports of the process, so you can track what changes occurred when, and with all of the information that led to those changes.
Writing our first commercial plug-in that updates metadata (all our other commercial plug-ins to-date have been read-only). In this plug-in we have opted to only update metadata via the standard, unmodified, well known and trusted SAS %MDU macros. Whilst we have lot of experience with the SAS metadata model, we decided to give our customers a gentle introduction to Metacoda driven metadata updates.
If you’d like to see the Metacoda Identity Sync Plug-in in action, here’s a short 10 minute screencast. I show the initial configuration, building an Identity Sync Profile, and a small initial load of AD users, driven by the selection of an initial set of AD groups. That saved profile can then be re-used for further interactive synchronizations (adding, updating and deleting identities as appropriate), as well as being used to drive regular batch synchronizations (topics for future screencasts perhaps?).
We’ve been getting some great feedback from the people we have shown so far, so I hope you’ve found this video interesting too. If you’d like to find out more about this new plug-in, or any of our other Metacoda Plug-ins, please contact me, or visit the metacoda.com web site. We’re still taking on beta testers for the the upcoming Metacoda Plug-ins 5.0 release too.
SAS® 9.4 M2 was released recently and included some new permissions related to identity administration. These new permissions are ManageMemberMetadata (MMM), for groups and roles, and ManageCredentialsMetadata (MCM), for users and groups. I found them documented in the SAS 9.4 Intelligence Platform: Security Administration Guide, Second Edition. They are listed in the Use and Enforcement of Each Permission section as follows:
ManageMemberMetadata (MMM): Change the membership of the Group and Role. Cannot change security or other account attributes. ManageCredentialsMetadata (MCM): Manage accounts and trusted logins of User and Group. Cannot change security or other account attributes.
Identity: User administration capabilities (from the Metadata Server: User Administration role) enable you to create, update, and delete users, groups, and roles. You can delegate management of an identity to someone who doesn’t have user administration capabilities by adding explicit or ACT grants of WriteMetadata permission in the identity’s authorization properties. An identity’s authorization properties have no effect on what that identity can do. You need ManageMemberMetadata permission to change the membership of the UserGroup and Role. ManageCredentialsMetadata enables you to manage accounts and trusted logins of User and UserGroup.
After some further exploration, I also saw that (unless otherwise specified) MMM and MCM follow the WriteMetadata (WM) permission on identities, just as WriteMemberMetadata (WMM) does with folders.
To provide support for these new permissions, Metacoda has just released an updated version of Metacoda Plug-ins 4.0 R2.
You can now see MMM and MCM in the Public Types Explorer:
The new permissions are also visible in the various Metacoda Reviewers and Permissions Explorers. If you are using the Metadata Security Testing Framework, you can now export tests that include MMM and MCM, and run tests that check for them too.
I’d encourage all existing users of Metacoda Plug-ins to upgrade to 4.0 R2. This latest release can be downloaded after logging in from the Metacoda support page. If you’re not yet a Metacoda Plug-ins user then you might be interested in a free one month evaluation license where you can try them out in your own environment.