Protect Server Definitions :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide

Introduction

In a new deployment, all registered users can update and delete server definitions. We recommend that you limit the ability to update or delete server metadata 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.

Method

To avoid repeatedly adding the same explicit grants and denials to multiple pieces of server metadata, create and use an ACT. 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 an explicit grant of WriteMetadata permission on that application server.

The following table depicts typical protections.

Example: Protecting Server Definitions

Object	Direct Controls
Object	ACTs	Explicit Grants
SASApp	Protect	DataAdmins: +WM
Each logical server inside SASApp	Protect	(none)
SASMeta	Protect	(none)
Other immediate children of Server Manager	Protect	(none)

Note: The initial configuration in a new deployment limits access to the logical workspace server and the logical SAS DATA step batch server within SASMeta, so it is not necessary to add protections to those components.

Instructions

Here is 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) 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.

If you do not already have an ACT with the appropriate pattern, create a new ACT as follows:

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

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

Example: Pattern for the Protect ACT

Group	Permission Pattern
PUBLIC	Deny	WriteMetadata, WriteMemberMetadata, CheckInMetadata, Write, Administer
SAS Administrators	Grant	WriteMetadata, WriteMemberMetadata, CheckInMetadata, Write, Administer, ReadMetadata1
1These grants ensure that administrators can manage all metadata.

Tip

To increase reusability, this pattern includes permissions that are not relevant for server definitions.

On the Authorization tab, add explicit controls to protect the ACT that you are creating:
- Select PUBLIC and deny WriteMetadata permission. Leave the indirect ReadMetadata setting in place.
- Select SAS Administrators and grant WriteMetadata permission. Leave the indirect ReadMetadata setting in place.
Tip
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.
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.
1. Right-click User Manager and select NewGroup.
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.
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.
To set the protections:
1. Expand Server Manager, right-click the first application server (if this is your first pass) and select Properties.
2. 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 ACT settings. These settings come from the Protect ACT.
3. (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.
  
  Tip
  For any users that are under change management, grant CheckInMetadata (CM), instead of WriteMetadata (WM). See SAS Intelligence Platform: Desktop Application Adminstration Guide.
  
  Note: Don't extend WriteMetadata access to the SASMeta application server, because that server should be used for only a few specialized administrative tasks.
4. Click OK to save the settings for this object.
5. Repeat steps 5a-d for every immediate child of Server Manager. Immediate children include objects such as other application servers, third-party servers, the share server, the content server, and spawners.
6. Apply the Protect ACT to every logical server that is under an application server where you added an explicit 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.

Protect Server Definitions

Introduction

Method

Instructions

See Also