Metacoda – Page 7 – platformadmin.com

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.

Metacoda Security Plug-ins Tip: Where’s that login?

This is a tip for Metacoda Security Plug-ins users who might have a need to track down which user or group identity in their SAS® metadata owns a particular user id.

Have you ever gone to add a login to a user or group identity in the SAS Management Console, perhaps some database credentials for a group to share, but couldn’t because the userid had already been used elsewhere? If so then you’ll be familiar with this error:

So now you know the userid has already been used elsewhere, but where exactly? Maybe it shouldn’t have been used on the other identity, or maybe you just want to check out the other identity because you might be able to take advantage of it instead of adding a new one?

It’s easy to find that user id, and the user or group identity it is associated with, by using the Metacoda Security Plug-ins Login Reviewer, especially if you have the new 2.0 version (which works with SAS 9.3 and SAS 9.2).

To track down the login open the Login Reviewer:

… and then, in the new filter bar, type in the user id which was already used, scott in this example. You’ll then see which identity has that login. In this example the scott login is already being used on the Vegas Enterprises: Oracle Users group which is why it couldn’t be added to the Custom Oracle Users group earlier.

If you have SAS 9.1.3 SP4 and Metacoda Security Plug-ins V1.0 then you won’t have the filter bar, but you can still find the login by clicking on the userid column header to sort by user id and then scroll down to find the problem login.

So finding a login isn’t that hard after all…

Capability Reviewer Preview: who has access to a capability and how?

The next version of the Metacoda Security Plug-ins includes a new Capability Reviewer. This new feature provides the ability to review who has access to a specific capability and by what paths a user, group or role acquires that capability.

As an example of how this is useful I’ll step through a scenario where we want to assess what needs to be done to avoid granting a specific capability to a specific user. If you have ever tried to make sure a user doesn’t have a particular capability then I’m sure you have seen this type of scenario. Lets say Bob Baxter is our user and he has the Drill to Detail capability in SAS® Web Report Studio 4.3 but he shouldn’t have.

We have to find all the roles that provide that capability directly to him and make sure he isn’t a direct member of the role. We need to remember that capability acquisition is cumulative and capabilities can’t be denied. It only takes 1 role to provide him the capability for him to have it. He can also get access to the capability through his, possibly nested, group memberships if those groups are members of a role that provides the capability. He can also get access through capability contributions, from contributing roles, to a role he is a member of directly or indirectly.

So now lets say Bob has been removed as a direct member of any roles that provided the capability but he still has the capability. Chances are he has acquired the capability indirectly through one of the groups that he is a member of (either directly or indirectly through nested group members, or implicitly through SASUSERS or PUBLIC). That means we need to track down how those groups have the capability and either remove him from the group or remove the group from the role (taking into account removing him from the group and/or removing the group from the role could have significant impacts elsewhere).

So where do we start with this? How do you find out which users, groups and roles have access to a specific capability and how they have access to that capability? This is where the Capability Reviewer in the upcoming V2 release of our Metacoda Security Plug-ins shines. The following screenshots show how we can use the Capability Reviewer to find this information.

The first screenshot below shows the initial view of the Capability Reviewer. It shows a list of all capabilities. Clicking on a capability shows all of the users, groups and roles that have access to that capability. This is presented in a tree format on the left and a table format on the right. The tree shows the various paths from the capability, through the roles, to the groups and users (including nested groups and contributing roles). The screenshots in this post are quite small, but you can click on any of them to view them full size.

We are interested in a specific capability, so we type drill in the filter bar to limit the display to those capabilities that include the text drill in their path/name or description. The result is shown in the next screenshot …

In the screenshot above (click it to view full size) we can see the filter bar has been used to find the Drill to Detail capability in SAS® Web Report Studio 4.3. The capability has been selected and we can see in the tree and table below it who has access to that capability. There are quite a few identities listed, but we are interested in a specific user (Bob). The next screenshot shows how we can look specifically at Bob’s access to that capability …

In the screenshot above (click it to view full size) we can see the filter bar within the Roles & Members tab, has been used to find Bob. By default the tree and table only show the shortest path by which the user acquires that capability, but if we want to ensure a user doesn’t have a capability we need to find and eliminate all capability access paths for that user, so we also click the “Show Duplicates” button on the filter bar. The table then shows all 3 paths by which Bob acquires the Drill to Detail capability:

Bob Baxter is a member of the implicit PUBLIC group which is a member of the Web Report Studio: Report Viewing role which has been granted the capability.
Bob Baxter is a member of the implicit PUBLIC group which is a member of the Web Report Studio: Report Creation role which has been granted the capability.
Bob Baxter is a member of the Vegas Enterprises: Executives group which is a member of the Vegas Enterprises: Report Consumers group which is a member of the Vegas Enterprises: Report Consumer Role which has Web Report Studio: Report Viewing as a contributing role which has been granted the capability.

