I saw that error earlier this week too (Sunday or Monday I think) and had to switch to a different browser to login. I used to get that error quite regularly just after communities switched over from Jive to Lithium, but haven't seen it for a while now. ... View more

@ChrisHemedinger - I noted that the documentation link posted below by @sasprofileon the filename statement email acess method states that: When SAS is in a locked-down state, the FILENAME statement, EMAIL access method is not available. Your server administrator can re-enable this access method so that it is accessible in the locked-down state. For more information, see SAS Processing Restrictions for Servers in a Locked-Down State in SAS Language Reference: Concepts. Of course, as you suggested, there may still be other ways to email SAS output - attachments via PC email clients, photos via smartphones etc. It sounds like it would be a good idea for @sasprofile to talk to their in-house security team about their support and policies for outbound email monitoring and data leakage prevention in general. ... View more

I think there might be a confusion here between session encryption (such as TLS/STARTTLS) and message encryption (such as S/MIME).   The code you posted uses SAS to send an email by connecting to an SMTP server, initially unencrypted on port 587, and then upgrading the connection to encrypted using STARTTLS. The transfer of the message between SAS (as a client) and the SMTP server is then over an encrypted connection. Someone on the same network that could capture the traffic would have a hard time decrypting it. However the email message itself is not encrypted. The server that received the message may not be the ultimate destination for the receipient. It may relay the message onto another server (or series of servers) before it gets to the recipient. Any of those intermediate servers can inspect the message contents. Additionally you cannot be sure that any of those intermediate servers will use TLS when passing the message on (after the initial exchange between SAS and the first server). Where this is an issue, email message encryption (such as S/MIME) can be considered. In that situation the message itself is encrypted for the recipient(s) such that only the receipient(s) should be able to decrypt it. The message may or may not pass over encrypted connections between the intermediate servers and the intermediate servers will not be able to decrypt the message contents.   My understanding is that SAS supports session encryption (TLS/STARTTLS) but not message encryption such as S/MIME.   You mentioned the code didn't work for you but you didn't post the error you got.  You may want to talk to your local email admin as they will be able to advise which ports the server will accept messages on and the protocols that it supports. ... View more

Those batch commands are including in the SAS Platform Object Framework so you can run them on any machine that has that component installed. That could be a server or even a workstation. For example I have a Windows machine that only has SAS clients installed, including SAS Management Console, and those batch commands are in the C:\Program Files\SASHome2\SASPlatformObjectFramework\9.4\tools directory.   If you want to run them from SAS Enterprise Guide, in a platform environment, connecting to a SAS Workspace Server, then they will run on a server and you can use any of the SAS language features you would normally use to run operating system commands from SAS code:  call system, x, systask, filename pipe, etc. Also consider that, depending on your current config with respect to noxcmd and lockdown, you may or may not be able to run operating system commands on the server via SAS EG without some config changes. ... View more

If you are interested in a point & click solution for (1) and (3), we have an ACT Reviewer as part of our Metacoda Plug-ins and that particular plug-in happens to be available free of charge. It has an Objects tab that shows you which objects a selected ACT has been applied to. There is also an In Use column that lets you see at a glance which ACTs are not being used and could be candidates for removal. You can export a HTML report too. You can find more info at https://www.metacoda.com/en/products/security-plug-ins/act-reviewer/ where you can register to download the plug-ins if you want.   For (2), as suggested by @LinusH,  for SAS 9.2 to SAS 9.4, one option is to use the SAS Migration Utility (SMU) during the initial installation of SAS 9.4. Post-installation migration of users, group, and roles can be done with the the SAS MDU macros - there is some sample code in SAS Sample 42251: Partial Promotion of User and Group Metadata at http://support.sas.com/kb/42/251.html  We also provide a point & click method (including a few other features) in our Identity Sync plug-in. Using this plug-in you can download/export an XML file from SAS Management Console 9.2 and then upload/import that XML file using SAS Management Console 9.4. However, the Identity Sync plug-in is not one of the free ones, so if you're a SAS coder then you may want to start out by looking at the SAS sample referenced above.   For migrating ACTs from SAS 9.2 to SAS 9.4, it depends on how many you have. If there are only a few then it would be easier to just recreate them from scratch. If you have a significant number then you could consider writing some code in SAS 9.2 to generate scripts to run in SAS 9.4. SAS 9.4 has some batch tools that can be used to create an ACT (sas-make-act) and apply an ACT (sas-set-metadata-access). The metadata querying side of things in SAS 9.2 to create the scripts is not a simple task however, which is why you would have to have a significant number of ACTs to migrate to make it worthwhile.   If you are interested in a commercial solution for the verification of the successful migration of the SAS metadata security implementation from SAS 9.2 to SAS 9.4 then you could look at our automated Metacoda Security Testing Framework. This is a topic I discussed in my SAS Global Forum 2014 paper: Test for Success: Automated Testing of SAS® Metadata Security Implementations. ... View more

