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

Hi all,

 

A while ago we have configured a group-managed service account for scheduling jobs in SAS Environment Manager, which works great. However, jobs are still being deployed from personal accounts in SAS Studio before they get scheduled using this gMSA. So when a job needs to be modified, it's not possible to simply redeploy a job that was created by another personal account. 

 

So my question is whether it is possible to deploy jobs under a gMSA, just like how jobs can be scheduled by a gMSA. We are currently on Stable 2024.08.

 

Kind regards

1 ACCEPTED SOLUTION

Accepted Solutions
gwootton
SAS Super FREQ
You cannot use a group managed service account to perform actions in SAS Studio unless you logged on to Viya as the service account, the group-managed service account functionality only allows users to run jobs as the service account and see the job execution history of those jobs run by the service account.

One option would be to store the code being executed in SAS Content and then having the deployed job only be a FILENAME statement using the FILESRVC access method pointing to the code in SAS Content followed by an %include of that fileref.

This would then allow the code to be modified in SAS Content without requiring it be redeployed, and modification permissions on the code path could be passed to multiple users or groups.
--
Greg Wootton | Principal Systems Technical Support Engineer

View solution in original post

3 REPLIES 3
gwootton
SAS Super FREQ
You cannot use a group managed service account to perform actions in SAS Studio unless you logged on to Viya as the service account, the group-managed service account functionality only allows users to run jobs as the service account and see the job execution history of those jobs run by the service account.

One option would be to store the code being executed in SAS Content and then having the deployed job only be a FILENAME statement using the FILESRVC access method pointing to the code in SAS Content followed by an %include of that fileref.

This would then allow the code to be modified in SAS Content without requiring it be redeployed, and modification permissions on the code path could be passed to multiple users or groups.
--
Greg Wootton | Principal Systems Technical Support Engineer
HonestBeeFriend
Calcite | Level 5
I see, is there a chance that that the features of an gMSA get expanded in future SAS updates?
gwootton
SAS Super FREQ
I don't think your described use case is part of the purpose of a group-managed service account, so I wouldn't expect such a feature to be added.

If you want multiple users to be able to edit the code you'd want to store the code (the .sas file) in a place where those individual users can edit it, rather than having them edit the code as the service account.

When you use SAS Studio's "Deploy as Job" function, this creates a jobRequest and jobDefinition object, with the jobDefinition containing the code from the program you chose to deploy as a job, and the jobRequest referencing that jobDefinition. That job definition is not stored in SAS Content.

The default rules allow non-administrators update permission only on jobDefinitions they created.

The "Redeploy job" function would update that job definition with any changes to the code, so this could only be done by the user who originally deployed the job.

If you don't use the Deploy as Job function and instead use the Create Job Definition function, this gives you the option to save the deployed job in a given path in SAS Content, so additional permissions can be conveyed based on the permissions set on the path in SAS Content where the job definition is saved.

After doing this, you can use the "Schedule job" option on the job definition to create a job request linked to that job definition.

In this workflow, because the jobDefinition is stored in SAS Content, permissions can be applied based on the storage location and other users could edit it if appropriate permissions are set there.
--
Greg Wootton | Principal Systems Technical Support Engineer

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