Introduction to User Administration :: SAS® 9.4 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. 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.

Note: For information about alternate configurations (such as web authentication) and exceptions (such as SAS internal accounts), see SAS Intelligence Platform: Security Administration Guide.

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.

Tip

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

This table introduces three predefined groups:

PUBLIC, SASUSERS, and SAS Administrators
Group	Description
PUBLIC	Implicitly includes everyone who can access the metadata server (directly or through a trust relationship).
SASUSERS	Implicitly 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.

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 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.

The following table introduces some of the predefined administrative roles:

Introduction to Selected Administrative Roles
Role	Capabilities Overview
Metadata Server: Unrestricted	Members have all capabilities and full access to metadata (but they cannot read other users’ passwords).
Metadata Server: User Administration	Members can create and manage restricted users, groups, roles, internal accounts, logins, and authentication domains.
Management Console: Advanced	Members can see all plug-ins in SAS Management Console.

For details and exceptions, see the discussion of administrative roles in SAS Intelligence Platform: System Administration Guide.

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.

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 Oracle, a group might have a login that looks like this:

OracleAuth | sharedORAid | ********

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.

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: In User Manager, you can customize some of these settings on a per-account basis.

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.

The second maintenance release of SAS 9.4 supports outbound and trusted authentication domains. A login in an outbound domain is used only to provide SAS applications with seamless access to external resources, such as a third-party vendor database. These logins are not part of the SAS identity phase that attempts to match the authenticated user ID to the current metadata user. Therefore, for outbound domain logins, the uniqueness requirements on the user ID are not enforced.

A login in a trusted domain can be accessed only by a trusted user on behalf of the user. The identity to which the login is associated does not have direct access to the login (they will not see it listed on the Accounts tab in SAS Management Console). Instead, the login will be used on their behalf by a trusted user. A login in a trusted domain also requires the authentication domain to be an outbound domain.

Administration of logins in outbound and trusted authentication domains can be performed only by unrestricted users and user administrators. For more information, see SAS Intelligence Platform: Security Administration Guide.

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). Here are some 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. See the instructions for updating managed passwords in SAS Intelligence Platform: Security Administration Guide.

About External Identities

What Is an External Identity?

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.

Uniqueness Requirements

In metadata user administration, certain uniqueness requirements apply. For example, you cannot create a user definition that has the same name as an existing user definition and you cannot assign the same user ID to multiple users. For details, see SAS Intelligence Platform: Security Administration Guide.