Introduction to User Administration :: SAS(R) 9.3 Management Console: Guide to Users and Permissions

About User Administration

In order to make access distinctions and track user activity, security systems must know who is making each request. The primary purpose of user administration is to provide information that helps systems make this determination. The central piece of user information that the SAS environment requires is one external account ID for each user. The SAS environment uses its copy of these IDs to establish a unique SAS identity for each connecting user. All of a user's group memberships, role memberships, and permission assignments are ultimately tied to their SAS identity.

Note: For identification purposes, only the account IDs are needed. SAS does not maintain copies of external passwords for identification purposes.

To access user administration features in SAS Management Console, select the User Manager node on the Plug-ins tab. Your roles and permissions determine which user administration tasks you can perform.

Tip

As an alternative to interactively creating and maintaining identity information, you can write a program that performs these tasks as batch processes. See the user import macros documentation in the SAS Intelligence Platform: Security Administration Guide.

About Users

A user is an individual person or service identity.

We recommend that you create an individual SAS identity for each person who uses the SAS environment. This enables you to make access distinctions in the metadata layer and establishes a personal folder for each user. If generic access is sufficient for some of your users, those users can instead share the generic PUBLIC group identity.

An individual SAS identity is established by coordination between two sets of identity information:

in an external system, a user account
in the metadata, a user definition that includes a copy of the external account ID

To give someone an individual SAS identity, you create a metadata user definition that includes a copy of their external account ID. This list provides details for several configurations:

In the simplest configuration, each user needs an account that is known to the metadata server's host.
- If the metadata server is on Windows, users typically have Active Directory accounts.
- If the metadata server is on UNIX, users might have UNIX accounts. Sometimes a UNIX host recognizes LDAP, Active Directory, or other types of accounts.
In a common alternate configuration, the metadata server trusts authentication that is performed at the Web perimeter. In this configuration, anyone who uses a Web application needs a Web realm account.
In a less common alternate configuration, the metadata server directly uses an LDAP provider such as Active Directory. This is appropriate only if you have accounts that are not already accepted by the metadata server's host. For example, if the metadata server is on Windows, it is not necessary (or appropriate) to configure direct use of Active Directory.

Note: A PUBLIC-only user does not need a metadata user definition. For metadata administrators and certain service identities, it is appropriate to use a SAS internal account.

About Groups

A group is a set of users.

We recommend that you create groups to simplify security management as follows:

It is more efficient to assign permissions to groups than to individual users.
If you need to store passwords in the metadata, you can reduce the amount of required maintenance by using a group to make one shared account available to multiple users.
It is sometimes more efficient to manage role membership by assigning groups to roles instead of assigning users directly to roles.

This table introduces three predefined groups:

PUBLIC, SASUSERS, and SAS Administrators

Group	Description
PUBLIC	Includes everyone who can access the metadata server (directly or through a trust relationship).
SASUSERS	Includes those members of the PUBLIC group who have a well-formed user definition.
SAS Administrators	Should include only users who perform metadata administrative tasks. In a standard configuration, this group has broad access but is not unrestricted.

Tip

A group's membership can include other groups as well as individual users. This enables you to create a nested group structure.

About Roles

A role manages the availability of application features such as menu items.

An application feature that is under role-based management is called a capability. Anyone who is a member of a role has all of that role's capabilities. This list highlights key points:

Roles determine which user interface elements (such as menu items or plug-ins) you see when you use an application. Roles do not protect data or metadata (other than a few system items).
Having a certain capability is not an alternative to meeting permission requirements. Permission requirements and capability requirements are cumulative.
Roles and groups serve distinct purposes. You cannot assign permissions to a role or capabilities to a group.
Capabilities are always additive. Assigning someone to a role never reduces what that person can do.

Each application that supports roles offers a fixed set of capabilities. You cannot convert an application feature that is not a capability into a capability.

Note: If you add custom plug-ins (in SAS Management Console) or custom tasks (in SAS Enterprise Guide or the SAS Add-In for Microsoft Office), you can register those features as capabilities. For further information, see the administrative documentation for those applications.

Each application that supports roles provides one or more predefined roles. Each predefined role has a unique initial set of capabilities. The capabilities that a role provides should reflect the activities and responsibilities of that role's members. You can adjust the distribution of capabilities in these ways:

