If you want to create it programmatically then have a look at the SAS IOMI AddUserFolders method: https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/omaref/n0xyl0tv8cxjjcn1iehd44cavbfz.htm   I have not had a need to use it myself yet but remembered seeing it in the documentation. It is supposedly locale aware and creates and secures the My Folder and Application Data correctly. This is what I would try first.   Off the top of my head I remember that SAS EG and SAS DI Studio created the user folders when needed but I do not know if there is a list as such. ... View more

Oh, and as @SASKiwi mentions, knowledgable SAS users can readily bypass metadata permissions on libraries and tables, so depending on how important this is, you may also want to look at SAS Metadata Bound Libraries: https://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm#n0tzurc8qfze0vn13z4n6j6mzz14.htm ... View more

The standard approach to this would be to put the tables in different folders and secure the folders so that inheritance does the heavy lifting. There are several different example scenarios in the SAS documentation. I would definitely recommend that over securing hundreds of individual objects (and maintaining that into the future).   If you still want some example SAS code that applies an ACT to multiple objects then have a look at the standard SAS MDUGRPAC macro (e.g. /opt/sas94m7/sashome/SASFoundation/9.4/sasautos/mdugrpac.sas) that used to be used in older versions of SAS to automatically secure user groups. It creates an ACT and then applies it to a bunch of objects.   ... View more

Hi @pchegoor  From your description it sounds like you are not unrestricted and not a user admin so I am puzzled why you would still be granted access to the group login but denied access to the group login password. They fact that someone else has been able to use it successfully rules out the possibility that it has been accidentally stored as 8 asterisks! 😉 I assume that the other user has no access to any other working Teradata logins in metadata by virtue of their own identity logins or any other group logins?   I also assume that you have also been using a new SAS EG session each time you made a change to rule out the use of cached logins by SAS EG? Have you also tried using the right mouse click Display Libname Statement action in the SAS Management Console Data Library Manager plug-in to review the libname statement code and the login it chooses to use? I find that quite useful in troubleshooting login access (as long as it is not a pre-assigned library).   When you say you add the SAS Administrators Group to the Teradata group do you mean SAS Administrators Group as a member of Teradata (or the other way round)? I am puzzled by the result you describe as it sounds very odd from here but then diagnosing security issues is very hard from afar without access to the environment to review. It is good that you are also working with SAS Technical Support as they are the best option with tricky problems like this.   Best of luck Paul ... View more

Hi,   If you are seeing the encoded version of 8 asterisks it suggests you are trying to use the library and access the metadata group's password as a highly privileged user and are deliberately not being given the correct password. As you would have seen in the thread you mentioned, someone who is unrestricted or a user administrator has the ability to see all logins but is restricted from fetching real passwords from metadata. This is one of the reasons we don't use unrestricted accounts for day to day work and may set up dual identities for our dual job roles.   I see you have tried removing yourself from the "SAS Administrators" group and that is one possibly path by which you may have gotten your privileged user status, however there may be other paths too. When you log into SAS Management Console what do you see on the status bar? userid as User Name userid as Unrestricted If option 2 then you are still a member of the unrestricted role by some path. If option 1 then you may still be a user administrator, in which case I would look at someone elses user in SAS Management Console User Manager. If you don't see an empty Logins tab and are not-unrestricted then you are most likely a User Administrator. Another possible but less obvious path is the SAS Metadata Server's adminUsers.txt file - it is unlikely but worth a look if all else fails.   To troubleshoot this, I would recommend you start by looking at the "Metadata Server: Unrestricted" and "Metadata Server: User Administration" roles in SAS Management Console and work backwards. Are you a direct member of the roles? Are you a member of any groups that are direct members of the roles? Are you an indirect member by virtue of any nested group memberships?   A fast way to find this out, and see all paths by which someone is a member of a role is to use the Metacoda User Reviewer Roles tab, or the Metacoda Role Reviewer Members tab. If the source of the problem is not already obvious from the SAS User Manager plug-in, and you would like to try the Metacoda Plug-ins too, then you can register for a 30 day free evaluation at https://www.metacoda.com/ - they will help you track down any less obvious paths.   I hope this helps. Cheers Paul ... View more

Hi, I wonder if you are running into the same HiDPI issue that I wrote about in a blog post: https://platformadmin.com/blogs/paul/2017/09/sas-management-console-on-hidpi-windows-10/ If you have a look in the comments you'll see that Vincent used the same method to get SAS Enterprise Miner looking OK on a HiDPI display. I hope this helps. Paul ... View more

