BookmarkSubscribeRSS Feed

The right way and the wrong way to limit access to SAS Environment Manager

Started ‎10-31-2018 by
Modified ‎10-31-2018 by
Views 5,783

A consultant called me from a customer site to explain that he had accidentally stopped all authenticated users including SAS Administrators from using SAS Environment Manager. There was now no-one left who could use the Rules page in SAS Environment Manager to remove the 'prohibit' rule which was causing the problem.




The consultant had correctly guessed that there would be a way to let themselves get back in using the sas-admin CLI. But he or she wanted a little help to do it and to avoid making things any worse.


This particular mistake will probably be fairly common, especially while many of us are new to SAS Viya's General Authorization system. So I think it's worth explaining what happened, how to fix the immediate problem of being locked out, and suggest a better way to achieve the original aim.


The SAS Viya General Authorization system is very different from the SAS 9 Metadata Authorization system. One of the most interesting differences is that it provides the SAS Administrator with several ways to lock themselves out of part or all of their own system! Fortunately, there are several suitably secure ways for an administrator to let themselves back in, so while it may initially be a heart-stopping moment when you realise you locked yourself out, there will almost certainly be a way to get back in - possibly several ways.


Limiting Access to SAS Environment Manager: the wrong way

In this case, the consultant wanted to prevent end users except SAS Administrators from using SAS Environment Manager at all.


I do not think it is necessary to remove general all-user access to SAS Environment Manager at most customer sites. But it is supported, according to this list of Selected Rules That Affect Access to Functionality. Looking at the rules which govern access to SAS Environment Manager, the consultant noticed:

