BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
jwward65
Obsidian | Level 7

I have found lots of information regarding the CASHostAccountRequired group and everything I found says to use this functionality, the user needs to have a CAS Host Account, but yet I cannot find any information or documentation on how to actually accomplish this.  Does anyone have any guidance on this?

 

Scenario:

We have ALL users in Active Directory groups that are in the custom CASHostAccountRequired group, but yet only some users are not able to start a CAS session!  I can't figure out why this doesn't effect ALL users.  

 

jwward65_2-1634219598357.png

 

jwward65_0-1634219387107.png

 

1 ACCEPTED SOLUTION

Accepted Solutions
jwward65
Obsidian | Level 7

Ended up figuring it out with SAS TS.  Apparently the SSSD service on one of the nodes wasn't refreshing and any new users added to the Active Directory group wasn't being recognized on this node.  In working with our Linux admin, once SSSD was stopped, cache cleared and restarted, it resolved the issue. 

 

For reference, this was what was run to refresh the SSSD service...

 

service sssd stop ; rm -f /var/lib/sss/db/* /var/log/sssd/* ; service sssd start

 

Thanks,

John

 

View solution in original post

2 REPLIES 2
gwootton
SAS Super FREQ
If a user is a member of the custom group CASHostAccountRequired, it instructs their CAS session to start as that user rather than the user "cas". So by a CAS host account we mean that the user must exist on the CAS server hosts. I'm guessing that the users who cannot start CAS sessions are not able to own processes on the CAS server hosts. Sounds like however you are provisioning accounts on the servers, like PAM/SSSD, is pulling a different set of identities than Viya.
--
Greg Wootton | Principal Systems Technical Support Engineer
jwward65
Obsidian | Level 7

Ended up figuring it out with SAS TS.  Apparently the SSSD service on one of the nodes wasn't refreshing and any new users added to the Active Directory group wasn't being recognized on this node.  In working with our Linux admin, once SSSD was stopped, cache cleared and restarted, it resolved the issue. 

 

For reference, this was what was run to refresh the SSSD service...

 

service sssd stop ; rm -f /var/lib/sss/db/* /var/log/sssd/* ; service sssd start

 

Thanks,

John

 

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
  • 2 replies
  • 1027 views
  • 0 likes
  • 2 in conversation