SAS Management Console – Page 8

SAS Management Console over SSH

I was asked recently how to get SAS® Management Console to remotely access a SAS metadata server using SSH tunnels. In the absence of a VPN connection to your network, SSH can be an alternative for SAS Management Console access to a remote SAS metadata server.

I am a huge fan of SSH (Secure Shell). I have been using it several times a day for many years now. It’s great. If you haven’t heard of SSH before, take a look at the Wikipedia page for Secure Shell. Here’s a quote from the page that provides a nice intro/summary:

Secure Shell (SSH) is a network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network.

Here are a couple of methods for using SAS Management Console over SSH:

1. Remote execution of SAS Management Console with X11 forwarding to the client

This method can be used when you are accessing a SAS platform installation on Linux or UNIX and have SSH client software and X server software on your remote workstation. Mac or Linux workstations are great for this since they usually have all the required software pre-installed. Windows can also be used if you obtain SSH client and X server software. I personally use Putty as an SSH client when I am working on Windows and would defintely recommend it. I have no specific recommendations for an X server on Windows since it’s been a long time since I’ve done X on Windows.

Assuming, as a SAS platform administrator, you have remote SSH access to the SAS metadata server machine then you can use SSH from your workstation to execute the SAS Management Console remotely and forward the X display to your client workstation.

Here’s an example command to do this:

ssh -X sasmeta.example.com /opt/sas93/SASManagementConsole/9.3/sasmc

Which means SSH connect, with X11 forwarding, to the machine sasmeta.example.com and then execute the SAS Management Console (/opt/sas93/SASManagementConsole/9.3/sasmc) on that remote machine sending the X windows back to the client workstation.

2. Local execution of SAS Management Console with SSH tunneling

SSH also allows you to configure a tunnel – a local port on your workstation that that forwards traffic to a designated server and port in the remote network. This tunnel can be used to make a remote service appear to be a local service. We can use it to make a remote SAS metadata server port appear to be on the local workstation so that a local installation of the SAS Management Console can connect to it as if it had a local metadata server.

Here’s an example command to do this:

ssh -L 8561:sasmeta.example.com:8561 sasmid.example.com

Which means SSH connect to the machine sasmid.example.com and establish a local machine port (8561) that forwards traffic to the remote host/port sasmeta.example.com:8561 accessible via sasmid.example.com. If you are not using public key authentication (recommended) then you will be prompted for a user id and password for the server. Once the connection is active, a local SAS Management Console can be started and will be able to access the remote SAS metadata server using a connection profile that connects to a metadata server on host/port localhost:8561. All traffic to this local port will be sent to the remote metadata server over the SSH tunnel.

Bear in mind that this only makes the metadata server port available on the local machine. So the local SAS Management Console instance can only access the metadata server. It doesn’t necessarily make the client fully functional as it may require additional connections to additional servers e.g. access to a SAS Object Spawner for a SAS Workspace Server session or a connection to the SAS Content Server. You could look into forwarding other ports and will also need to modify your local hosts file to redirect the remote host names found in metadata to the localhost interface. For anything more complex than pure metadata server access it would probably be easier and more robust to use a VPN connection (or remote access via something like X or RDP to remote network client workstations).

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.