About PaulHomes

PaulHomes · ‎09-27-2018

This looks like a duplicate of https://communities.sas.com/t5/Administration-and-Deployment/SAS-EM-The-application-has-encountered-an-unexpected-problem/m-p/498854/highlight/true#M14420 but with the addition of the console stack trace containing the kerberos ticket error. I'd suggest posting that extra info in the original post as the people who helped you on that post might miss this new one.

PaulHomes · ‎09-27-2018

Hi KJ, When you are manually adding AD users via SAS Management Console User Manager you do not need to specify a password. Think of that user as a reference to an AD user and the user id is the key (linking the host/AD authenticated user to the SAS identity in metadata). AD authenticates the user but SAS needs an entity within SAS metadata to use for (SAS metadata) access control decisions, to associated private user content, store user preferences etc. The SAS metadata groups have no connection to AD groups unless you set up a sync process to effectively copy/replicate the desired set of groups into SAS metadata. When you have a small number of users it may be easier to manage them and the local SAS groups manually like this. As the number of users increases people often turn to AD synchronisation to automate this process using AD as the source of user and group information. If you're a SAS coder, take a look at the User Import Macros section of the SAS® 9.4 Intelligence Platform: Security Administration Guide. We also have a commercial Metacoda Identity Sync plug-in that makes this easier to implement for those who are not coders (or do not want to keep maintaining code). To find out more about managing users, groups and access (and many other SAS admin topics) I would wholeheartedly recommend the SAS Platform Administration: Fast Track course from SAS Education. In terms of documentation I would start with the About User Administration section in the SAS® 9.4 Intelligence Platform: Security Administration Guide. That book also has some nice worked examples of group-based access control for SAS metadata content in the Access to Metadata Folders section. Another document to read is the SAS® 9.4 Management Console: Guide to Users and Permissions. In addition to the SAS documentation I would definitely recommend looking at some of the best practice papers for proven patterns that make this much more manageable: Five papers on Recommended SAS 9.4 Security Model Design (part 1 & part 2) as published by @DavidStern from the SAS Global Enablement and Learning (GEL) team. SAS Global Forum 2011 paper 376-2011: Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark by @CecilyHoffritz and @JohannesJørgensen from SAS Institute Denmark. SAS Global Forum 2017 paper: Getting Started with Designing and Implementing a SAS 9.4 Metadata and File System Security Design by @angieh from SAS Consulting Cheers Paul

PaulHomes · ‎09-26-2018

Hi KJ, When you say AD integration, do you mean the host OS has been configured for AD integration (joined a domain) so that you can log in as an AD user and use AD groups for file system access controls, or do you mean that SAS has also been configured to synchronize SAS metadata groups with corresponding AD groups so that you can, in effect, use AD groups for SAS metadata access controls. Unlike SAS Viya, the SAS 9.4 platform (underlying the older SAS VA 7.3 release) does not use native AD/LDAP groups for access control. Instead SAS admins usually set up a scheduled process whereby a set of AD groups is replicated in SAS (as similar/same-named metadata groups) and any changes to those AD groups (name, members etc) are applied to the SAS groups on a regular basis. If you can provide a bit more background on how AD integration has been done in your environment then you'll be able to get more focused help. Also providing a worked example of what you have done with respect to SAS access controls in SAS Management Console will help too. When you say no joy, what does that mean? Do they have access when they shouldn't? Have no access when they should? What is it they are trying to do that is failing? What are they trying to access? What type of access controls have been applied (ACTs, explicit permissions), for what groups/users on what objects? Thanks Paul

PaulHomes · ‎09-26-2018

Hi Jan, I'd start by looking at Lev1/SASMeta/MetadataServer/trustedPeers.xml to see who the SAS Metadata Server has been configured to accept as trusted peers. Has it been modified from the defaults of the initial install? Then check the series of config files used (with a starting point of sasbatch.sh) on the problem node and especially Lev1/metadataConfig.xml to see if it is pointing to the wrong metadata server. Also check DNS resolution for the metadata server node host name(s) is working as expected on that node. As Juan suggested, have a look at the metadata server logs. Is there a failed connection on the metadata server from the problem node when the job is run? Is there any connection registered at all? If so, as whom? Does it fail with a specific error? Verify who the Linux process owner of the batch job is? Do they have a corresponding SAS metadata identity? Try running a simple test by SSH-ing into the machine as the same Linux user id and running something like this to see if the metadata libraries can be assigned: /opt/sas/config/Lev1/SASApp/BatchServer/sasbatch.sh -sysin ~/simple-proc-options.sas -log ~/simple-proc-options.log Hope this helps. Cheers Paul

