Hi,
I followed Stuart Rogers' blog at https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-3-5-Object-Spawner-with-Kerberos/ta-... to connect EG83 to a SAS Viya 3.5 Workspace Server on Windows, using Kerberos. I created SPN's and defined constrained delegation.
In EG, I set the Security Package in the SAS Workspace Server definition explicitly to Kerberos, the Workspace Server session starts. The Object Spawner log mentions:
IWA context established using NTLM package
I had expected Kerberos here instead of NTLM, is that correct?
I then try to start a CAS session from that Workspace Server and get the following errors
28 options cashost=localhost; 29 options casport=5570; 30 cas; ERROR: Error in SSPI function AcquireCredentialsHandle. Error -2146893042 (No credentials are available in the security package ). ERROR: Unable to load extension: (tkcident) ERROR: The Kerberos extension failed to load. Kerberos is not functional in this environment. ERROR: Unable to connect to Cloud Analytic Services localhost on port 5570. Verify connection parameters and retry.
Any ideas?
- Bart
Hello @bheinsius,
A good thing to remember is that IWA is not just Kerberos, it is also NTLM. Essentially with Windows systems it will always attempt Kerberos (so long as they are different hosts), but it will fallback to NTLM if something goes "wrong". Having duplicate SPNs would definitely fall into the something "wrong" category 😀.
When EG attempts to obtain the service ticket for the given SPN this will fail if duplicate SPNs are registered. At that point "IWA" will drop back to NTLM. So if you are expecting Kerberos and the logs show NTLM it's good practice to walk back through the prerequisites for Kerberos (check the SPN, check availability of local TGT, ensure processes are running on separate hosts).
I hope removing the duplicate SPNs resolves your issues.
Thank you for your time.
Stuart
I removed the SPN for the SAS/<computer-account> but it returned right after restarting Viya.
Checking the logs I see that the SAS Connect Spawner registers an SPN:
2021-03-04T16:45:30,543 INFO [00000008] :SYSTEM@STASASVIYAP01 - SPN registration succeeded for current host.
It doesn't say it's the SPN for the SAS service class but I think it is.
Should the SAS/CONNECT service also be running as the spawner service account?
And should its usermods file then also have this line:
Set USERMODS_OPTIONS=-sspi
and its Windows Service re-installed?
Thanks for your time,
Bart
Hello @bheinsius,
Yes if you have the SAS/CONNECT spawner running on the host as the localsystem account this will automatically register the SAS/hostname SPN against the computer object. So yes you'll need to switch the SAS/CONNECT spawner to run as the same service account you are using for the Object Spawner. I would also recommend, as you've pointed out, adding the -sspi option to the usermods as covered in the SAS Viya 3.5 Administration Guide.
Thank you for your time.
Stuart
Removing the duplicate SPN worked as the spawner log now says:
IWA context established using Kerberos package.
I now see the Workspace Server running under my account on the Viya server.
The next step is connecting to CAS from that Workspace Server session.
The SPNs are there:
C:\Users\svc-sasinst>setspn -Q SAS/sasviya35win.eom.local Checking domain DC=eom,DC=local CN=svc-sasspawner,OU=Admins,DC=eom,DC=local SAS/sasviya35win SAS/sasviya35win.eom.local Existing SPN found!
I configured constrained delegation for the computer account:
dn: CN=sasviya35win,OU=VirtualMachines,DC=eom,DC=local changetype: add msDS-AllowedToDelegateTo: sascas/sasviya35win.eom.local msDS-AllowedToDelegateTo: sascas/sasviya35win
I set the SAS_CONSTRAINED_DELEG_ENABLED environment variable to 1. From the SAS Workspace Server session:
28 %put NOTE: %sysget(SAS_CONSTRAINED_DELEG_ENABLED); NOTE: 1
But connecting to CAS fails:
28 options set=CASCLIENTDEBUG=1; 29 options cashost="sasviya35win.eom.local" casport=5570; 30 cas casauto; NOTE: HOMEDRIVE: C: NOTE: HOMEPATH: \Users\svc-sasinst NOTE: Client is using the token identity provider NOTE: Calling ClientContextInit NOTE: First call to initialize context ERROR: Error in SSPI function InitializeSecurityContext. Error -2146893042 (No credentials are available in the security package ). ERROR: Access denied. ERROR: Unable to connect to Cloud Analytic Services localhost on port 5570. Verify connection parameters and retry.
Did I miss a step?
Thanks,
Bart
Hello @bheinsius,
If you have the SPN registered against a service account:
CN=svc-sasspawner,OU=Admins,DC=eom,DC=local
Then you need to set the constrained delegation options for the service account and not the computer account.
Thank you for your time.
Stuart
I'm sorry, I had included the wrong output, I have constrained delegation setup for the service account:
ldifde -f delegation.ldf -d "CN=svc-sasspawner,OU=Admins,DC=eom,DC=local" -l msDS-AllowedToDelegateTo dn: CN=svc-sasspawner,OU=Admins,DC=eom,DC=local changetype: add msDS-AllowedToDelegateTo: sascas/sasviya35win.eom.local msDS-AllowedToDelegateTo: sascas/sasviya35win
Thank you,
Bart
Hello @bheinsius,
So you stated:
I now see the Workspace Server running under my account on the Viya server.
With constrained delegation on Windows we expect to see all workspace server or Compute Server processes to run as the service account which then impersonates the client-user identity. So there is still something not working correctly even though Kerberos has now been used to authenticate to the Spawner. I think you'll need Technical Support to drill into this in more detail than can be achieved by the "back-and-forth" offered here.
Thank you for your time.
Stuart
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.