Permissions on Servers

Protecting Server Definitions

In the initial configuration, the Server Manager [icon] capability is available to only the SAS Administrators group. This provides some protection for server definitions. For greater security, use permissions to define access as follows:

The SAS Administrators group should be able to administer, update, and delete all server definitions.
Users who assign libraries, stored processes, or an OLAP schema to an application server must have WriteMetadata permission for that application server.
No other users should be able to update or delete server definitions.

To efficiently set the permissions, create and use an access control template (ACT). This enables you to avoid individually setting the same grants and denials on multiple pieces of server metadata. If you want to enable regular users to assign libraries, stored processes, or an OLAP schema to a particular application server, supplement the ACT settings with a grant of WriteMetadata permission on that application server. The following instructions are one way to set the permissions:

Log on to SAS Management Console as a member of the SAS Administrators group (for example, sasadm@saspw). Select the Plug-ins tab.
(Optional) To examine the current settings:
1. Expand Server Manager, right-click the SASApp application server and select Properties.
2. On the Authorization tab, select SASUSERS. Notice that this group (which includes all registered users) has both ReadMetadata and WriteMetadata permissions. The application server inherits these grants from the standard repository-level settings. Click OK to close the dialog box.

To create the ACT:

Expand Authorization Manager , right-click Access Control Templates, and select New Access Control Template.
On the General tab, enter a name such as Protect.

Note: If you already have a Protect ACT, verify that the pattern on that ACT's Permission Pattern tab is correct and that settings on that ACT's Authorization tab protect the ACT itself. Then, proceed to step 4.

On the Permission Pattern tab, define settings that you want to apply to all server metadata:

Click Add. In the Add Users and Groups dialog box, clear the Show Users check box. Move PUBLIC and SAS Administrators to the Selected Identities list box and click OK.

On the Permission Pattern tab:

Select PUBLIC and set the denials in the following table
Remove the grant of ReadMetadata permission for PUBLIC by clicking the already selected grant ReadMetadata check box. This clears that check box so that the pattern neither grants nor denies this permission to PUBLIC.

Note: A grant of ReadMetadata permission is automatically added for each user or group that you add to a Permission Pattern tab. The purpose of the Protect ACT is to limit the ability to update or delete items, not to change the visibility of items, so it is important to undo the automatically created grant of ReadMetadata permission for PUBLIC. Do not instead add a denial of ReadMetadata permission for PUBLIC. That denial would interrupt the grant of this permission for SASUSERS that flows through from the repository ACT.
Select SAS Administrators and set the grants in the following table. For this group, you can leave the automatic grant of ReadMetadata permission in place.

The Protect ACT
Group	Permission Pattern¹
PUBLIC	Denial	WriteMetadata, WriteMemberMetadata, CheckInMetadata, Write, Administer
SAS Administrators	Grant	WriteMetadata, WriteMemberMetadata, CheckInMetadata, Write, Administer, ReadMetadata
1 Gives SAS Administrators exclusive write access to metadata. To increase reusability, this pattern includes extra permissions.

On the Authorization tab, add explicit settings to protect the ACT that you are creating:

Note: If the Users and Groups list box on the ACT's Authorization tab is empty, click OK to save the ACT. Then, right-click the new ACT, select Properties, and select the Authorization tab again.
- Select PUBLIC and deny WriteMetadata permission. Leave the indirect (gray) ReadMetadata setting in place.
- Select SAS Administrators and grant WriteMetadata permission. Leave the indirect (gray) ReadMetadata setting in place.
Click OK.

(Optional) If you want to allow some nonadministrators to assign libraries, stored processes, or an OLAP schema, and you don't already have a group that represents those users, create a new custom group.

Note: As an alternative to creating a group for only this purpose, you can skip this step and instead assign the permissions to specific users in step 5c.
1. Right-click User Manager and select New Group.
2. On the General tab, enter a name such as Data Admins.
3. On the Members tab, move users (or groups) to the Selected Identities list box.
4. Click OK to save the new group. You will grant WriteMetadata permission to this group in step 5c. This group doesn't participate in the ACT's pattern because this group needs WriteMetadata permission on only some of the target objects.

To set the protections:

Expand Server Manager, right-click the first application server (if this is your first pass) and select Properties.
On the Authorization tab, click Access Control Templates. In the Add and Remove Access Control Templates dialog box, move the Protect ACT to the Currently Using list box (you have to expand the Foundation node to get to the ACT). Click OK to return to the Authorization tab.

Note: Review the revised settings. Notice that SASUSERS is now denied WriteMetadata permission and that PUBLIC and SAS Administrators have some green settings . The green settings come from the Protect ACT.
(Optional) If the current item is an application server to which nonadministrators will assign libraries, OLAP schemas, or stored processes, click Add, add one or more identities to the Authorization tab, and give each of those identities an explicit grant of WriteMetadata permission. For example, you might assign the grant to a group (such as GroupA) or to individual users.

Note: Don't extend WriteMetadata access to the SASMeta application server, because that server should be used for only a few specialized administrative tasks.
Click OK to save the settings for this object.
Repeat steps 5a-d for every immediate child of Server Manager (except the table server). Immediate children include objects such as other application servers, third-party servers, the share server, the content server, and spawners.
Apply the Protect ACT to every logical server that is under an application server where you added an individual grant of WriteMetadata permission (for SASUSERS or a custom group such as Data Admins).

Note: This protects lower-level server metadata that would otherwise inherit the nonadministrator's WriteMetadata grant from the application server. This also prevents nonadministrators who have WriteMetadata permission on the application server from deleting that application server.

The following table summarizes typical protections.

Example: Protecting Server Definitions
Object	Added Settings
Object	ACT	Supplemental Grants
SASApp	Protect	DataAdmins: +WM
Each logical server inside SASApp	Protect	(none)
SASMeta	Protect	(none)
Other immediate children of Server Manager*	Protect	(none)
* Except the table server, which does not need any changes.

	Hiding Server Definitions
	Explicit Settings
	The Authorization Tab
	Use and Enforcement of Each Permission