Blogging about all things SAS

Been doing some work on SAS Security lately and the post over on Angela Halls blog about Managing Metadata via EG, elicited my post. Particluary the comment “NOTE:: Deleting Metadata can cause orphan content elsewhere, so use this capability judiciously.”

When you first install SAS it by default optimistic, by that I mean it allows public, and SAS Users to do lots unless you stop them.

Now if you do the SAS Administrators course the first thing you get told is to secure metadata, i.e change it to a pessimistic view, where users can’t do anything unless you grant them (or a group they belong to) rights to do so.

Easier said than done, as you can’t just deny everything to Public and SAS Users as nothing will work (because they need to be able to read and write metadata to check what they can do

So you need to play with your ACT and Group structure to initially deny them everything and then grant access to what you want them to see.

I suggest you at least deny the write metadata on anything you want to keep, before you show them in Enterprise Guide how to delete stuff

I beleive this all changes in SAS 9.2.

I have talked to a number of customers that are having a problem with the SAS Addin for Microsoft Office (AMO) remembering a users password and then locking them out of their account.

When a user configures their connection to the SAS Server in AMO they can save their password, so they effectively gain a form of single sign on. (The password is stored as an encrypted text string in an XML file).

A number of customers I talked to also have some form of LDAP authentication setup (i.e. Active Directory), Unfortunately when a user changes their password on the LDAP server, AMO doesn’t know about it. It keeps trying to authenticate the user with their old password until the users account gets locked.

SAS Enterprise Guide also enables the user to store their connection credentials, but it seems to prompt the user to re-enter their credentials if the authentication with the server fails, therefore the users account doesn’t get locked.

We are working through some work arounds for this to see if we can fix the AMO issue, but has anybody else struck this?

Anybody else fixed it?