When I apply a new SAS license (setinit) each year, sometime I forget to also update it in metadata. I might not even remember until I get an email from the SAS platform itself:
From: SAS Platform
Subject: SAS Product Expiration Notification
Your license for SAS product name on sas.example.com has expired. Please contact your on-site SAS support personnel to obtain your updated setinit information.
“on-site SAS support personnel” … hey that’s me! I feel embarrassed that I forgot … again!
So, what if you want to be a bit more proactive and double-check whether you have an up to date SAS setinit in metadata? Continue reading “Checking a SAS Setinit/License in Metadata”
This tip was prompted by a SAS Communities question which I hear from time to time, essentially “How do I find out which groups a SAS user is a Portal Group Content Administrator for?” It can be answered using the Metacoda Identity Permissions Explorer but involves a few steps so I will outline them here.
To quote the SAS® 9.4 Intelligence Platform: Web Application Administration Guide, Group Content Administrator section:
A group content administrator is a user who has WriteMetadata permission for the respective group, and the group’s Portal permission tree. A group content administrator can share personal content with the group, and can edit or remove content that has been shared with the group. (Portal administrators have WriteMetadata permission for all group permission trees that are defined in metadata.)
So, to find out which groups a user is group content admin for, we need to look for all of the group portal permission trees where the user has a grant of the WM permission. This can be done quickly and easily using the Metacoda Identity Permissions Explorer. Below is a screenshot with numbered steps where we find out which groups Aaron Atkins (demoaaron), a fictitious Business Analyst, is a Portal Group Content Administrator for. Continue reading “Metacoda Plug-ins Tip: User’s Group Content Admin Permissions (Identity Permissions Explorer)”
This tip details how to go about removing an unwanted Authentication Domain and all associated Login objects from SAS metadata. A need for this can arise when you have been temporarily (or accidentally/unnecessarily) added a second set of inbound logins for all of your SAS users and you decide you no longer need those extra logins (perhaps you are migrating between authentication mechanisms).
If you are using the Metacoda Identity Sync Plug-in then the first step is to edit the Identity Sync Profile (IDSP file) using the Identity Sync Profile Wizard and untick the checkbox that configures the 2nd login. If you don’t do this, then the auth domain, and all the logins, will simply be re-added next time you run a sync! You can see a sample screenshot of the wizard page where you can unconfigure the 2nd login below:
After updating, and saving, the Identity Sync Profile you are almost ready to remove the unwanted auth domain and associated logins. Before removing the metadata it is a good idea to do the following: Continue reading “Metacoda Plug-ins Tip: Removing an Unwanted Auth Domain and Logins”
It is usually obvious where a SAS user’s metadata home folder (My Folder or private user folder) is – just look under /User Folders/ (or /Users/ in older SAS versions) for a folder with the user’s name. Sometimes, however, it can be a little trickier to locate: the user name may be cryptic or the user may have been added and deleted in metadata multiple times and you have folders with numeric suffixes i.e. name, name(1), name(2) etc.
To be confident, a user’s home folder can be found specified in metadata. As highlighted in the screenshot below, using the Metacoda User Reviewer, select the user, right click and select Advanced Properties from the context menu. In the Advanced Properties dialog, and the Associated Objects tab you should see the home folder listed in the row where the Association Name is AssociatedHomeFolder.
As a bonus tip, if you need to find home folders for users that are no longer present in metadata see Finding Private User Folders for Deleted SAS Platform Users
Sometimes I forget whether I’ve added our internal site root and intermediate CA certificates to the Trusted CA Bundle that SAS® Software applications use. Sometimes I also forget the command I can use to find out whether I did! 😉 As is often the case with my blog posts, by jotting things down here, I can find them again either by searching this blog, or more likely, by remembering I wrote it when I see it turn up in Google search results!
If you use site-signed certificates from your own internal CA in your SAS platform installations then you’re probably already familiar with adding them to the Trusted CA Bundle using the SAS Deployment Manager (see the Manage Certificates in the Trusted CA Bundle Using the SAS Deployment Manager section in the Encryption in SAS® 9.4 book for more info).
If you want to find out what CA certificates are already in that bundle you can use the Java keytool command like so:
/opt/sas94m5/sashome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -list -keystore /opt/sas94m5/sashome/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.jks -storepass changeit
It generates a long list of CA certs, so I pipe it through grep to look for the ones I want:
/opt/sas94m5/sashome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -list -keystore /opt/sas94m5/sashome/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.jks -storepass changeit | grep -i metacoda
If you want more details on the certificates you can Continue reading “Did I add that CA Certificate to the SAS Trusted CA Bundle?”