When I do my SAS 9.4 server install I break it into phases: 1) install-only (no deploy) to get a populated sashome 2) add my custom CA certs (intermediate and root) to SAS Trusted CA Bundle - see Manage Certificates in the Trusted CA Bundle Using the SAS Deployment Manager 3) deploy-only to get populated Lev1     If you have an EV cert from a well known CA then I imagine you will have skipped 2 (or only added the intermediate) and perhaps combined 1 & 3 into a single step.   Looking at my recorded deployment response file, I can only see the server cert specified and looking at my notes I don't see any references to SSLCertificateChainFile, however based on the name of the file I highly suspect it was a manual post-deployment change to the Apache config by me - along the lines of Updating the Key and Certificate That Are Used by SAS Web Server but with a SSLCertificateChainFile that contains the PEM encoded intermediate and root certs.   From memory, with the SAS Deployment Wizard Typical level of prompting, you get to specify the server cert and key files (but not chain file). ... View more

Because it also fails for non-admin users when not using IWA, this sounds like an issue with permissions on the share and/or server file system. I would start tracing those. To assign a library (and not update any tables) they should only need basic read and list folder contents access.   Once you have the non-IWA access resolved, and start looking at IWA access, if you you are using Windows 10 watch out for potential issues with constrained vs unconstrained delegation - for more info look at the Windows Defender Credential Guard section of Stuart Rogers' SAS Global Forum Paper SAS1878-2018: SAS® 9.4 on Microsoft Windows: Unleashing Kerberos on Apache Hadoop ... View more

The SAS 9.4 Web Server (which includes Apache Web Server) can be configured to send the certificate chain to a web browser client. As long as the root certificate of the chain is in the browser CA store (as you would expect for an EV cert) then you should not need to make any changes to the browser. I don't have an EV certificate to test with my SAS mid-tier, but do have an intermediate CA with a self-signed root CA. I only have to add the self-signed root CA cert to the browser CA store because it is not already there.   Using openssl s_client I can see the whole certificate chain being sent back by the SAS Web Server (edited version below):   openssl s_client -showcerts -connect sasserver.example.com:8343 CONNECTED(00000003) depth=2 C = AU, O = Example, CN = Example Root CA verify return:1 depth=1 C = AU, O = Example, CN = Example Sub CA2 verify return:1 depth=0 C = AU, O = Example, CN = sasserver.example.com verify return:1 --- Certificate chain 0 s:/C=AU/O=Example/CN=sasserver.example.com i:/C=AU/O=Example/CN=Example Sub CA -----BEGIN CERTIFICATE----- **** PEM encoded server cert here **** -----END CERTIFICATE----- 1 s:/C=AU/O=Example/CN=Example Sub CA i:/C=AU/O=Example/CN=Example Root CA -----BEGIN CERTIFICATE----- **** PEM encoded Example Sub CA cert here **** -----END CERTIFICATE----- 2 s:/C=AU/O=Example/CN=Example Root CA i:/C=AU/O=Example/CN=Example Root CA -----BEGIN CERTIFICATE----- **** PEM encoded Example Root CA cert here **** -----END CERTIFICATE----- --- Server certificate subject=/C=AU/O=Example/CN=sasserver.example.com issuer=/C=AU/O=Example/CN=Example Sub CA ---   In my /opt/sas94m5/config/Lev1/Web/WebServer/conf/extra/httpd-ssl.conf file I have the following:     SSLCertificateFile "ssl/sasserver.example.com.crt" SSLCertificateKeyFile "ssl/sasserver.example.com.key" SSLCertificateChainFile "ssl/sasserver.example.com-ca-chain.crt" The /opt/sas94m5/config/Lev1/Web/WebServer/ssl/sasserver.example.com-ca-chain.crt file specified in SSLCertificateChainFile contains the PEM encoded CA certs (intermediate then root).   ... View more

