Application server authorization

[gboggs]

Over the weekend we stopped and restarted the services on our Linux 9.4 environment in order to apply the keys.  Now my users are seeing all of our Application servers in EG when on Friday they only saw the servers they were authorized to.  Could I have stepped on an entry in the config_user.. file when doing this?  We need to get back to the configuration we had last week because now users are getting different default servers and their projects are not set up to runagainst these servers.  

Does anyone have any ideas?  We are running SAS 9.4 on a Linux server.  

Authorities at the server and user levels did NOT change.  

Gary

[SASKiwi]

I suspect the behaviour you are seeing may be caused by the order or way you stopped and started your SAS services. I would recommend just doing a full reboot of all of your SAS servers, restarting them in the order metadata, app, web. Then check to see if this resolves your problem. Doing this will be a lot quicker than trying to diagnose what went wrong.

[PaulHomes]

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

[gboggs]

Thank you Paul.  Looks like my the Metadata logs are not turned on.  I user the Management Console to view and it has the following.  for the Metadata Manager server.  

Current message level: Off
Current threshold level: Error
Either there's no log available, ....

My visual review of the ACTs, User Groups and Users does not show any changes that I can see.  No nested elevated user groups such as SAS Administrators, SAS Security Admins in the lower groups nor do I see PUBLIC, or SASUSERS embedded within any of the higher functioning groups either.  

I think my next step is to restore back to Sunday.  I am assuming that to restore I first need to stop all services at the linux level (./sas.servers stop) before I restore.  Can you confirm that?  Also do you know if this will reset the keys back to Sunday as well?  

Thanks for taking the time. i did recommend your product but it was shot down during budgets.  Maybe this will help get it in. 

[PaulHomes]

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.

[MichelleHomes]

Hi Gary,

I thought I'd share with you a presentation Paul gave at the SAS Nordic user conferences in June. Paul's presentation, ‘How do you know it's secure if you don't test it?’ discussed and demonstrated methods for testing SAS metadata security including three aspects of testing:

1. Implementation testing – how has it been secured?;
   
2. Outcome testing – what is the effective result of the implementation? and
   
3. Best practice testing – how well does the implementation align with best practices such as the well-known Golden Rules?

Feel free to download the presentation which also includes references to GDPR articles at https://communities.sas.com/t5/Nordic-Events-and-Presentations/FANS-Conference-2018-Testing-SAS-9-Me...

Please let us know if you'd like further assistance.

Kind Regards,

Michelle

[nhvdwalt]

By default, Metadata backups are taking daily at 1 am. You could temporarily roll back to a previous day's backup and see if any Metadata permissions were changed between the two days.

[JuanS_OCS]

Hello @gboggs,

I agree with @PaulHomes. I would definetely focus on the SAS metadata permissions, rather than OS or other config files or scripts.

Here are my guesses:

• Someone changed some permissions, ACTs, applied ACTs to folders or group memberships.
• If you have a user synchronization script, this script might have changes some group memberships in the metadata, hence, changing permissions as well.

So, the problem is clear, the cause it is still unclear, you would need to investigate it.

To solve it, if you have the authorizations matrix well documented, you only need to apply the righ permissions, with SAS Management Console, to the SASAppX - WorkspaceServer or the SASAppX node, denying ReadMetadata.

Towards the future, and to prevent or identify this problem on an earlier stage (and have it fully documented), I would like to recomment the Security Testing utility from metacoda. If you are interested, I am sure @PaulHomes and @MichelleHomes can help you with it. I love all of their tools.

Hope it helps.

Kind regards,

Juan