DATA Step, Macro, Functions and more

Remote submitting on Virtual Server - permissions issue for libraries

Reply
Occasional Contributor
Posts: 9

Remote submitting on Virtual Server - permissions issue for libraries

Hi All,

 

It's been many a year since I came and asked you guys for help but this one has had many of us bashing our heads against the wall! We are about to migrate a physical server that exists here to a virtual server. All permission settings have been retained according to the I.T. guys, however I seem to get this authorization error when rsubmitting from the new virtual server.

 

Below is a test log of my interactions; (yeah I know we're not exactly running the most up to date version of SAS! I think it's SAS 9.1.3).

 

87   %LET HADES_1=hades.XX.XXXXX.corp 23; *you may need to specify a port depending on config
87 !  :) 23 is the default;
88   OPTIONS COMAMID=TCP REMOTE=HADES_1;
89   signon HADES_1;
NOTE: Remote signon to HADES_1 commencing (SAS Release 9.02.02M3P041310).
NOTE: Unable to open SASUSER.PROFILE. WORK.PROFILE will be opened instead.
NOTE: All profile changes will be lost at the end of the session.
NOTE: Copyright (c) 2002-2003 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) 9.1 (TS1M3)
      Licensed to XXXXX, Site XXXXX.
NOTE: This session is executing on the NET_ASRV  platform.



NOTE: SAS 9.1.3 Service Pack 3

NOTE: SAS initialization used:
      real time           0.21 seconds
      cpu time            0.13 seconds

NOTE: Remote signon to HADES_1 complete.
90   %LET HADES_2=hades-clone.XX.XXXXX.corp;
91   OPTIONS COMAMID=TCP REMOTE=HADES_2;
92   signon HADES_2;
NOTE: Remote signon to HADES_2 commencing (SAS Release 9.02.02M3P041310).
NOTE: Unable to open SASUSER.PROFILE. WORK.PROFILE will be opened instead.
NOTE: All profile changes will be lost at the end of the session.
NOTE: Copyright (c) 2002-2003 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) 9.1 (TS1M3)
      Licensed to XXXXX, Site XXXXX.
NOTE: This session is executing on the NET_ASRV  platform.



NOTE: SAS 9.1.3 Service Pack 3

NOTE: SAS initialization used:
      real time           0.07 seconds
      cpu time            0.04 seconds

NOTE: Remote signon to HADES_2 complete.
93   rsubmit HADES_1;
NOTE: Remote submit to HADES_1 commencing.
1    data _null_;
2    put "test";
3    run;

test
NOTE: DATA statement used (Total process time):
      real time           0.01 seconds
      cpu time            0.00 seconds


NOTE: Remote submit to HADES_1 complete.
94
95   rsubmit HADES_2;
NOTE: Remote submit to HADES_2 commencing.
1    data _null_;
2    put "test";
3    run;

test
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds


NOTE: Remote submit to HADES_2 complete.

96   rsubmit HADES_1;
NOTE: Remote submit to HADES_1 commencing.
4    libname test "\\hades\data";
NOTE: Libref TEST was successfully assigned as follows:
      Engine:        V9
      Physical Name: \\hades\data
NOTE: Remote submit to HADES_1 complete.
97   rsubmit HADES_2;
NOTE: Remote submit to HADES_2 commencing.
4    libname test "\\hades-clone\data";
ERROR: User does not have appropriate authorization level for library TEST.
ERROR: Error in the LIBNAME statement.
NOTE: Remote submit to HADES_2 complete.

 

 

Yes I understand that naming the server after the underworld probably doesn't help, but here you can see that in the test, upon signing on to both hades 1 and hades 2 (2 being the new virtual clone) that I can write a DATA _NULL_ step to both without issue, and I can still assign a library on hades 1. However, for some reason I get this authorization error when trying to define a libname on the new server which is a virtual clone of the first server.

 

Important to note that the server is definitely a clone, the folder structure is the same, and the same folder above definitely exists on the clone. I.T. have spent all day trying to fiddle around with the permission settings to try and fix the problem and nothing appears to work. They are adamant that my permission settings are exactly the same copied across from the physical server onto the virtual server.

 

Strangely, if I sign on using a script it seems to work ok. Evidenced below;

 