PaulHomes · ‎09-26-2018

What makes you say Trusted Peer Connections doesn’t apply?

PaulHomes · ‎09-21-2018

I don't have any suggestions for command-line but if you can find what you need to modify in metadata then you could potentially use the SAS 9.4 Open Metadata Interface from Base SAS, Java or .Net. An understanding of the SAS 9.4 Metadata Model is also required. As @SASKiwi mentions however there is potential for some serious damage so thorough testing in a throwaway playpen environment is highly recommended. When I want to find potential metadata objects in this type of scenario I use our Metacoda Metadata Explorer Plug-in to search for something like 'dav' across all character attributes on all SAS model type objects and then when I find what I want I try to narrow the search into an XMLSELECT style query that I can use with the SAS metadata API to find the exact set of objects I want (and potentially update them). Changing lots of Foundation Services DAV configs (after configuring HTTPS) is something that I have done in the past but I can't remember whether I used code to change them or just to review them to make sure I'd changed them correctly via point and click. I had a quick look to see if I had any old code for it but couldn't find anything so perhaps I decided point and click was quicker for a one-off job as @SASKiwi mentioned 😉 If you want to have a go, to update or just review manual changes, you may find the following 2 queries useful to get you started on where to look (the curly brackets indicate an XMLSELECT style query to the Metacoda Metadata Explorer plug-in - so remove those to use the XMLSELECT query in SAS Metadata API code): 1) This one finds Information Service XML configs used by Foundation Services containing WebDAV attributes: {{{ TextStore[@TextRole='initialization' and @StoredText contains 'WebDAV'] }}} 2) This one finds a WebDAV mapping for the SAS Folders root folder. {{{ Document[@URIType='DAV'] }}}

PaulHomes · ‎09-21-2018

Have a look at the SAS System Requirements doc for your operating system and SAS version e.g. System Requirements for SAS® 9.4 Foundation for Linux for x64 - inside those PDFs you will find a section for SAS/ACCESS Interface to DB2 (assuming that is what you are using to access DB2 from SAS).

PaulHomes · ‎09-18-2018

As @alexal suggested, installing sssd-krb5-common will pull in additional packages including the standard open source GSSAPI libraries. In terms of specific packages, in my environment /usr/lib64/libgssapi_krb5.so is a symlink (provided by the package krb5-devel) to libgssapi_krb5.so.2.2 (provided by the package krb5-libs). The krb5-libs package is one of the dependencies of sssd-krb5-common. A while ago I was having trouble with a missing /usr/lib64/libgssapi_krb5.so -> libgssapi_krb5.so.2.2 symlink so created it manually. Later on I found that the krb5-devel package provides it. I only use realmd to provide the basic setup for IWA on Linux now as I find it makes it significantly easier: https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ (I just updated the blog post to add a note about krb5-devel)

PaulHomes · ‎09-18-2018

Start by reviewing all of the information in the SOE (email) you would have got from SAS along with the SAS 9.4 Intelligence Platform: Installation and Configuration Guide and any specific documentation for the solutions. However, if you are new to SAS and have never done a multi-machine SAS platform installation before, then I would strongly recommend getting help from SAS Professional Services or a local SAS Partner. You will have a much greater chance of success if you do so and they will also be able to help you make choices that may be difficult or time-consuming to change after the deployment.

PaulHomes · ‎09-17-2018

