SAS Management Console – Page 8

Role-Based Access to Metacoda Security Plug-ins in SAS Management Console

This post explains how to provide role-based access to Metacoda Security Plug-ins in the SAS® Management Console (versions 9.2 and 9.3).

Update 01Sep2023: The method described in this post is relevant for Metacoda Plug-ins version 5 and earlier. Metacoda Plug-ins version 6 and above, available since 2016, allow a much more flexible approach where you can control access to individual plug-ins and various other features. Metacoda customers can find more information in the documentation for the Metacoda Plug-ins Metadata Installer at https://support.metacoda.com/docs/plugins/v6.0/user-guide/tools/metadata-installer.html

Metacoda Security Plug-ins are initially only available to administrators, specifically members of the Management Console: Advanced role, of which the SAS Administrators group is a member by default. As unregistered plug-ins, Metacoda Security Plug-ins are controlled by the Access Unregistered Plug-ins capability which is only granted (by default) to the Management Console: Advanced role.

At Metacoda, we sometimes get asked about the possibility of providing wider access to Metacoda Security Plug-ins, for users that need/want to review and/or troubleshoot security metadata, but who are not members of the SAS Administrators group and/or the Management Console: Advanced role.

One possible option would be to modify the Management Console: Content Management role, of which SASUSERS is a member (by default) and grant the Access Unregistered Plug-ins capability. Whilst this works, it is not a recommended approach. It involves modifying the capability set for a SAS predefined role. The SASUSERS membership also means anyone with access to the SAS platform and SAS Management Console will get access to the plug-ins which is probably much wider access than is required.

These are the recommended steps to follow to provide limited, non-administrator, access to Metacoda Security Plug-ins in the SAS Management Console.

1. Choose/create Group(s) for Role-Based Access to Metacoda Security Plug-ins

The first step is to identify which groups of users need access to Metacoda Security Plug-ins. You might already have suitable groups you can use. If not then create a new group (or groups) and assign users (or nested groups) as appropriate. In this example we have a Metacoda Plug-ins Users group that contains a few individual users, including the SAS Demo User for testing purposes.

2. Enabled Role-Based Access to Metacoda Security Plug-ins

Whilst logged into SAS Management Console as an administrator, select Plug-in Manager from the Tools menu to access the Plug-in Manager dialog.

Locate Metacoda in the list of plug-ins, tick the check box to enable role-based access, and click the OK button to save the changes.

3. Create a New Role for Metacoda Security Plug-ins

Now that we’ve enabled role-based access to Metacoda Security Plug-ins, we can create a new custom role to provide access to the capability for the target users.

From the SAS Management Console User Manager plug-in, create a new role using the menu sequence Actions > New > Role. In the General tab, provide an appropriate name and description for your installation, as shown in the screenshot below.

4. Assign Capabilities to the New Metacoda Security Plug-ins Role

In the Capabilities tab for the new custom role, expand the Management Console application group and then the Plug-ins folder to locate the new Metacoda capability. Tick the check box to grant the Metacoda capability to this new custom role as shown here.

If necessary you could also grant additional capabilities for this role.

5. Assign Members to the New Metacoda Security Plug-ins Role

With the capability granted, all that remains is to use the Members tab to assign users and/or groups to the role to provide them with access to the capability. In the screenshot below I have added the Metacoda Plug-ins Users group I identified in step 1. You could also add individual users here but I prefer to use groups in role memberships and manage user access through group memberships instead.

Now the new custom role is ready, click the OK button to save the changes.

6. Test the New Metacoda Security Plug-ins Role

You can test this new role by asking one of the target users to log-in to SAS Management Console and verify Metacoda Security Plug-ins are now available to them. Alternatively, as an administrator, you could use impersonation techniques to log-in as one of the target users and verify this for yourself.

