Tag: Accounts/Logins

Password Encoding with SAS

Quick note from Paul: I’m really excited that platformadmin.com’s very first guest post is from the well known blogger and author Tricia Aanderud. I suspect you already know Tricia, but just in case you don’t …

Tricia Aanderud, president of And Data, Inc., provides SAS® consulting services to corporations who need assistance understanding how to transform their data into meaningful charts, reports, and dashboards. Tricia has been an enthusiastic SAS user since 2002 and has presented papers at the SAS Global Forum and other industry conferences. She is the co-author of two SAS BI books, “Building Business Intelligence with SAS: Content Development Examples” and “The 50 Keys to Learning SAS Stored Processes”.

Now over to Tricia …

I frequently find myself querying the metadata to assist with understanding a new customer system or trying to navigate one of my demo systems. As a result, I find I have many utilities that I want to share with customers. However, since these connect to the metadata with an active password, I don’t want to share my password. Using the SAS PWENCODE procedure, I can encode my password in a SAS program and voilà! a way to share the code and shield the password.

Encoding the Password

The PWENCODE procedure allows you to encode passwords that are used in place of plaintext passwords in SAS programs.

The following figure shows the PWENCODE procedure in a simple way. My example password, Pa55w0rd!, is placed in quotes. You can use different encoding methods, which you can read more about in the SAS PWENCODE procedure documentation.

The encoded password appears in the Continue reading “Password Encoding with SAS”

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.

  1. 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
  2. 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.