As @alexal mentioned you should be able to configure the server so you don't need to specify any extra details on the client other than the basic host name, port and to use IWA. SPNs should be added in AD so the client user doesn't have to worry about them. Just so you know I get that warning message in my Linux + IWA lab environment when IWA connection is successful: 2018-09-18T10:48:43,814 INFO [00689123] :paul - New client connection (57834) accepted from server port 8591 for IWA user paul. Encryption level is Credentials using encryption algorithm AES. Peer IP address and port are [192.168.2.101]:52435 for APPNAME=SAS Enterprise Guide. 2018-09-18T10:48:43,859 WARN [00689123] :paul - The destination buffer size was not sufficient for the requested password. 2018-09-18T10:48:43,884 INFO [00689123] :paul - Created process 14210 using credentials paul (child id 94). 2018-09-18T10:48:44,490 INFO [00689130] :sas - New out call client connection (57848) for launched server (child 94). Peer IP address and port are [192.168.2.27]:54050. 2018-09-18T10:48:44,497 INFO [00689130] :sas - Client connection 57834 for user paul closed. 2018-09-18T10:49:41,026 INFO [00000009] :sas - Client connection 57848 for user paul closed. 2018-09-18T10:49:41,152 INFO [00689122] :sas - Process 14210 owned by user paul (child id 94) has ended. I don't know why I am getting that buffer size warning but it does not seem to have any obvious impact. If anyone else knows how to get rid of it I'd be keen to hear. 🙂 So I think you need to focus on that "Access denied" error. Have you added the Audit.Authentication trace level logging for the object spawner as @alexal suggested?

PaulHomes · ‎09-13-2018

Thanks for the feedback. Glad the info's helpful. 1) When clients (such as SAS EG, SAS MC, web browser etc) want to work with a service using kerberos they construct an SPN using a host name. Some clients/users may use FQDN some may use short names. In some scenarios they may use host name aliases. Essentially all of the possible host names that could be used should be registered in SPNs for that service (account). If a client uses a host name to construct an SPN which is not found then the connection will fail. You add multiple SPNs to handle all the possibilities. Perhaps if you can guarantee only one form will be used then you might get away with one SPN, but I have always used both FQDN and short name versions (plus any DNS aliases). I wouldn't skimp here ... it's very quick and easy to add them ... but it's tricky and time consuming to troubleshoot them 😉 2) I believe that recommended security practice (to limit the scope of access/changes when a keytab is lost/replaced) is to use a different account/keytab per service. You will see in Stuart's SASGF 2016 paper he says: There is a choice as to either using one user account per service or link multiple services to one account. While having multiple services linked to one account can simplify the management of the environment, it will mean that any security breach of this account impacts all the services. As such, many organizations will require a separate user account per service. So in your split metadata/compute server environment, you may want to use separate service accounts/keytabs for the the metadata server machine and object spawner (compute) machine. This is just like the examples given Stuart's SASGF 2016 paper. In my blog posts you may only see one used for both because in my small lab environment I have all the server components on one host (and it's easier to write about one). If you end up configuring web for IWA then you will also want one for the mid-tier. You should also consult with your organization's security team on their policies in this regard (to save you time possibly having to make changes later). ... and yes the keytab file should only be accessible to the process owner of the SAS services (often called sas or sasinst). I chown sas:sas and chmod 400 mine.

PaulHomes · ‎09-12-2018

Thanks for the mention @JuanS_OCS! Because this is a question I have been asked before and I thought it would be useful for Metacoda customers too, I wrote up a quick blog post on the topic: Metacoda Plug-ins Tip: User’s Group Content Admin Permissions (Identity Permissions Explorer). The Identity Permissions Explorer is one of the Metacoda Plug-ins that Juan mentioned. It is used to find out what objects a user has access to and what level of access they have on those objects. This can, of course, also be used on portal permission trees. By finding the portal permissions tree where a user has +WM we can see which ones they are group content admin for. This particular solution involves a commercial product but, if you are interested in trying it out, you can register for a free 30 day evaluation to use in your own environment. If it's a one-off question then you can use the evaluation to answer it. If it's an ongoing requirement then we hope you'll find this and the other plug-ins useful enough to warrant looking into licensing options.

PaulHomes · ‎09-12-2018

You could enhance that code by pulling out the email(s) for the user, but personally I would suggest you just reuse code already provided by SAS and use the supplied SAS %MDUEXTR macro. You point that macro at a library and it will extract user email, phone, location, and group/role membership info (and more) from metadata into Canonical Tables in that library. If the info you need is all in those tables it is much easier than having to get to grips with the SAS Metadata API and the SAS Metadata Model. I would only suggest writing metadata API code if you need something that is not already in those canonical tables.

PaulHomes · ‎09-12-2018

If you are after general resources for SAS Administrators I would suggest starting at https://support.sas.com/en/sas-administrators.html More specifically read the extensive admin documentation at https://support.sas.com/documentation/onlinedoc/intellplatform/index.html

PaulHomes · ‎09-10-2018

No problem. It was an interesting exploration.

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