I would suggest you contact SAS Technical Support about this issue.   From the error message it look like it might be failing because the installation process can't find/use the standard Windows netstat and chcp commands. You might want to check with your Windows sys admin to see if there is any reason why those might not be available to the account being used to install SAS on that machine.   If you log into the server and open a command window, what happens if you issue the netstat and chcp commands? Are they not found, or do they run and generate output.   What do you get if you run the path command to print the command search path? ... View more

Are you following the instruction in the Configuring One-Way SSL Authentication section in Configuring the JBoss Application Server for Secure Sockets Layer and Client-Certificate Authentication on SAS® 9.3 Enterprise BI Server Web Applications at https://support.sas.com/resources/thirdpartysupport/v93/appservers/ConfigureJBossforSSLandClient-CertAuthforSAS9.3.pdf   If so, I think you may have sasmc.ini and smc.ini mixed up in your statement "the pdf file say edit sasmc.ini file but it's not exist i only see smc.ini". The PDF (above) mentions smc.ini but in my installation the file is sasmc.ini (i.e. there is a typo in the PDF).   I have seen that PKIX message many times and it usually means that the server certificate offered by the web (application) server (JBoss in this instance) is not trusted, in that the required certificate-authority (CA) certificate in the chain of trust cannot be found in the JRE's trust store. There are 2 ways to resolve this 1) update the default JRE trust store JREHOME/lib/security/cacerts to add the CA cert so all applications using that JRE can use it or 2) direct a Java application to use a specific keystore using the javax.net.ssl.trustStore* system properties as describe in the SAS PDF on page 11   You can tell which JRE SASMC is using by looking in the sasmc.ini file. It usually refers to JREHOME which is defined in the included sassw.config in the SAS home dir (usually 2 directories above sasmc.ini). ... View more

In addition to Juan's list, I'd also be keen to see coverage of the following topics: Detailed list of the various SAS Viya microservices that make up the architecture, together with information about their purposes, which product bundles they are included in, and how they interoperate. The various SAS Viya APIs provided by the microservices and in particular, if available, any discovery/reflection APIs SAS Viya Authentication options including single sign-on SAS Viya Authorization including fine grained row-level type security SAS Viya Logging configuration and customization ... View more

When you used the SAS Deployment Manager Update Passwords task, did you remember step 3 "Stop all SAS servers and services." and step 4 "Restart the metadata server, the SAS Web Infrastructure database (usually the SAS Web Infrastructure Platform Data Server), and any SAS solution-specific data servers. Do not restart other servers or services." ?  If not, then there may have been services using the old password that triggered a lock-out before you got to attempt your SAS MC login. Also, if you have any custom written applications, jobs, or other usages of those credentials they should be shut down or disabled until you have a chance to update them, otherwise they may lock you out by continuing to use the old password. ... View more

In that case, how was the password changed? Was it done in SAS Management Console User Manager plug-in (which only changes the password), or was it done with SAS Deployment Manager (which changes the password and updates any known/managed uses of it in configuration files and metadata). See the Update a Managed Password section of the SAS 9.4 Intelligence Platform: Security Administration Guide, Second Edition for more info. ... View more

Has the SAS Administrator internal account (sasadm@saspw) password been changed lately? Perhaps you have a component, batch process, or person that is using the old password and needs to be using the new one?  Or perhaps the password hasn't been changed and there is a component, batch process, or person using the incorrect password? I would suggest reviewing the SAS Metadata Server log files to look for sasadm@saspw authentication failures to see if you can identity the times, frequency and IP addresses of authentication failures for more clues. ... View more