Change role memberships. For example, to prevent regular users from seeing plug-ins in SAS Management Console, you might narrow the membership of the Management Console: Content Management role by making changes on that role's Members tab.
Customize the initial roles-to-capabilities mapping by using any of these techniques:
- Incrementally select or clear explicit capabilities for a role. You cannot deselect capabilities for the unrestricted role.
- Aggregate existing roles so that one or more roles contributes all of their capabilities to another role.
- Create new roles that provide unique combinations of capabilities.

This table introduces the main administrative roles:

Main Administrative Roles

Role	Capabilities
Metadata Server: Unrestricted	Members have all capabilities and cannot be denied any permissions in the metadata environment.1
Metadata Server: User Administration	Members can create, update, and delete users, groups, roles (other than the unrestricted role), internal accounts, logins, and authentication domains.2
Metadata Server: Operation	Members can administer the metadata server (monitor, stop, pause, resume, quiesce) and its repositories (add, initialize, register, unregister, delete).3
Management Console: Advanced	Members can see all plug-ins in SAS Management Console (in the initial configuration).
1Unrestricted users are subject to denials in other authorization layers, can use only those logins that are assigned to them (or to groups to which they belong), and do not have implicit capabilities that are provided by components other than the metadata server.
2Restricted user administrators cannot update identities for which they have an explicit (white) or ACT (green) denial of WriteMetadata.
3Only someone who has an external user ID that is listed in the adminUsers.txt file with a preceding asterisk can delete, unregister, add, or initialize a foundation repository. Only an unrestricted user can analyze and repair metadata or perform tasks when the metadata server is paused for administration.

About Logins

What is a Login?

A login is a SAS copy of information about an external account. Every login must include a user ID. In a login for a Windows account, the ID must be qualified (for example, user@company.com), domain\user, or machine\user.

Tip

The requirement to provide a qualified ID for a Windows account applies to the SAS copy of the ID. It is usually not necessary to qualify the user ID that you provide when you launch a SAS application.

Tip

If you do provide a qualified ID when you log on, you must use the same format that was used in your login. For example, Windows might accept both WIN\me and Me.MyLastName@mycompany.com, but SAS can understand only one of these qualified forms (the form in which the SAS copy of the ID is stored).

Logins for Users

Each user should have a login that establishes their SAS identity. It is not necessary to include a password in this login. For example, this is how Joe's login might look when a user administrator views Joe's Accounts tab:

DefaultAuth | WIN\Joe  |

A user might have additional logins that provide access to other systems. For example, if Joe has his own Oracle account, he might have these two logins:

DefaultAuth | joe      |

OracleAuth  | ORAjoe   | ********

Note: The Oracle login should include a copy of Joe's Oracle password.

If a site uses Web authentication, the requirements are different. For example, if Joe uses both Web and desktop applications at such a site, Joe might have these three logins:

DefaultAuth | WIN\Joe |

OracleAuth  | ORAjoe  | ********

web         | WEBjoe  |

Note: Like his DefaultAuth login, Joe's Web login does not need to include a password.

Logins for Groups

Groups do not have to have logins. The main reason to give a login to a group is to make a shared account available to multiple users. A group login contains a SAS copy of the user ID and password for a shared account. For example, to provide shared access to DB2, a group might have a login that looks like this:

DB2Auth | sharedDB2id | ********

All members of the group can see and use this login. Since this login is for a third-party database, a copy of the DBMS account password should be stored in this login.

About Internal Accounts

What is an Internal Account?

An internal account is a SAS account that the metadata server authenticates independently, without relying on an external authentication provider such as the operating system. Use internal accounts for only metadata administrators and certain service identities. For these identities, an internal account is an acceptable substitute for an external account with a corresponding login. For example, the SAS Administrator and the SAS Trusted User can be based on internal accounts.

Benefits of Internal Accounts

Internal accounts have these advantages:

Internal accounts provide an alternative to creating external accounts for SAS internal purposes such as inter-process communication.
Internal accounts can be maintenance free. You do not have to synchronize internal accounts with some other user registry. Internal accounts do not have to conform to the security policies of the rest of your computing environment. For example, even if your host security policy forces password changes every 30 days, you can retain the initial policy for internal account passwords (which is that these passwords never expire).
Internal accounts are usable only in the SAS realm, so they reduce exposure to the rest of your security environment.

Limitations of Internal Accounts

Although the Create Internal Account button is available on all user definitions, internal accounts are not intended for regular users. Someone who has only an internal account cannot do these things:

launch a standard workspace server without interactively providing some external credentials
participate in Integrated Windows authentication or Web authentication
add, delete, initialize, or unregister a foundation repository

Policies for Internal Accounts

By initial policy, these server-level settings are in effect:

