- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Scenario:
- SAS 9.4 M8 in Windows Server 2022 x64
- SAS EG 8.4 on Windows 10 x64
- All hosts are in the same AD forest/domain
- SAS was configured during installation for Integrated Windows Authentication (IWA), using a plan file recently produced by SAS engineers (our previous one didn't include SAS/CONNECT).
- SASMeta - Logical Metadata Server is configured for Host authentication, Security Package = Kerberos
- - sspi option is part of the service startup arguments
- SASApp - Logical Workspace Server is configured for Host authentication, Security Package = Kerberos
- Connection: Connect Spawner is configured for Integrated Windows Authentication, DefaultAuth domain
- Connect Spawner servide includes -sspi REG_NONE in its Parameters key
- Object Spawner includes -sspi REG_NONE in its Parameters key
- Kerberos Constrained Delegation (KCD) is configured and working for all other SAS usage (remote SQL, file shares).
- The library in the LIBNAME statement is an ODBC connection to a database on a remote MS-SQL server that authenticates using domain credentials.
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;
- Tags:
- rsubmit
- sas_connect
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
..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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Greg Wootton | Principal Systems Technical Support Engineer
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
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!