As you can see the Capability Reviewer allows us to find exactly how Bob acquires the capability through all of the potential paths. To make sure he doesn’t have the capability we need to ensure he is not in any of these paths. How that is done for you will depend on how you have set up your groups, roles and capabilities within your SAS platform installation. The simplest way will be to either remove Bob from the relevant roles and/or groups, or remove the capability from the relevant role(s). However, we also need to bear in mind that, depending on the changes you make, this can have significant impacts to roles, capabilities and access controls elsewhere. A more realistic outcome from a requirement to effectively remove a capability for a user is that the roles & capabilities implementation needs to be re-assessed and re-planned. Roles & capabilities needs careful planning but that’s a bigger story than we have time for here.

Our other Metacoda Security Plug-ins reviewers can help you assess the potential impact of any changes you might plan to make. For example: the Role Reviewer can help you find out what other users and groups might be affected by changes to a role’s capability set; the Group Reviewer can help you find out what other users and groups are direct or indirect members of a group you might want to change role memberships for.

If you’d like to find out more about the Capability Reviewer, or evaluate a beta version when it becomes available soon, then you can either send me a message or contact us via the Metacoda contact form.

If you are attending SAS Global Forum 2011 in Las Vegas this week then you can also see the Capability Reviewer in action by visiting us at the Metacoda booth (#106) in the demo area.

Updated 08Sep2011: Metacoda Security Plug-ins V2.0, and the new Capability Reviewer, is now available to customers and evaluators. If you would like to try it out you can request a evaluation from the Metacoda web site.

User Reviewer V2: Sneak Peek

If you’re a SAS platform administrator who manages a SAS metadata security implementation then you might be interested in this sneak peek of some of the enhancements in the next version of our Metacoda Security Plug-ins (custom plug-ins that can be installed into the SAS Management Console). We’ve been hard at work updating our plug-ins to provide enhanced views of the great new metadata security improvements in SAS® 9.2 like roles and capabilities.

Roles and capabilities in SAS 9.2 let you control, via the SAS metadata server, user access to functionality and features in SAS client applications such as SAS Enterprise Guide, SAS Add-in to Microsoft Office, SAS Web Report Studio and SAS Management Console. For an excellent overview of roles and capabilities I’d definitely recommend reading Kathy Wisniewski’s SAS Global Forum 2010 paper “Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2“.

We’re improving our Metacoda Security Plug-ins User Reviewer by adding Roles and Capabilities tabs that provide extended information about the roles and capabilities for a user. This screenshot (click the thumbmail to view the full size image in a new window) shows a preview of our new Roles tab:

In the screenshot you can see that I have tracked down a particular user and am looking at all of the roles he is associated with. It shows:

direct role associations, where a user is a member of the role directly
indirect role associations, where the user is a member of a group (possibly nested) and that group is a member of the role
implicit role associations, where the user is associated with the role through the one of the implicit groups (SASUSERS and PUBLIC)
contributed role associations, where the user is associated with a role indirectly through that roles contribution to another role the user is associated with

Essentially this new Roles tab allows you to answer the question: is a user associated with a particular role, and if so, by what means are they associated?

Another question administrators want to answer for a given user is what capabilities do they have or not have, and why? That’s where our new User Reviewer Capabilities tab helps. Here is another screenshot (once again click the thumbnail to enlarge):

This screenshot shows the Capabilities tab where you can see a list of all the capabilities and whether or not the user has been granted access to them. If the user has been granted access to a capability it also shows which role is providing them with the capability and the membership path from the user to the role. If you’ve ever tried to track down why a user has an unexpected capability then I’m sure you’ll appreciate how useful this is.

That’s it for this sneek peak, but if you are going to SAS Global Forum 2011 in Las Vegas this year, and you’d like to find out more, then please pop by and visit us in the SAS Alliance Cafe for a demo – we’ll be in booth #106.

BTW if anyone out there is interested in trying out a beta version then we’re looking for a few more beta testers. If you have a SAS metadata server in a development, test, or sandpit environment and would like to test drive our plug-ins then let me know. You can contact me through this blog, Twitter, my LinkedIn profile, the Metacoda web site or even in person at the SAS Global Forum in a few weeks time :)

Identity Hierarchy

In my upcoming SAS Forum Australia & New Zealand 2010 presentation Best Practices with SAS® 9 Metadata Security, I mention that is important for platform administrators to have an understanding of the Identity Hierarchy concept. In this post I provide a bit more information about the identity hierarchy, and associated identity precedence, than time allows in the presentation.

Learning about the Identity Hierarchy

If you want to lean more about this topic, I would suggest any or all of the following:

Read the SAS® 9.2 Intelligence Platform Security Administration Guide, Chapter 3 Users, Groups, and Roles, specifically the section titled Identity Precedence
Read the SAS® 9.1.3 Intelligence Platform Security Administration Guide, Second Edition, Chapter 2 Understanding Authorization, specifically the section titled To Whom Can Permissions Be Assigned?
Attend the SAS training course SAS Platform Administration: Fast Track. I think this is one of the best courses available from SAS and is an essential foundation for any platform administrator. I should point out that I do teach this course from time to time for SAS Institute Australia so I might be a little biased ;)

Visualizing the Identity Hierarchy

