Library Appearing in EG under only one SASApp Server but assigned to both

[LukeBurvill]

Newbie SAS Admin here, and this one has me stumped. It might be pushing in to the Windows Administration space, but figured I might get lucky and someone has experienced the same issue before.

We have two SASApp servers available in our environment running over separate servers: SASApp and SASAppVA.

Thers is a large Base SAS Library some users want to work with in our environment. Given other concerns with our environment, I would like them to be able to do their work with SASAppVA. The datasets that make up this library are in storage attached to the server that SASApp is running on, and available through a network share open to everyone at the share level, and locked down with folder security from there. It is assigned to both servers in its SMC properties, and is pre-assigned using the native library engine.

However, when checking in EG with my standard user account, this Library appears in Libraries under SASApp but not under SASAppVA. 

I have double checked and my standard user account has Read access on each folder down to where the datasets in this library are stored. I also made sure that the process being spawned when connecting to SASAppVA in EG is spawned with my standard user account, and that account has Logon as Batch on the SASAppVA server. Even though it is apparent from the Library appearing in the SASApp Libraries list, I also double checked my Metadata permissions to this library as well.

So I know that its going to be some sort of permissions issue with my Windows account connecting from one SAS server to the other to access the files in the network share, but I've checked everywhere I can think of and everything seems to be in order.

I feel like I'm missing something obvious, but does anyone have any suggestions of what to check next?

[PaulHomes]

Hi Luke,

Given you are using the same pre-assigned SAS library object, I'm assuming you have set the path for that library to a UNC path that can be used without change on both machines?

Are you by any chance using Integrated Windows Authentication (IWA) for your metadata and workspace server connections? If so I'd check that the SASAppVA machine is trusted for delegation - see https://platformadmin.com/blogs/paul/2012/01/sas-and-iwa-two-hops/ and https://platformadmin.com/blogs/paul/2012/03/sas-and-iwa-verify-trusted-for-delegation/

To help troubleshoot this, what happens when you submit a libname statement in SAS EG (running on SASAppVA) with the same path as specified in the metadata defined library? Do you get any error messages?

Once you get past this accessibility issue, if those tables are large, I'm wondering what the performance will be like with this setup. Where is the storage for those SASApp tables? Local disks on the SASApp machine, SAN, clustered filesystem? If you run into issues check out @MargaretC's collection of posts and papers on managing SAS platform storage and performance: http://blogs.sas.com/content/author/margaretcrevar/ 

Cheers

Paul

[LukeBurvill]

Hi Paul,

Thanks for your help.

That is correct. The library points to the data set folder by UNC path.

Checking both machines in AD using the method described in the links, it would appear neither server is setup for delegation. However, I just noticed I forgot to mention in my original post that using my admin account (within SAS and to both servers) the Library appears under SASAppVA. I was also able to successfully run a libname list on the library using this Admin account.

Running a libname statement on SASAppVA for the same UNC path results in the below errors. 

ERROR: User does not have appropriate authorization level for library SASTEST.
ERROR: Error in the LIBNAME statement.

For the sake of completeness, I ran the same command on SASApp and received the below, with a SASTEST library appearing in the Libraries list under SASApp.

NOTE: Libref SASTEST refers to the same physical library as QSAC_RES.
NOTE: Libref SASTEST was successfully assigned as follows:
Engine: V9

And I'm told by our Infrastructure team that the storage is Fibre attached SAN.

Thanks again,

Luke

[PaulHomes · Accepted solution]

Hi Luke,

From memory that looks like the error you get when you have insufficient file system / network access to the library path. I would double check the Windows share and file system ACLs. Does the other (non-admin) account have the ability to logon to the server to try typing the path into Windows Explorer to test (I'm guessing not).

How are your SAS EG connection profiles configured? Do they use userid+password or IWA? Is it the same for both users or different?

When you look at the properties of SASApp - Logical Workspace Server and SASAppVA - Logical Workspace Server in SAS Management Console, what do you see in the Options tab under Authentication service? Host, UserName/Password, Kerberos etc.

For the definitive how-are-they-connecting answer check the metadata server and object spawner logs for the connection messages. They will indicate the authentication method (IWA, SAS token, etc.) You can see examples at https://platformadmin.com/blogs/paul/2012/06/sas-and-iwa-check-the-logs/

If IWA is being used then you will need to get the domain admins to make the server Trusted for Delegation (or avoid IWA by switching your client connection profile to userid+password). If it's userid+password then you can ignore that and focus on opsys permissions.

Cheers

Paul

[LukeBurvill]

Hi Paul,

The second you asked whether both profiles in EG used the same method it all came together. My standard user account was using IWA from some testing a few months back when we discovered some of the SPNs were missing. I changed the profile, typing my username/password in manually, opened the Library list, and there they were.

I'll have a chat with my Infrastructure team about Delegation between the servers.

There's always that one thing you don't think to test and it takes someone else looking in fron the outside to find it. 

Thanks for your help,

Luke.

[PaulHomes]

No problem Luke. Glad you were able to find the underlying issue.