BookmarkSubscribeRSS Feed
bheinsius
Lapis Lazuli | Level 10

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

8 REPLIES 8
bheinsius
Lapis Lazuli | Level 10
There seem to be duplicate SPN's for SAS/<hostname>, that's not right for sure. I will have one removed and report back.
StuartRogers
SAS Employee

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

bheinsius
Lapis Lazuli | Level 10

Hi @StuartRogers 

 

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

 

StuartRogers
SAS Employee

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

bheinsius
Lapis Lazuli | Level 10

Hi @StuartRogers 

 

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

 

 

 

 

 

StuartRogers
SAS Employee

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

bheinsius
Lapis Lazuli | Level 10

Hi @StuartRogers 

 

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

StuartRogers
SAS Employee

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

 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

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.

Discussion stats
  • 8 replies
  • 2116 views
  • 2 likes
  • 2 in conversation