Accounts do not expire and are not suspended due to inactivity.
Passwords must be at least six characters, do not have to include mixed case or numbers, and do not expire.
The five most recent passwords for an account cannot be reused for that account.
There is no mandatory time delay between password changes.
After three failed attempts to log on, an account is locked. If an account is locked because of logon failures, further log on attempts cannot be made for one hour.
For an account that has a password expiration period, there is a forced password change on first use and after the password is reset by someone other than the account owner. By initial policy, passwords do not expire so there are no forced password changes.

Note: These settings are defined in the metadata server's omaconfig.xml file. In User Manager, you can customize some of these settings on a per-account basis.

CAUTION:

Passwords for a few required accounts (such as the SAS Administrator and the SAS Trusted User) are included in configuration files.

If you change these passwords, you must also update the configuration. See the SAS Intelligence Platform: Security Administration Guide.

About Authentication Domains

What is an Authentication Domain?

An authentication domain is a name that facilitates the matching of logins with the servers for which they are valid. This matching is not important when you launch a client, but it is important when you access certain secondary servers such as a third-party DBMS or a standard workspace server.

When Do I Need to Add an Authentication Domain?

In the simplest case, all logins and SAS servers are associated with one authentication domain (DefaultAuth). This list describes the most common reasons for using more authentication domains:

If you use Web authentication, you might need a second authentication domain for the logins that contain Web realm user IDs.
If you want to provide seamless access to a third-party server (such as a DBMS server) that has its own user registry, you need a separate authentication domain for that server and its logins.
If both of the following criteria are met, you need a separate authentication domain for the standard workspace server and its logins:
- The standard workspace server does not share an authentication provider with the metadata server (and cannot be configured to do so).
- You want to provide seamless individualized access to the standard workspace server.

About Passwords

Passwords in Logins

In general, it is not necessary to create a SAS copy of an external password. An exception is if you want to provide seamless access to a server that requires credentials that are different from the credentials that users initially submit. These are the most common examples:

A third-party DBMS server might require a different set of credentials.
In a multi-platform environment, the standard workspace server might require a different set of credentials.

If credentials are not otherwise available, some applications prompt users for an appropriate user ID and password.

Passwords in Internal Accounts

Internal accounts exist only in the metadata. Each internal account includes a password. By initial policy, internal passwords do not expire.

Passwords in Configuration Files

Passwords for a few required accounts (such as the SAS Administrator and the SAS Trusted User) are included in configuration files. If you change these passwords, you must also update the configuration. See the SAS Intelligence Platform: Security Administration Guide.

About External Identities

What is an External Identity?

While logins and internal accounts are involved in the logon process, external identities are not. An external identity is an optional synchronization key for a user, group, or role. If you use batch processes to coordinate SAS identity information with your primary user registry, you need external identities (such as employee IDs) to facilitate matching. This list explains the circumstances in which a user, group, or role needs an external identity:

For a user, group, or role that you maintain interactively in SAS Management Console, no external identity is needed.
For a user, group, or role that you maintain using batch processes, one external identity is needed.

Where do External Identities Come From?

External identities can be added in these ways:

For a user, group, or role that is created by an import process, an external identity is added as part of that process.
For any user, group, or role, you can interactively add an external identity on the General tab of their definition.

Requirement: Unique Names and IDs

Within a metadata server, these uniqueness requirements apply:

You cannot create a user definition that has the same name as an existing user definition.
You cannot create a group or role definition that has the same name as an existing group or role definition.
You cannot assign the same user ID to different users or groups. All of the logins that include a particular user ID must be owned by the same identity. This enables the metadata server to resolve each user ID to a single identity.
- This requirement is case-insensitive. For example, you cannot assign a login with a user ID of smith to one user and a login with a user ID of SMITH to another user.
- This requirement applies to the qualified form of the user ID. For example, you can assign a login with a user ID of winDEV\brown to one user and a login with a user ID of winPROD\brown to another user.
- This requirement cannot be mitigated by associating the logins with different SAS authentication domains. For example, if one user has a login with a user ID of smith in DefaultAuth, you cannot give any other user a login with the user ID smith, even if you put that login in another authentication domain.
If you give a user two logins that contain the same user ID, the logins must be in different authentication domains. Within an authentication domain, each user ID must be unique. For example, if you give Tara O'Toole two logins that both have a user ID of tara, then you cannot associate both of those logins with the OraAuth authentication domain. As with the previous requirement, this requirement is case-insensitive and is applied to the fully qualified form of the user ID.