In the screenshot below you can see the SAS Demo User has limited access to just Metacoda Security Plug-ins and the standard SAS Management Console Authorization Manager, Data Library Manager and User Manager plug-ins, but none of the other plug-ins (such as Server Manager). Access to Metacoda Security Plug-ins has been provided via the new custom role. Access to the other plug-ins is provided via the predefined Management Console: Content Management role in its default state.

Final Thoughts

Whilst it’s easy to provide limited non-administrator access to Metacoda Security Plug-ins where required, bear in mind that those users may only be seeing part of the picture. Metacoda Security Plug-ins do not attempt to bypass metadata security, so users can only review security metadata on objects they would ordinarily be able to see (where they have an effective grant of the ReadMetadata permission). Since they are not unrestricted users and not user administrators, they will also only be able to see their own logins and logins for any groups they are a member of. If any folders or objects in metadata have been hidden from those users (with an effective denial of ReadMetada) then they won’t be able to review the security metadata for those folders and objects. If there is a requirement for those users to review security metadata for content they would not ordinarily be able to see, it is best handled by getting an administrator to export HTML reports from Metacoda Security Plug-ins and publish them in an area accessible to those users.

These instructions show how to provide role-based access to all of the features in Metacoda Security Plug-ins through a single capability. Depending on your role memberships you can either access none of the features or all of the features. If there is a need for it, in a future version, we can register the individual reviewers, and even the tabs within those reviewers, as specific individual capabilities to allow for much finer role-based access. If this is something that is important to you then please let me know.

Login Reviewer: Finding Accounts with Stored Passwords

In a previous post I mentioned how the Accounts tab in SAS® Management Console 9.3 now displays a blank in the password field when logins don’t have a stored password, and only displays ******** when there is a stored password. Compare this to SAS 9.2 where it always displays ******** regardless of whether there’s a stored password or not.

This is a great enhancement in SAS 9.3 because it allows us to know whether a password is stored in metadata or not. Sometimes it’s necessary to store passwords in metadata, but we generally try to minimize this. Passwords stored in metadata might be wrong and can get stale when password changes are enforced.

So now thanks to SAS 9.3 we can spot stored passwords when looking at individual users and groups. At Metacoda, we also wanted to be able to see, in one view, all logins that have stored passwords, across all users and groups, and in all repositories. This would show us how prevalent stored passwords are and which users and groups have them.

We’ve just enhanced the Login Reviewer for the next version of our Metacoda Security Plug-ins software to add a Password indicator column. Here’s a screenshot of this Password indicator column shown in SAS Management Console 9.3. I’ve sorted the Password indicator column to group together all the logins with and without stored passwords.

You might notice that one of the logins above is for a group found in a custom repository. I don’t recommend this approach, it’s just there for testing purposes. When I’m reviewing security metadata, I definitely want to know if there are things like this tucked away in custom repositories :)

Finally, for completeness, here’s another similar screenshot of the Login Reviewer’s Password indicator column, but this time in SAS Management Console 9.2. With SAS 9.2, when logged in as an unrestricted user, we can’t tell if there are stored passwords or not. This is why the screenshot below shows the column full of ‘Unknown‘ values. With SAS 9.2 we can only show Yes/No values when logged in as a normal user (in which case they will only get to see their own logins and any logins for groups they are a member of).

If you’d like to try this out, along with the other enhancements we’ve got planned for our next Metacoda Security Plug-ins version, then please let me know. We’re keen to talk to anyone who’d like to try out the beta when it’s available.

SAS Management Console 9.3 Password Indication

You’ve probably encountered this issue too. As an administrator you just want to know whether someone has stored a password in metadata or not. You don’t want to know the actual password, just whether there’s one there or not, because if there’s no password it can’t be wrong, whereas if there is a password it might be wrong / outdated.

In SAS® Management Console 9.2 the User Manager plug-in always displayed ******** in the password column on the accounts tab for a user (or group) whether there was a password there or not. A small, but very nice, enhancement in SAS Management Console 9.3 means that it now displays a blank when there’s no stored password and ******** only when there is a stored password. This is a nice indicator to show whether or not a password is present.

