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

As title.

There were 3 SAS servcies, by default running by Windows "localsystem" account:

SAS Connect Spawner (BIG5), port 7551

SAS Connect Spawner (English), port 7552

SAS Connect Spawner (UTF8), port 7553

Can I run them by non-administrative account? If yes, what rights need to be granted to that account?

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

Hi Henry,

I don't think there's any difference in the requirements, but I've never yet needed to run the spawner with a different service account.

For further clarification have a look at Windows Privileges in the SAS(R) 9.3 Intelligence Platform: Security Administration Guide.  It states:

Note: In most cases, an object spawner on Windows runs as a service under the local system account. If the spawner instead runs under some other account, that account must be a Windows administrator on the spawner's host and have the Windows user rights Adjust memory quotas for a process and Replace a process level token. These user rights assignments are part of the local security policy for the Windows computer that hosts the spawner.

Other than that I would suggest trying it out and/or following up with SAS tech support.

Cheers

Paul

View solution in original post

4 REPLIES 4
PaulHomes
Rhodochrosite | Level 12

Hi Henry,

Have a look at Defining User Accounts in the SAS(R) 9.3 Intelligence Platform: Installation and Configuration Guide. It states (in part) ...

... the user account that runs the object spawner must meet the following requirements on the object spawner machine:

  • be the administrator or a member of the Windows Administrator's group
  • have the following Windows local user rights:
    • Adjust memory quotas for a process
    • Replace a process level token

Cheers

Paul

Henry47203480
Calcite | Level 5

Paul Homes wrote:

Hi Henry,

Have a look at Defining User Accounts in the SAS(R) 9.3 Intelligence Platform: Installation and Configuration Guide. It states (in part) ...

... the user account that runs the object spawner must meet the following requirements on the object spawner machine:

  • be the administrator or a member of the Windows Administrator's group
  • have the following Windows local user rights:
    • Adjust memory quotas for a process
    • Replace a process level token

Cheers

Paul

But the part you quoted is talking about NOT using Windows service:

On Windows, if you choose how to run your SAS servers using management scripts—instead of running them as Windows services

So I wonder if it's the same for a "Windows Service" case?

PaulHomes
Rhodochrosite | Level 12

Hi Henry,

I don't think there's any difference in the requirements, but I've never yet needed to run the spawner with a different service account.

For further clarification have a look at Windows Privileges in the SAS(R) 9.3 Intelligence Platform: Security Administration Guide.  It states:

Note: In most cases, an object spawner on Windows runs as a service under the local system account. If the spawner instead runs under some other account, that account must be a Windows administrator on the spawner's host and have the Windows user rights Adjust memory quotas for a process and Replace a process level token. These user rights assignments are part of the local security policy for the Windows computer that hosts the spawner.

Other than that I would suggest trying it out and/or following up with SAS tech support.

Cheers

Paul

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