The identity hierarchy consists of the user, all of the groups that they are a direct member of, all of the groups that they are an indirect member of via nested group memberships, as well as the SASUSERS and PUBLIC groups that they are implicit members of. All of these identities can be arranged in a hierarchy. The following screenshot shows the identity hierarchy for a fictitious user Kate Knowles:

This screenshot was generated and extracted from the identity hierarchy tab available in our Metacoda Security Plug-ins User Reviewer. This tab provides a visualization of the identity hierarchy for any selected user in metadata. If you are wondering what the various icons mean:

represents a user (in this particular case a user bulk-loaded into metadata from AD or LDAP);
represents a normal group;
represents a group that has been bulk loaded into metadata (from AD or LDAP); and
represents a group that ultimately contains itself (via a circular reference)

At the top of the identity hierarchy (level 0), with the highest identity precedence, is Kate Knowles herself. Underneath Kate (at level 1), and with the next highest identity precedence, are the groups that Kate is a direct member of ( Northern Region HR for example). These level 1 groups are those where you will find Kate listed on the group’s Members tab. Underneath those level 1 groups are the level 2 groups (e.g. Northern Region), that have the level 1 groups as direct members (i.e. you will find the level 1 group listed on the Members tab of the level 2 group). Kate is an indirect member of the level 2 groups. This process continues until we exhaust all of the nested groups, which is at level 3 for Kate. Finally, at the deepest levels are the implicit groups: SASUSERS for everyone with a metadata identity; and PUBLIC for everyone with valid credentials.

You can see the screenshot shows two different views of the identity hierarchy: 1) the tree view shows the member relationships between the groups as well as the shortest path by which the user is a member of any given group; and 2) a flattened table view which just shows the user and the direct, indirect and implicit groups in order of identity precedence.

The identity hierarchy shown above is a simplified smaller representation of a complete identity hierarchy. It has had redundant duplicate groups that have the same or lower identity precedence removed, so that groups are only shown once at their highest level of identity precedence. To illustrate this a simpler identity hierarchy is shown below which includes a duplicate group reference. In this example, Tara Thompson is a direct member of both the Australia and the Asia/Pacific groups – these are shown at level 1. The Australia group is itself a direct member of the Asia/Pacific group too, and so the Asia/Pacific group is also a level 2 group and shown greyed out below – ordinarily we hide this lower precedence group from the identity hierarchy. You might notice that there is no need for Tara to be a direct member of the Asia/Pacific group because she already has that membership indirectly through the Australia group membership. In fact this multi-level membership has the potential to cause unwanted conflicts. I plan to post about this type of identity hierarchy issue later on.

Importance of the Identity Hierarchy

The identity hierarchy is important because it is used to determine identity precedence which plays a key role in resolving conflicts. It can also be used to find any shared logins accessible to the user, via their group memberships, by walking the tree looking for logins on any of the groups.

To quote from the SAS® 9.2 Intelligence Platform Security Administration Guide:

Identity precedence affects authorization decisions when a user has more than one relevant permission setting because of the user’s group memberships. Identity precedence affects login priority when someone has more than one login in an authentication domain. Identity precedence is not relevant for roles

In SAS 9.1.3 the identity hierarchy is only used to resolve authorization decisions and find shared logins. Its use in choosing a higher priority login is new in SAS 9.2.

A good understanding of the identity hierarchy allows you to understand and troubleshoot conflicts, and hopefully help you plan to avoid them where possible.

Potential Identity Hierarchy Issues to Avoid

Most of the time the identity hierarchy is quite straightforward, but you can also get into some odd situations. Some of the potential issues to avoid include:

As shown above, in the identity hierarchy for Tara, a group can potentially appear at multiple levels in an individual’s identity hierarchy. Whilst this can be normal, care may need to be taken with access controls to avoid potentially unwanted outcomes. I plan to post an example soon which provides an example of an unwanted outcome due to an identity hierarchy conflict and “non-implicit-group permission denials”.
It is possible to end up with circular references in the identity hierarchy. This occurs when a group contains itself as an indirect member through a nested group membership. The Metacoda Security Plug-ins User Reviewer detects these and tags the group with a special icon . The identity hierarchy shown earlier for Kate provides an example of this: Kate is a direct member of the Human Resources Managers group which itself is a direct member of the Human Resources group and that group in turn is a direct member of the Human Resources Managers group (it’s own parent).
Whilst it’s possible to add the implicit groups SASUSERS and PUBLIC as direct members of other groups, this is not a recommended practice. It is however quite normal to add the implicit groups to roles with SAS 9.2. In another quote from the SAS® 9.2 Intelligence Platform Security Administration Guide:

To avoid introducing unnecessary complexity, don’t make PUBLIC or SASUSERS a member of another group. For example, if you make PUBLIC a member of GroupA, then a user who is an indirect member of GroupA (through his automatic membership in PUBLIC) has GroupA as his lowest precedence membership. This contradicts the usual expectation that every user’s lowest precedence membership is PUBLIC

To be continued …

I am planning on following up this post with some additional examples and practices that build upon this discussion of the identity hierarchy, but that’s it for now. I hope this post is useful to those who may want to find out more than I can discuss in my forum presentation. Please let me know if you have any comments or questions.