Scenario:
When EG clients connect to SAS using stored credentials, the following code works as intended.
When EG clients connect to SAS using IWA, the code fails with ERROR: CLI error trying to establish connection: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
All other code works as desired, regardless of EG authentication. This leads me to believe that there's a post-setup SAS/CONNECT configuration I've missed, but I can't seem to locate it.
TIA,
Jim
SAS Admin, Central WA Univ
OPTIONS AUTOSIGNON=Yes SASCMD="!sascmd"; %LET StuCenLib =; %LET StuEndLib =; rsubmit task1 wait=no sysrputsync=yes; LIBNAME SS META LIBRARY="Static_Store"; data Student_Census; set SS.STU_Student_Census; run; %sysrput StuCenLib=%sysfunc(pathname(work)); %sysrput task1code = &sysinfo; LIBNAME SS CLEAR; endrsubmit; %PUT NOTE: %DateTimeStamp First data step began; rsubmit task2 wait=no sysrputsync=yes; LIBNAME SS META LIBRARY="Static_Store"; data Student_End; set SS.STU_Student_End; run; %sysrput StuEndLib=%sysfunc(pathname(work)); %sysrput task2code = &sysinfo; LIBNAME SS CLEAR; endrsubmit; %PUT NOTE: %DateTimeStamp Second data step began; waitfor _all_ task1 task2; %PUT NOTE: %DateTimeStamp All data steps ended; rget process=task1; rget process=task2; %PUT StuCenLib = &StuCenLib, StuEndLib = &StuEndLib; %PUT Task1Code = &Task1Code, Task2Code = &Task2Code; LIBNAME StuCen "&StuCenLib"; LIBNAME StuEnd "&StuEndLib"; %PUT NOTE: %DateTimeStamp Proc sql began; proc sql; CREATE TABLE Cen_End AS SELECT sc.STRM , sc.EMPLID FROM StuCen.Student_Census AS sc LEFT JOIN StuEnd.Student_End AS se ON se.STRM = sc.STRM AND se.EMPLID = sc.EMPLID WHERE missing(se.EMPLID) ; quit;
We've just been through a similar exercise ourselves, trying to get IWA and SSO going across all SAS clients and interfaces. This might be one thing you have missed and most likely need:
SAS Help Center: Windows Privileges
When your Connect Spawner runs under your server's local system account, then the above configuration must be done.
Hm...
That was exactly what I asked our domain admins to do, but in reviewing the servers' delegation settings, I see that they set "Use any authentication protocol," not "Use Kerberos only" (I can view, but not change things in Active Directory Users and Computers).
Interesting that it works for everything except rsubmit...
I'll have them change this in my TST environment and see what shakes out.
T'anxQ!
..actually...
I just reviewed the docs I referenced in the PowerShell script I built for them, and https://go.documentation.sas.com/doc/en/bicdc/9.4/bisecag/p1jg2eif6qym5qn1co79sdclcyt7.htm says to set it as "Use any authentication protocol."
I thought I "smelled" an apparent disconnect in the SAS admin docs, but this discussion brought it together for me.
I'll let you know what happens.
Hello @JimmyJoeBob
I see this in the first post "ERROR: CLI error trying to establish connection: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user 'NTAUTHORITY\ANONYMOUS LOGON'."
This is an expected behavior.
SQL server needs credential to allow connection.
Sajid,
As I outlined, SAS and the client are configured for Integrated Windows Authentication (IWA) and SAS and Active Directory are configured for Kerberos Constrained Delegation (KCD). This configuration works for every other use case except rsubmit. Calls to rsubmit work when the client is authenticated using stored credentials, which, from a security perspective is suboptimal.
Thx,
My domain admins changed the delegation to "Trust this computer for delegation to any service (Kerberos only)" and saw no change in MPCONNECT behavior. That's mildly encouraging!
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.