Thanks @JuanS_OCS for the security testing framework recommendation - that's great advice! 😉   Gary, that SAS Management Console Server Manager Logs tab can be a bit tricky to get to grips with and it only shows a limited amount of recent history. For a more in-depth review I'd suggest looking at the metadata server log files on the server instead.   In terms of restoring from a backup, have a look at Best Practices for Backup and Restore. You will want to arrange some outage time and will need to restart some services. You have several options including: 1) restoring metadata only using the Metadata Manager plug-in - see Recovering the SAS Metadata Server in the SAS® 9.4 Intelligence Platform: System Administration Guide (if you have a clustered metadata server it is a bit more involved). There is a possibility the restored metadata may be out of sync with any changed physical content it references (WIPDS, file system etc) which is why the next option may be preferred. 2) restore using the SAS Deployment Backup and Recovery Tool which will do a more synchronised restore than a metadata-only restore. 3) recover anything not handled by the DBRT using standard file system restore features with whatever backup tools your org uses   I imagine 2 is your best option of the 3, but like all of the above you will lose any metadata changes your users have made since the recovery point in time you choose. Is that acceptable? If not then perhaps continue to troubleshoot the issue in the current state.   In terms of the SAS licenses (setinit/keys) applied in the interim period. Unless you restore your SAS home from a file system backup you should not need to re-apply the setinit. If you have products that rely on a setinit in metadata then you will most likely have to repeat that step. You may as well go through the whole SAS license update process post-restore as it cannot hurt to redo it.   If it were me, to avoid the potential loss of a weeks worth of interim work, and to understand what happened (to help avoid in future), I would, out of normal business hours, do a metadata-only backup of the current state, metadata-only restore a previous known-good state, use Metacoda Security Plug-ins to export metadata security tests of the previous known-good state, metadata-only restore the previous backup of the current state, run metadata security tests on the current state using the exported known-good state tests to see what has changed since with respect to metadata security. Review the test failures, undo-any-unwanted-changes/reinstate-any-prior-important-controls and repeat the tests until you get no (relevant) test failures. As I mentioned before I would be happy to give you an evaluation license, and walk you through a demo, to help you get past this issue. If it helps to justify budget in the future that would be nice but if the eval can help you get out of a one-off difficult spot then that's a good outcome too.   ... View more

Hi Gary,   Are you 100% sure that access controls (or group/role memberships) on those servers have not changed? I'm guessing you've already reviewed the ACTs (definition and usage), ACEs and checked the SAS metadata server logs for security audit log messages during the time frame when the change in access occurred?   Another, somewhat remote, possibility would be to check whether a broad user group like SASUSERS or PUBLIC been added as a nested member of the SAS Administrators group or the Metadata Server: Unrestricted role and so indirectly/implicitly granted lots of users permissions they would not otherwise have.   If you are still having problems after trying all the suggestions mentioned in this thread, I could give you an evaluation license for Metacoda Security Plug-ins, and show you how you can review and trace permission related issues with the Object Permissions Explorer and Permissions Tracer plug-ins. If that's of interest just send me a private message.   Cheers Paul ... View more

The same question has been asked by @shoin in the Admin & Deploy community so you might want to keep an eye on that thread in case it gets an answer: https://communities.sas.com/t5/Administration-and-Deployment/Default-Viya-Install-path-is-there-an-alternative/m-p/500567#M14511 ... View more

Yes, there are MetadataCreated and MetadataUpdated attributes for all objects in metadata. The question is do you want it for the Person (representing the user identity) or the Login (representing the user id - one of the means they can be identified as that Person)? It is possible that they can be different. In the screenshot below you can see the SAS Demo User (Person object) with login sasdemo (Login object). I deleted and recreated the Login object several times after I created the Person object.     The SAS %MDUEXTR macro does not extract MetadataCreated and MetadataUpdated, so if you need those, and do not want to write the code yourself, we have alternative %metacodaPersonExtract and %metacodaIdentityLoginExtract macros in our idsync-utils github project that extract those extra attributes (and also handle long UTF-8 strings). ... View more

Metacoda Security Plug-ins, including the ACT Reviewer, are supported for SAS versions 9.2, 9.3 and 9.4. ... View more

Thanks for pinging me @andreas_lds - I didn't notice this one as I mainly read the Administration and Deployment board.   As @andreas_lds mentioned you could use the SAS® 9.4 Open Metadata Interface to extract info about metadata objects, such as ACTs, (as described in the SAS® 9.4 Metadata Model). For users and groups I'd suggest using the shortcut of the SAS %MDUEXTR macro for basic info on users, groups and roles.   My company has a Metacoda Security Plug-ins product that is used to explore, document, and test several different aspects of SAS metadata security. Whilst this is a commercial product we do also have a few free plug-ins and the ACT Reviewer is one of them. You can use it to export an HTML reports of all your ACTs: how they have been defined, where they have been applied, and how they have been protected. If you'd like to get access to this plug-in and the other free plug-ins (and optionally request an evaluation of the licensed ones) you can register here. ... View more