98   signoff HADES_2;
NOTE: Remote signoff from HADES_2 commencing.
NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414
NOTE: The SAS System used:
      real time           4:31.73
      cpu time            0.04 seconds

NOTE: Remote signoff from HADES_2 complete.
99   filename rlink "C:\Program Files\SAS\SASFoundation\9.2\connect\saslink\tcpwin.scr" ;
100  %LET HADES_2=hades-clone.XX.XXXXX.corp;
101  OPTIONS COMAMID=TCP REMOTE=HADES_2;
102  signon HADES_2;
NOTE: Remote signon to HADES_2 commencing (SAS Release 9.02.02M3P041310).
NOTE: Start of script file trace.
TRACE:    Echo on;
TRACE:    Log 'NOTE: Script file 'tcpwin.scr' entered.';
NOTE: Script file 'tcpwin.scr' entered.
TRACE:    If not TCP then goto notcp;
TRACE:    If signoff then goto signoff;
TRACE:    Waitfor    'Username:',
TRACE:               'Hello>': ready,
TRACE:               120.0 seconds: noprompt;
Username:
TRACE:    Input display 'Userid?';
TRACE:    Type lf;
TRACE:    Waitfor    'Password:',
TRACE:               120.0 seconds: nolog;
Password:
TRACE:    Input nodisplay 'Password?';
TRACE:    Type lf;
TRACE:    Waitfor    'Hello>',
TRACE:               'access denied': nouser,
TRACE:               120.0 seconds: timeout;
Hello>
TRACE: ready:
TRACE:    Log 'NOTE: Logged onto Windows... Starting remote SAS now.';
NOTE: Logged onto Windows... Starting remote SAS now.
TRACE:    Type 'sas -device grlink -nosyntaxcheck' lf;
TRACE:    Waitfor    'SESSION ESTABLISHED',
TRACE:               120.0 seconds: nosas;
SESSION ESTABLISHED
TRACE:    Log 'NOTE: SAS/CONNECT conversation established.';
NOTE: SAS/CONNECT conversation established.
TRACE:    Stop;
NOTE: End of script file trace.
NOTE: Unable to open SASUSER.PROFILE. WORK.PROFILE will be opened instead.
NOTE: All profile changes will be lost at the end of the session.
NOTE: Copyright (c) 2002-2003 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) 9.1 (TS1M3)
      Licensed to XXXXX, Site XXXXX.
NOTE: This session is executing on the NET_ASRV  platform.



NOTE: SAS 9.1.3 Service Pack 3

NOTE: SAS initialization used:
      real time           0.17 seconds
      cpu time            0.10 seconds

NOTE: Remote signon to HADES_2 complete.
103  rsubmit HADES_2;
NOTE: Remote submit to HADES_2 commencing.
1    data _null_;
2    put "test";
3    run;

test
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds


NOTE: Remote submit to HADES_2 complete.
104  rsubmit HADES_2;
NOTE: Remote submit to HADES_2 commencing.
4    libname test "\\hades-clone\data";
NOTE: Libref TEST was successfully assigned as follows:
      Engine:        V9
      Physical Name: \\hades-clone\data
NOTE: Remote submit to HADES_2 complete.

 

 

The only difference here is that SAS prompts for a username and password (Windows) before allowing me to continue. But then after this point everything looks ok and the library assigns without problem.

 

I understand that this might not be something that is easy to pin point, but if any of you have had an issue like this before and managed to figure out a solution I would be much appreciative of your input!

 

I have a feeling it will be something really simple, but it's been playing us up for almost 2 days now.

 

Cheers guys

Super User
Posts: 3,857

Re: Remote submitting on Virtual Server - permissions issue for libraries

[ Edited ]

I suspect the key to your problem is you appear to be using IWA (Integrated Windows Authentication) for your first SIGNON test as you are not supplying a user name. So you are relying on your client session delegating its authentication credentials to the server sessions.

Then when you define a LIBNAME using the UNC convention \\ServerName\Folder, that is a second level of delegation.

 

So it appears HADES_1 is set up correctly for two-level delegation of user credentials but HADES_2 is not. You appear to be using Windows servers so I suggest you check out the Kerberos SPN settings of both of your servers to see if anything is different:

setspn -i HADES_1 or _2. See this link:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc...

 

Ask a Question
Discussion stats
  • 1 reply
  • 87 views
  • 0 likes
  • 2 in conversation