Hi Nigel,   i would advise against removing the SASUSERS: +WM from the repository ACT (commonly Default ACT). From memory I believe that those broad grants of +RM and +WM to SASUSERS at the repository level control the ability to log in and create new objects (which all SAS users need to do) - I can't find any explicit documentation on this so I'll double check and test it when I get a chance.   If you look at the Adjust the Repository-Level Settings section in the SAS 9.4 Management Console: Guide to Users and Permissions, it states "All users need ReadMetadata and WriteMetadata access at the repository level. In general, it is appropriate for the SASUSERS group to have these permissions on the repository ACT's Permission Pattern tab."   What I would recommend instead is that you use something like a "Hide ACT" to revoke WM from all users except admins and selectively grant WM (or WMM) back to those that require it with additional ACTs. For more info on this see the Baseline ACTs section in the SAS 9.4 Intelligence Platform: Administration Security Administration Guide. If you haven't already seem them, I would also wholeheartedly recommend reading David Stern's excellent Five papers on Recommended SAS 9.4 Security Model Design (part 1 & part 2). I hope this is useful.   Cheers Paul ... View more

Rather than looking at this problem as how do I revoke access to people who have access but shouldn't, I would recommend taking a step back and considering how do I make sure I only grant access to the people who should have access. Based on the latter it looks like the access controls on the app server are not currently setup correctly to only grant access to those who should have access.   If you were to look at denying access to specific users or non-implicit groups (groups other than PUBLIC/SASUSERS) then you are very likely to run into conflict scenarios. You end up finding people-who-have-access-who-shouldn't or people-who-don't-have-access-but-should that can hard to troubleshoot (and the first group don't always tell you).   The recommended practice is to deny broadly (wipe out everyone's access) using PUBLIC (or SASUSERS) and then start granting access back to those who should have access (SAS System Services, SAS Administrators, other org groups).   For more info on this, there several resources you could look at: SAS® Security Model Design Golden Rules, Validation, and Monitoring - Webinar - there is a webinar and many links to related papers SAS Global Forum 2011 Paper 376-2011 Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark by Cecily Hoffritz & Johannes Jørgensen - includes example of securing app servers too If you follow those best practice examples then you control who has access by making sure they are members of groups that should have access. By making sure you do not deny permissions to any identity other than PUBLIC/SASUSERS then you also won't get conflicts. If the groups are setup correctly and someone doesn't have access then they need to join a group that has access. If they have access but shouldn't then they need to leave any groups that have access. If neither of those choices make business sense then the access controls and groups need to be revisited. ... View more

Have you noticed that your hostname doesn’t match what’s in the certificate? i.e. sasviyaV34 vs sasviya34 The hostname has an extra V. ... View more