Also, what method did you use to stop access to SAS 9.3 for your users? ... View more

I thought perhaps it might be because the userid for the credentials being used to log into the SAS Metadata Server are on a group rather than a user (Person object). This is similar to how you see sassrv on the SAS General Servers groups Accounts tab and can login as the group using the sassrv credentials. I created a SAS metadata group 'Test' and added a users login (demotest) to its Accounts tab, then logged in as that user. I see the following in the SAS Metadata Server log:   2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - The specified person name 'Test' does not exist in metadata. 2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - GetUserFolders return code=807feca2.... 2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - DoRequest return code=807feca2....   So similar but not identical. I did this test with sas 9.3 M2 - which SAS 9.3 version are you using? ... View more

Of course, another way to always use a service identity to launch workspace servers is to switch the SAS Workspace Server over to SAS Token Authentication. The credentials used to spawn these servers then only need to be accessible to the SAS Trusted User identity (usually by adding them to the SAS General Servers group). For more info see the SAS Token Authentication and How to Configure SAS Token Authentication sections in the SAS® 9.4 Intelligence Platform: Security Administration Guide.   I would also suggest looking into the underlying problem/requirement that is sending you down this path of configuring a single service identity to launch the servers (and losing the option for using file system access controls based on the requesting user). It is completely understandable that users would not like being asked for credentials each time they connect to SASApp. When I have seen this outcome in the past it has sometimes been a sign of a non-optimal configuration, examples including non-aligned authentication domains for the cached credentials for the initial metadata connection and subsequent compute server connections, or Integrated Windows Authentication connections to the SAS metadata server without configuring IWA support for the workspace server. Of course sometimes, with things like mixed-authentication providers, SAS Token Authentication may become a more optimal configuration. @cjsummers - it would be interesting to know the background behind the requirement to use a single service identity for your SAS Workspace Servers. Having a better understanding of the environment and constraints can lead to more tailored advice and options.    Cheers Paul ... View more

Hi Dennis,   When you have multiple admins making changes and you want to see who changed what and when then you could look at enabling the SAS Environment Manager Service Architecture and using the built-in Report Center or querying the data mart tables yourself.   Another option, especially in the area of metadata security for carefully monitoring changes to access controls, high privilege group/role membership etc, is to use the Metacoda Security Testing Framework. This allows you to export test scripts from an environment in a known-good state and then regularly run those test scripts against the environment in batch on a regular basis.  When unexpected changes occur you can get an email alert indicating test failures so you can investigate further to find out if they are due to good or bad security changes. I did a demo of some security implementation tests (for ACTs) in a webinar with @DavidStern recently. You can find a link to the webinar recording and to David's best practice papers via this blog post: SAS® Security Model Design Golden Rules, Validation, and Monitoring with Metacoda. For more background information on the testing framework I wrote a SAS Global Forum 2014 paper: Test for Success: Automated Testing of SAS® Metadata Security Implementations.   I hope you find this useful.   Cheers Paul ... View more

I have resolved my own issue with SAS Management Console 9.5 M5 not starting. It appears that the VJR cache did not get updated. After deleting/renaming the file C:\Program Files\SASHome2\SASVersionedJarRepository\eclipse\com.sas.app.launcher.cacheFile (as mentioned in http://support.sas.com/kb/59/113.html for Foundation SAS) I was able to start SAS Management Console successfully. I took a little longer the first time whilst it rebuilt that cache file. ... View more

You may also find a log file in a location similar to this:   C:\Users\myuserid\AppData\Local\SAS\SASDeploymentWizard\sasmc_2017-9-28-14.41.6.log   ... with the same sasmc_console.exe messages and a few more. ... View more

This happended to me today after updating workstation clients to SAS 9.4 M5. SAS Management Console started, the splash screen appeared, disappeared, and then nothing.   I remembered that there is a sasmc_console.exe alongside sasmc.exe. If you run that from a Windows command line it logs messages to the console. In my case it showed a "no matching Plug-ins" message:   C:\Program Files\SASHome2\SASManagementConsole\9.4>sasmc_console.exe java.lang.RuntimeException: com.sas.app.RepositoryException: For one or more plug-in requests, no matching Plug-ins were found in repository: MetaInt [9.1.0.0_SAS_20170720162239,9.1.0.0_SAS_20170720162239], PlatformComputing_PM [10.1.0.0_SAS_20170516111116,10.1.0.0_SAS_20170516111116], ....   ... which I'm about to start looking into further. 🙂 ... View more

You may also find some clues in the SAS Management Console client log file: SASMCErrorLog.txt   I would check its timestamp, to see if it is being updated, and then the contents for any stack traces and error messages.   If you need help finding that log file there's more info at https://platformadmin.com/blogs/paul/2010/06/sas-management-console-log-file/ and https://support.sas.com/kb/43/157.html ... View more

Have a look at the Permissions doc link I posted above. You'll see tables that show, for various tasks, what the minimum permissions required are, for the various parts (servers, libraries, folders, tables, reports, explorations etc) in order to be able to do that task. You will see that to view a report you only need RM for the report (and RM for the folders to be able to navigate to it). You need RM and R for the tables as the data source for the report. If you follow metadata security best practices, the required sets of permissions can flow consistently from standard ACTs applied to key objects/folders.   Those documentation tables are very useful. To confidently manage metadata security you will also need an understanding of identity hierarchies, object inheritance paths, conflict resolutions rules, and best practices. If you are not confident with those then I recommend reading the docs, attending the SAS Platform Administration Fast Track course, and reading best practice papers by the likes of @CecilyHoffritz & Johannes Jørgensen, @DavidStern, and @angieh.   There are also a couple of webinars on metadata security best practices coming up soon: Angie Hedberg and @MichelleHomes are doing one this week - see https://www.sas.com/en_us/events/users-groups/17q3/security-best-practices.html and David Stern and I are also doing one in October - see https://www.sas.com/en_gb/events/2017/user-webinars/security-model-designs.html   ... View more

It looks like the permission info is cached. If you have a look in the Configuration Properties section of the SAS Visual Analytics 7.4: Administration Guide, you will see the following statement for the las.caching.permission.lifetime property. sets the duration of time (in seconds) for which permission information is cached by the LASR authorization service. The default is 900 seconds (15 minutes). Do not set a custom value unless you are directed to do so by SAS Technical Support.   I logged into VA as a user that had no access, then as an admin in SAS Management Console granted them access. Every few minutes I refreshed the report as the user in SAS VA. The error disappeared and the report displayed correctly after about 15 minutes. I also tried logging out and re-logging in but that seemed to have no effect.   When I did my test earlier I don't remember waiting that long, but it may be because I reloaded the table or tried it as a different user. I'll leave it to you to test out those scenarios 😉   BTW you can find out the VA version when logged into VA by clicking on the question mark icon in the top right hand corner and selecting the About menu item. ... View more