Here’s a screenshot for Bob’s SAS metadata identity. We can see he has no password stored for his inbound DefaultAuth domain\bob login, but he does have a password stored for his outbound OracleDBAuth oraclebob login.

Protecting the Unrestricted from Impersonation

I was asked a very insightful question about SAS® metadata security this week. This question and the ensuing investigation means I’ll now consider the inclusion of protections for unrestricted users in my metadata security plans. Especially for securing sensitive environments that have a separate group of user administrators who should not have access to login using unrestricted accounts.

Unrestricted users are very highly privileged users in SAS metadata. Metadata access controls do not apply to them. You might consider SAS metadata unrestricted users as somewhat like the UNIX root user.

The question I mentioned earlier came up when I was discussing how SAS metadata user administrators have the ability to impersonate other users for troubleshooting and testing purposes. This is a very useful feature. The person asked a question along the lines of:

Is it possible for a user administrator, someone in the “Metadata Server: User Administration” role, to impersonate an existing unrestricted user, and then as that impersonated unrestricted user make themselves unrestricted?

We decided to test it out and found that it was indeed possible.

This potential, for user administrators to elevate themselves to unrestricted via the impersonation of an existing unrestricted user, is easily protected against. An explicit denial of WriteMetadata to PUBLIC on each unrestricted user account will do the trick. This ensures that no user, other than an already unrestricted user, will be able to modify the account for those existing protected unrestricted users in order to attempt impersonation. e.g.

Unrestricted User Identity	Explicit Permissions (ACEs)
SAS Administrator	PUBLIC: -WM
Paul Homes (Admin)	PUBLIC: -WM

Of course these additional protections should go hand in hand with other measures to protect unrestricted users such as limiting knowledge of unrestricted user passwords (like the sasadm@saspw password) and ensuring that the adminUsers.txt file is only editable by appropriate administrators.

Update 12Dec2011: Someone has since alerted me to the fact that these additional protections for unrestricted user identities are actually documented in the SAS® 9.3 Intelligence Platform: Security Administration Guide appendices under Checklist for a More Secure Deployment where it states the following:

Consider reducing WriteMetadata access to the user definitions for any unrestricted users. This prevents restricted user administrators from updating an unrestricted user’s definition and then logging on as that unrestricted user. To add this protection, access the Authorization tab of each unrestricted user and add an explicit denial of the WriteMetadata permission for PUBLIC.

Baseline Security Metadata for a new SAS® 9.3 Deployment

When I’m reviewing SAS® metadata security implementations, I find it useful to have baseline security metadata to refer to. This baseline documents the initial state of metadata security (ACTs, ACEs, users, groups, roles, capabilities, protected objects, logins and internal logins) for a fresh new SAS software deployment. When reviewing a SAS installation I can then see what changes have been made since the initial software deployment.

The links below are for baseline metadata security reports I generated from a new SAS 9.3 deployment created from the EBIEDIEG single machine plan. The reports were generated using Metacoda Security Plug-ins V2.0.

New SAS 9.3 Lev3 EBIEDIEG Deployment (default exclusions): excludes protected objects and ACEs on protected objects under the following metadata folder tree paths:
- /ApplicationActions
- /Configuration
- /Portal Application Tree
- /Products
- /System
- /User Folders
New SAS 9.3 Lev3 EBIEDIEG Deployment (no exclusions): shows all security metadata including normally excluded objects

The first report has less detail as it excludes many things from areas of the metadata folder tree where SAS applications are known to automatically apply ACEs. This content is excluded to help me focus more on areas of the metadata folder tree where custom administrator-managed access controls are more likely to have been applied. The second report includes the excluded content for those times when I might also need to review those excluded areas for potential administrator-managed access controls.