There are a few situations I have seen where you may find yourself with read-only access to a user in SAS Management Console: You are viewing the user indirectly. If you open the user properties directly in SAS Management Console User Manager (and you have sufficient role/permissions) then it should be read/write. If you open the user properties indirectly, such as selecting the user in the members list of a group and clicking the properties button, to indirectly view the user properties, then it will always be read-only. You can only make changes when editing the user directly. The user is an unrestricted user (direct/indirect member of the Metadata Server: Unrestricted role), but you are only a user administrator (direct/indirect member of the Metadata Server: User Administration role). Restricted user admins cannot modify unrestricted admins otherwise there is the potential for that restricted admin to impersonate the unrestricted user and then promote themselves to unrestricted. Access controls have been applied to the user that effectively deny the WriteMetadata permission for the restricted user admin that is trying to modify them. This is sometimes done deliberately in delegated user admin scenarios but more often than not it is the result of a prior mistake. This does not apply to unrestricted user admins as permissions to no apply to them. I hope this helps you narrow down the problem. ... View more

There are a couple of strategies that people use when they encounter identity sync errors relating to trying to add AD users/groups to SAS when they already exist (often manually added ones). The first is to delete the users/groups in SAS to make way for the identity sync process to recreate them. This is easy but is quite brutal and will destroy any metadata relationships those users/groups already have, including any access control that directly reference them. A better way is to link up the SAS user/group with the AD user/group by editing the external identity metadata for the user/group and adding in the id you have chosen for the sync process (i.e. distinguishedName, sAMAccountName, objectGUID etc). You can see an example screenshot of the SAS Management Console User Manager Edit External Identity Properties dialog in this blog post: https://platformadmin.com/blogs/paul/2016/03/identity-sync-finding-your-keys/     If you have only a handful of these to add then the User Manager plug-in is the way to go. If you have lots then Metacoda also has a (commercial) External Identity Manager plug-in that can streamline this, including import/export from CSV files. We have helped some SAS customers automate this process for hundreds of users when setting up identity sync for the first time. ... View more

In the SAS 9.4 metadata model permissions for tables do not inherit from the library they are contained in but instead from the folder they are contained in. To set permissions consistently across a large number of tables, apply the permissions to one of the parent folders the tables are contained in. See https://documentation.sas.com/?docsetId=bisecag&docsetTarget=p0eqebtrv1qhzhn1qje3kytr5kcr.htm&docsetVersion=9.4&locale=en   ... View more

Those $(UPPER_CASE_THINGS_IN_PARENTHESES) are environment variables that will be automatically replaced by Notepad++ with values appropriate for the (SAS) file you are currently editing. See http://docs.notepad-plus-plus.org/index.php/External_Programs for more info.   I assume that you have sas.exe on the same machine you are running Notepad++ on? i.e. SAS is not on a remote Windows or Linux server that you usually access with a platform client like SAS Enterprise Guide?   If it is not working then I would try constructing the command that Notepad++ would run and then paste it into a command window and see if you get any interesting error messages. ... View more

Hi,   1) In example 1 "LibraryA has an explicit denial for PUBLIC and LibraryA’s parent folder has an explicit grant for the user." The (ReadMetadata) grant on the parent folder is overridden by the denial to PUBLIC on the library object itself. Everybody is a member of PUBLIC and so nobody will be able to see the library unless there is something of a higher precedence on the object that grants the permission back (or they are a member of the unrestricted role). You are correct in your statement "A user who is a member of PUBLIC will not be able to see Library A." but also that everybody is a member of the PUBLIC group so it applies to everybody. When considering effective permissions on an object you have to consider the complete set of applicable identities - the user themselves and every group they are a member of - direct, indirect and implicit (SASUSERS, PUBLIC).   2) Ordinarily yes, a PUBLIC-only user (someone that has no SAS identity of their own) would not be able to login due to the denial of permission to PUBLIC in the repository ACT (usually named Default ACT). One does need to consider the possibility that this may have been changed, either accidentally or deliberately, and PUBLIC-only users have been given the ability to login. That is why I prefer to deny permissions to PUBLIC rather than SASUSERS. Even in the normal situation, when PUBLIC-only users cannot login, the PUBLIC (or SASUSERS) group is still the best group to use to wipe out access for everybody (except unrestricted) and then grant back permissions selectively to other narrower groups (this is one of the best practices).   I hope this helps.   Cheers Paul ... View more

Thanks @BeStibolt and the rest of the SAS Nordic teams for welcoming us to the SAS Nordic Forums over the last few weeks. It was wonderful to catch up with SAS staff, customers, and partners and hear about how SAS is being used in the region. We have always admired the great SAS community you have in the Nordics with the combination of face-to-face forum events and regular webinars. It is well worth the trip from Australia and we hope to come back again soon. ... View more