❶ There is an out-of-the-box rule granting SAS Administrators access to all the pages in SAS Environment Manager (/SASEnvironmentManager/**)
❷ Another rule grants Authenticated Users access to the top level of SAS Environment Manager (/SASEnvironmentManager/)
❸ Several more rules grant Authenticated Users access to certain pages in Environment Manager, but not all of them



Figure 1 - Rules managing access to SAS Environment Manager (click to enlarge)


The consultant reasoned (correctly) that to prevent most users from accessing SAS Environment Manager, he or she needed only to prevent users from accessing the top level of SAS Environment Manager, so that they would not see the button on their navigation menu.


So, using the Rules page in SAS Environment Manager, he or she modified rule , which grants Authenticated users access to the top level of SAS Environment Manager (/SASEnvironmentManager/). He or she changed this rule to prohibit Authenticated Users from accessing the top level of SAS Environment Manager instead, reasoning that rule above (which grants SAS Administrators access to all the pages in SAS Environment manager) would still work.


When you do this, you get a dialog asking 'are you sure?', which ought to make you stop and think for a moment. The exact problem is explained in this dialog:



Figure 2 - Prohibit Access 'are you sure?' dialog


Disregarding that warning and clicking OK, rule ❷ now looks like this:



Figure 3 - Authenticated Users are going to be prohibited access to SAS Environment Manager


We should really change the description of the rule too, since it no longer allows access, it prohibits access.


Initially everything looks okay - your permissions to access SAS Environment Manager are evaluated when you first access it, and are cached for a short time, so we don't immediately get locked out:



Figure 4 - Modified rule - access to SAS Environment Manager is going to be prohibited to all users (click to enlarge)


However this change doesn't produce the intended result, for two reasons:

  1. SAS Administrators are authenticated users too.
  2. A prohibit always beats any grants in the general authorization system where a grant and a prohibit both apply to the same resource for the same user: Prohibit always wins.

After the SAS Administrator logs out, nobody, not even the SAS Administrator, can use SAS Environment Manager. This also means nobody can use Rules page to undo this change.



Figure 5 - Nobody can access SAS Environment Manager (click to enlarge)


Uh-oh. This is going to make finishing the implementation project more difficult.


At this point the consultant realised his or her mistake and its root cause, and asked for help.


Restoring access to SAS Environment Manager

The good news is that we can resolve this impasse using one of the best bits of SAS Viya: the sas-admin Command Line Interface (CLI). In this case, we'll use the General authorization plug-in.


To use the sas-admin CLI you need a shell session running on a SAS Viya host in the [CommandLine] host group for your deployment - in other words, one of the hosts where the Viya command line tools are deployed. You'll need to log in to that host as a user who has access to the filesystem directories containing the SAS Viya Command Line tools, such as 'sas' or 'root'. I am illustrating this post using a collection of hosts in SAS's RACE environment, for which I have root access, but you absolutely don't have to be root to do this.


First, we need to authenticate as a SAS Administrator (who has permission to modify the problem rule), using the authentication plugin for the sas-admin CLI. There are several SAS Administrators in this environment, and I'm using one called geladm:


/opt/sas/viya/home/bin/sas-admin auth login --user geladm --password xxxxxx


[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin auth login --user geladm --password xxxxxx
Enter credentials for

Login succeeded. Token saved.
[root@intviya01 ~]#


Now we can use the authorization plugin for the sas-admin CLI to list all rules in a text output format (rather than a more verbose JSON format), and use grep to find the rules which target SAS Environment Manager.


/opt/sas/viya/home/bin/sas-admin authorization --output text list-rules | grep SASEnv


In the results, we see the same rules that we saw in the filtered view of the Rules page in Environment Manager, which is reassuring. They are not necessarily in the same order, but in this case it seems that they are, and the prohibit rule is the second from last in the list:


[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin authorization --output text list-rules | grep SASEnv
278f2ecc-1a48-485a-8b88-1efade65416d   /SASEnvironmentManager/**            SASAdministrators   group                grant      [read]
953a133b-8a82-456a-99c4-bf7119f03ae9   /SASEnvironmentManager/dashboard     Administrators      authenticatedUsers   grant      [read]
1f714fa1-ab6d-4ee7-a4cf-24c4ca3bc342   /SASEnvironmentManager/content       SASAdministrators   authenticatedUsers   grant      [read]
9f0c7f1a-5d4b-4db1-aef3-58e1845f67f9   /SASEnvironmentManager/data          SASAdministrators   authenticatedUsers   grant      [read]
26d5e0e7-7f54-4821-83e8-babc7b193cec   /SASEnvironmentManager/servers       sasapp              authenticatedUsers   grant      [read]
de1159c9-47cd-493e-9c3b-62df8afb24a2   /SASEnvironmentManager/credentials   sasapp              authenticatedUsers   grant      [read]
6e966869-a463-4e96-8270-2077557c54f8   /SASEnvironmentManager/              sasapp              authenticatedUsers   prohibit   [read]
2994f5f6-c0a8-4694-b2f5-80c8e42f3549   /SASEnvironmentManager/jobs          SASAdministrators   authenticatedUsers   grant      [read]
[root@intviya01 ~]#


The rule IDs in my environment will be different from yours. Here, the rule ID of the prohibit rule causing our problem is 6e966869-a463-4e96-8270-2077557c54f8.


Now we can update this rule, to change it from a prohibit back to a grant, so that it grants all Authenticated Users access to /SASEnvironmentManager/. Again, remember you need to substitute the rule ID of the offending rule in your deployment, in place of the rule ID in mine:


/opt/sas/viya/home/bin/sas-admin authorization update-rule --id 6e966869-a463-4e96-8270-2077557c54f8 --grant --authenticated-users


[root@intviya01 ~]# /opt/sas/viya/home/bin/sas-admin authorization update-rule --id 6e966869-a463-4e96-8270-2077557c54f8 --grant --authenticated-users
    "description": "Allow access to an application.",
    "id": "6e966869-a463-4e96-8270-2077557c54f8",
    "mediaType": "",
    "modifiedBy": "geladm",
    "modifiedTimestamp": "2018-10-04T13:28:02.220Z",
    "objectUri": "/SASEnvironmentManager/",
    "permissions": [
    "principal": "",
    "principalType": "authenticatedUsers",
    "reason": "",
    "type": "grant",
    "version": 10
The rule has been modified.
[root@intviya01 ~]#


And now our SAS Administrator (and everyone else) can get back in to SAS Environment Manager:



Figure 6 - We can access SAS Environment Manager again (click to enlarge)


So, what would be a better way to reduce the number of people who can use SAS Environment Manager, if that is something you determine is appropriate for your customer and their authorization model?


Limiting Access to SAS Environment Manager: the right way

Again, I want to be clear that I do not think it is necessary to remove this general all-user access to SAS Environment Manager at most customer sites.


But suppose you felt absolutely compelled to, what is a good way to do it? Simple. You want to:

  1. Effectively not grant but also not prohibit access to /SASEnvironmentManager/ for Authenticated Users
    1. In the SAS Viya General Authorization System, access to any resource is by default not authorized, and will only be authorized if there is at least one rule granting access, and no rules prohibiting it. We can rely on this to not authorize Authenticated Users to use SAS Environment Manager. Simply don't grant them access to it.
    2. The word effectively in this point is relevant when an out-of-the-box rule exists which grants something you do not wish to grant. The two most obvious ways to make rule ineffective are to:
      1. Delete rule
      2. Disable rule - this option may be considered messy if you are confident you know what you are doing, but it may help you reverse the change later by simply re-enabling the disabled rule, if you change your mind.
  2. Grant access to /SASEnvironmentManager/ to some smaller subset of users
    1. If that subset of users is just SAS Administrators, there is nothing to do for the second part because rule  already takes care of SAS Administrators.
    2. If you wish another group of users, broader than just SAS Administrators but not as broad as all Authenticated Users to get access to SAS Environment Manager, you could modify rule , rather than delete or disable it. Why not modify the rule so that it grants access to /SASEnvironmentManager/ to another group, instead of to Authenticated Users? You could even call your new group 'SAS Environment Manager Users', as shown in Figure 7 below.


      Figure 7 - If you wish to restrict access to SAS Environment Manager, why not create a new Custom Group called 'SAS Environment Manager Users' (id=SASEnvironmentManagerUsers), and modify rule to apply to this group instead of Authenticated Users? (click to enlarge)

Now, users who are SAS Administrators, or are members of the SAS Environment Manager Users group see SAS Environment Manager in their side menu, but users (like Hazel in the screenshot below) who are in neither of those groups do not:



Figure 8 - Hazel, who now does not have access to SAS Environment Manager, does not see a 'Manage Environment' option in the side menu (click to enlarge)


Here is the same side menu for a user called Delilah who is a member of a group called Data Managers, which I put in the SAS Environment Manager Users group in this environment:



Figure 9 - Delilah, does have access to SAS Environment Manager, and sees a 'Manage Environment' option in the side menu (click to enlarge)


The use of a new custom group, or an LDAP group if you have one which is suitable, to manage access to SAS Environment Manager is documented and supported. It also seems elegant and unlikely to confuse another SAS Administrator in future. Of course, there's no obligation for you to have any users in the SAS Environment Manager Users group, if you don't want anybody (other than SAS Administrators) to have access to it.


One more thing. You should really design your authorization model before you start implementing it.


80% of the initial effort of setting up a good security model should be spent on design and an appropriate level of documentation. About 10% of the effort is needed for actual implementation - it's comparatively quick and easy. And about 10% of the effort is required for testing, to ensure the authorization model really does what you intended.


I hope this was useful!


So this is a paradigm change from the way SAS metadata works, where one denies globally (PUBLIC and SASUSERS) and allows selectively.

Hi @Kurt_Bremser, yes indeed it is.


Authorization in SAS Viya is quite different from SAS 9 metadata authorization. Of all the differences, I think the 'prohibit always wins' feature may be the one that trips new Viya administrators up the most. Rather than prohibiting access to a group of users who should not have access, you will almost always prefer to set up your authorization rules so that the access is not granted to them.


But in my experience in an internal educational role in SAS, people who are coming to Viya for the first time seem to find the two new auth systems (CAS authorization for data and general authorization for pretty much everything else) are quite logical and sensible once they have spent a little time with them. They're new and initially unfamiliar, but they're really quite neat.

Hello @DavidStern,


thank you for the post, very useful as usual coming from you.


Indeed, the most of the initial efforts should go to implementing a good authorizarions matrix, and its implementation.

At this moment, regarding the more than 300 default Rules for the most basic Viya installation, I think it would be interesting to have a document or tool, to have a better reporting /implementation and perhaps best practices, as you shared in the past for SAS 9.4.


Are you aware if there is any running development/project related to those areas I mention? 


PS. The first link seems to point to a non-existing page. 

Thank you for your comment @JuanS_OCS. I am sure we will see improvements to the rules UI and development of proven good practices begin to come out over the next year or two, and I hope to be able to write about both and share them here! We are working on lots of good practice things in our Global Enablement and Learning team within SAS, but it's going to take a bit of time and real experience in real projects before we have something as mature as the good practices we have now for SAS 9. We're working on it!


Thank you for letting me know about the first link being broken. I think I have fixed it, but I would appreciate someone outside SAS checking it now works correctly.


Best wishes!



Hi @DavidStern a useful and informative article, exactly the content that will help myself & others formulate the best practice which is needed in the Viya world.


Would using the 'sasboot' id (if you had access to it of course) still be able to get to Environment Manager in this scenario I wonder?





ps, the 1st link works now btw

Hey @alancox, that's an excellent question! But... no.


It turns out that once that change to rule #2 in the post above is made (which prohibits Authenticated Users' Read permission on /SASEnvironmentManager/ instead of granting it), sasboot cannot use Environment Manager either. This makes sense when you think about it: sasboot is authenticated, even if only by the SAS Logon service.


But it was a smart idea to try!




P.S. Thank you for checking the link - glad that seems to have fixed it.

I tried this in my Production SAS Viya 3.4 environment but did not work for me, Authorized users are still able to see SAS Environment Manager GUI and all its contents.Not sure what is wrong in my environment. Any insight what i could be wrong here.

Hi @syedhisam , did you log the test user out and log back in again before testing whether your change worked? Rule changes in the General Authorization system sometimes only take effect for newly logged-in sessions. If a user who has just logged in can see SAS Environment Manager in your SAS Viya 3.4 deployment, there are only two explanations that I can think of:

1. The user is directly or indirectly a member of a group which is granted the Read permission on /SASEnvironmentManager/. Check the user's group memberships, and see what groups have a rule granting them access to  /SASEnvironmentManager/

2. Authenticated Users are granted Read on /SASEnvironmentManager/


Does one of those things explain what you are seeing?





In my case AllAuthenticatedUsers group is entitled to every folders so whoever I add as a new user can able to see everything. When I disable grants of AllAuthenticatedUsers even Administrators can not able to see our reach any content. What is the solution of this problem? Any ideas?

Hi @akcoray, if I understand you correctly, the permissions you describe are not the default. It looks like someone may have changed the default authorization rules without completely understanding how they work.


However, you can most likely fix it, by finding the authorization rules that have been modified or added. It may only be a small number. Which version of SAS Viya are you using? In SAS Viya 4, in SAS Environment Manager signed in as a user who is in the SAS Administrators custom group, first go to the Content page. In the content page, right-click any folder, and choose View Authorization. Then look at the names of the permissions along the top for the one you are interested in, e.g. Read for the permission to see a folder, or Update for the permission to change it's name, or Read (Convey) for the permission to see objects inside the folder and so on.


Next, look at the Principals down the left of the authorization dialog, and find Authenticated Users, or another group or user, and click in the cell in the table that is the intersection of that row and the column for the permission you chose, and which shows a symbol for the authorization decision that would be made for that permission for that user, on the selected folder..


A dialog appears, and if you click on the Contributing Rules tab of this dialog, you can see which rules contributed to the authorization decision. This usually isn't a very long list - often just one or two rules. From that list you may be able to see what's causing the odd permissions behavior.


A small number of rules created out of the box during deployment use Prohibit settings to stop users accessing certain things, but the vast majority only grant permissions. Look for rules where the setting is Prohibit (or just possibly, Conditional Prohibit). Do they target a folder? If so, there is a good chance that they are causing or contributing to a permissions issue. See my YouTube Video for examples of good permission patterns - none of them use a Prohibit setting in an authorization rule: (708) SAS Demo | Simple General Authorization Patterns in SAS Viya - YouTube

Alternatively, still in SAS Environment Manager, go to the Rules page. There, click on the Manage Columns button top right:



Add the Date Modified column. Unfortunately you can't currently sort the rules in this table by their column headings, but you can at least see that the great majority of the rules were created at the about same time on the same date. This would be when your instance of SAS Viya was deployed. Then, you can filter the rules for ones edited since that date.


That should be a much smaller list of rules. If you right click a rule that targets a folder in its Object URI or Container URI fields, you should be able to see the name of the folder that corresponds with either or both of those URIs. That might also help.

Thanks for this article.

I have a question, prohibit works, but I can't get the reason being displayed.

Reason : u mag dit niet gebruiken, you are not allowed to use this.


Any advice on this ?


Regards ,


Dik Pater


Version history
Last update:
‎10-31-2018 11:03 AM
Updated by:


Available on demand!

Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.


Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags