About PaulHomes

PaulHomes · ‎11-12-2018

The permissions required/enforced depend on where the data resides and the manner in which it is accessed. Consideration needs to be given to permissions at multiple layers: the metadata layer (for the metadata objects that describe the physical objects), permissions at the data layer and permissions at the storage layer - this could be 3rd party database, file system, etc. Some examples/options: 1) When using a 3rd party database using a SAS/ACCESS engine: metadata permissions on folder, table and library objects govern who can see and manipulate the metadata "view" of those external tables but not the content of those tables. Permissions at the database authorization layer will determine who can do CRUD and DDL operations. 2) When using the SAS BASE engine WITHOUT the Metadata Libname Engine (MLE): metadata permissions on folder, table and library objects govern who can see and manipulate the metadata "view" of those SAS datasets but not the content of those SAS datasets. Metadata permissions RM, WM/WMM, CM will control who can register and unregister the data (the data permissions R,W,C,D will be ignored). File system access controls will determine who can manipulate the SAS dataset files (where it's effectively read-only or read/write). 3) When using the SAS BASE engine WITH the Metadata Libname Engine: metadata permissions on folder, table and library objects govern who can see and manipulate the metadata "view" of those SAS datasets and the content of those SAS datasets - i.e. in addition to metadata RM, WM/WMM, CM permissions, the data permissions R,W,C,D will also be enforced (but only when accessing through the MLE). File system access controls will still determine who can manipulate the physical SAS dataset files. The main thing to beware of here is that whilst you may present an MLE view, savvy users with file system write permissions will be able to bypass it by coding their own libname statements ... if this is a concern then Metadata-Bound Libraries may be of interest. 4) For more control you can secure the underlying storage for a BASE engine library by converting it to a Metadata Bound Library (MBL). This protects the SAS datasets and contents with more traditional DB-style permissions(S, I, U, D, AT, CT, DT), maintained in metadata and always enforced. A savvy SAS user will not be able to bypass the metadata layer permissions by coding their own libname statement. You may however still need to consider file system access for users that can access the op-sys and do file system level operations (rm, mv etc). There is also the potential of adding in mediated-access for file-system access control but this is already a long response so I'll just add it as a additional point of interest that may be worth looking into 🙂 From your description I imagine that option 4 (MBL), or possibly option 1 (DB), will give you the level of control you need (as others have suggested) but there are always pros/cons to each approach that need to be considered against requirements so your situation may warrant something different or a hybrid. If you need more help in planning/testing this then I'd definitely recommend getting SAS Professional Services or a local SAS Partner in to advise further.

PaulHomes · ‎11-07-2018

Hi Bart, Depending on the context in which the SAS code is running you may potentially have a &_METAPERSON macro variable, containing the identity name, although I assume you have %put _all_ and not found it. The &_METAUSER macro variable does look like a login user id but in mixed-case user and user@domain format instead of the low-case user and domain\user format you have in your metadata. A transformation of user@domain to domain\user and a case-insensitive search of metadata Login objects should locate the Login object for the logged in user (Person). You can then follow the association to the Person object and then another association to the one or more Email objects for that Person. You could do this using data step metadata functions like @andreas_lds suggested or use the standard SAS %MDUEXTR macro to get all user info into SAS tables to query. We also have some similar macros at https://github.com/Metacoda/idsync-utils that can extract various aspects of SAS identity metadata into SAS tables: %metacodaIdentityLoginExtract will give you a table with userId, identityName, and identityObjId (among others) %metacodaPersonEmailExtract will give you a table with (email) address, personName, and personObjId (among others) A join of those 2 tables (on object id) with a filter on userId with an appropriately transformed &_METAUSER should give you the email address(es) for the user. If you are doing identity sync then you might cache such a table at the same time to facilitate easy lookups. Cheers Paul

PaulHomes · ‎10-31-2018

In addition to the advice from @SASKiwi, if this is an ongoing requirement, you could also look at using the User Import Macros. Whilst those macros are usually used for syncing with AD/LDAP they can also be used to sync from any other source where you can get the information into SAS tables. It is possible you may find them easier to use and maintain that using the lower level SAS Open Metadata Interface feature.

PaulHomes · ‎10-31-2018

Hi Jan, A few things of the top of my head.... Any there interesting messages in the SAS Management Console client log SASMCErrorLog.txt? The worst case of slow SAS MC start I've encountered was due to anti-virus/malware scanning. Any chance of temporarily disabling it to see how much impact it is having? Is it just SAS Management Console? Do any other Java based SAS apps connecting to metadata have the same issue (SAS Data Integration Studio, SAS Information Map Studio etc)? Is DNS resolution working well (dig, nslookup etc)? I have seen long delays in the past with slow DNS and timeouts. SAS Management Console also makes a connection to the mid-tier during startup/login - what sort of mid-tier response are you getting from those clients? Perhaps if you are able to temporarily run the metadata cluster in non-cluster mode you could see if there is any differences there with respect to metadata server cluster node redirections? Cheers Paul

PaulHomes · ‎10-31-2018

You might want to provide some more specific info (examples may help) so community members can give you more targeted assistance. e.g. which SAS version and platform is this for? Are you looking for help with access controls or just SAS roles and capabilities? It sounds like it might be a combination of several things. By role do you mean a SAS "Role" or a generic job role? As @SASKiwi mentioned SAS metadata bound libraries may help here. You will probably also need to look at access controls in metadata (via ACTs/ACEs for groups on objects), access controls in the file system (UNIX, Linux or WIndows?) and role/capabilities in metadata (to control access to SAS application features) - a multi-layered approach. If your question is only about SAS roles and capabilities then I would suggest the following resources: Metadata Roles section (and associated links) in the SAS® 9.4 Intelligence Platform: Security Administration Guide. Administering Roles section in the SAS® 9.4 Intelligence Platform: Desktop Application Administration Guide. Assign Capabilities to a Role section in the SAS® 9.4 Management Console: Guide to Users and Permissions. SAS Global Forum 2010 Paper (324-2010) "Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2" by Kathy Wisniewski

PaulHomes · ‎10-31-2018

If that script is part of the SAS AML solution then it is probably best for you to work with SAS Tech Support to resolve this. I don't have access to that software to investigate any further myself. If I did I would probably search for the ApplicationAction objects in metadata to see if they have been able to be associated with the AML applications to show up in SAS MC. Also review the script and its logs to see where and how it might go wrong. Unless other community members have experience with this aspect of SAS AML then SAS tech support will be your best option (as always). If you do get a resolution please report back on this thread so it might be useful to others in future. Cheers Paul

PaulHomes · ‎10-29-2018

If you have a look at the Load Balancing Error Messages section of the SAS® 9.4 Intelligence Platform: Application Server Administration Guide you will see that error message: Attempt to connect to peer failed. Attempt to connect to peer (name) for cluster name (ID) failed with exception message. Explanation: Load balancing was configured to use several machines to balance the client load, but was unable to connect to one of the other peers as defined in the cluster. Load Balancing will not be able to use that peer at this time. A peer can be another object spawner. Resolution: This message might be seen during initialization due to the fact the other peers or object spawners have not initialized yet. Once they initialize, load balancing will be able to communicate with them. Ensure that the other peers have initialized. I don't know exactly how you have your pooled workspace servers configured but I imagine you have multiple object spawners (where there is a peering relationship between them for sharing load balancing information). It sounds like this communications is broken. I would look for things like spawners not running, firewalls blocking spawners communicating with each other etc. Is the server named mor-sasprd04.server in the error message up and running and the object spawner service running on it?

PaulHomes · ‎10-29-2018

Do you know if the program aml_omr_sync_users.sas is custom written for your organisation or part of the SAS AML Solution? The name of the program suggests AML Open Metadata Repository sync users - i.e. sync users (from AD?) into metadata for AML. Perhaps it manipulates role (IdentityGroup) and capability (ApplicationAction) metadata too but without seeing the code itself it is impossible to tell. I think you may get the best response by following this up with SAS AML specialists in SAS Technical Support, or whoever installed and configured the SAS AML Solution for you - perhaps SAS Professional Services or a SAS Partner?

PaulHomes · ‎10-26-2018

Thanks Jan! ... I'm glad I was able to help a little but I think you should have probably marked your own response as the answer to the post .... since it actually contained the real answer! 😉

PaulHomes · ‎10-21-2018

Those AML applications (and capabilities) shown in the SAS Management Console User Manager role Capabilities tab look possibly site-specific, given the suffixes (BU_JO, BU_PSE etc). I don't have AML so cannot investigate this myself. Does AML create those for you or have you created them for yourself (using ApplicationMetadataUtility)? The capability that has a grey dot in front of its name, and has a grey background to the checkbox, indicates a capability that has been granted through a contributing role. If you look at the Contributing Roles tab, one of the roles in that tab will have had that capability ticked/granted in its own Capabilities tab. Contributed capability grants cannot be un-granted in a role where they have been contributed - they can either be explicitly re-granted in the role where they have been contributed (to always be granted regardless of what happens in the contributing role), or be un-granted in the source contributing role itself. For more info on roles and capabilities I would recommend reading Kathy Wisniewski's SAS Global Forum 2010 Paper (324-2010) Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2 It's several years/versions old now but most of it still applies today and is a quick and easy read. Also tracing capability access can be tricky and time consuming so if you are interested in a commercial tool that can help with that, there's a Capability Reviewer in Metacoda Security Plug-ins that can show who has a capability and how they get it (included which contributing roles provide might be providing it). I wrote a blog post about it a few years ago that has some examples.

PaulHomes · ‎10-17-2018

Hi @JuanS_OCS, When I was doing some work with the REST API, I was also seeing a filtered list of rules returned (dozens instead of hundreds), which appeared to be related to not opting in to the assumable group SASAdministrators. I just tried the CLI when logged in as an admin and it returned hundreds of rules. When logged in as a normal user it returned less than 50 rules. I don't see any CLI option to opt in/out of assumable groups so perhaps double check you are logged in as a member of SASAdministrators? Cheers Paul

PaulHomes · ‎10-17-2018

In addition to the suggestions by @JuanS_OCS, if you are doing this to sync user/group config between SAS environments (which are not already syncing to a common source like AD/LDAP), then you could also look at using the SAS User Import Macros. Whilst these are normally used to sync to external directories they can also be used to sync between environments. See SAS Sample 42251: Partial Promotion of User and Group Metadata for an example.

PaulHomes · ‎10-17-2018

It's good to hear your testing went well. If you want the web apps to use the aliased in redirections (instead of the physical host names) then that will require some server changes as mentioned in my first reply - see Overview of Updating Host Name References and Specifying Connection Properties. If you only want the clients to see the alias then you could look at the external connection properties. If you want the server side components to use the aliases too then go through a host name change process. In the past when I have used DNS aliases to provide the ability to switch between primary and DR sites I also made sure the primary and DR sites always saw themselves with the aliases so they never tried to interact with each other regardless of the state of the client DNS resolution (you can use static /etc/hosts mappings on the servers or split-horizon DNS depending on how complex your environment is) Using DNS aliases there is the potential for disruption after changing the DNS alias definitions due to caching and propagation lags. If you want to avoid this then you could look at IP switch features instead. I remember a discussion of this in an old SAS Global Forum 2011 paper (358-2011) "Considerations for Implementing a Highly Available or Disaster Recovery Environment" by Diane Hatcher and Jochen Kirsten. As that paper is several years old now you might want to talk to your network admins to see what the current best practices are regarding rapid host/IP switch-over capabilities.

PaulHomes · ‎10-17-2018

From what you have said it sounds like aliases may work for you on the client, without any server configuration, as long as: the clients will still be able to resolve any real host names that get returned from the servers you are not using HTTPS for the mid-tier (where you may otherwise get cert errors unless the certs also include the aliases as SANs) the web apps will most likely redirect the clients to use the real host names after the initial connection Otherwise, you may need to do some server side re-config to get it to factor in the aliases too. Best thing to do is to try it out in a dev/test/playpen environment. I would do a quick test myself except my environment uses TLS and the certs only have the real host names.

PaulHomes · ‎10-10-2018

Yes, you can use DNS aliases (CNAMEs) to refer to your SAS servers. I have done this several times in the past. It can be useful when you want to use meaningful logical names when the servers have obscure physical names, or when you want to have the option to easily switch from one SAS platform to another (during upgrades, DR etc). For best success you should plan carefully and get help from SAS Professional Services or a local SAS Partner if you are not confident. Using aliases is more easily done during SAS installation/deployment but can also be done post-deployment. Some things to consider: Are you doing this just as a convenience for users/clients or for servers to communicate with each other too? A SAS app/client/server will often get a host name from metadata/config for the client to use for subsequent connections (you will see this with the web apps) so, for consistency, you may want/need to use the DNS aliases in metadata/config too. e.g. see Overview of Updating Host Name References and Specifying Connection Properties. If you are using IWA / Kerberos you will want to make sure you add Service Principal Names (SPNs) for the aliases as well as the actual names. If you are using SSL/TLS then make sure your certificates include the DNS aliases as Subject Alternative Names (SANs) as well as the actual names (unless wildcards will suffice).

Online Status	Offline
Date Last Visited	‎02-11-2025 08:08 PM