Introduction to User Administration :: SAS(R) Environment Manager 2.4: User's Guide

About User Administration

SAS Environment Manager provides some of the capabilities that are available in SAS Management Console. SAS Environment Manager is not currently a replacement for SAS Management Console, and no functionality has been removed from SAS Management Console.

In order to make access distinctions and to track user activity, each requesting user must be identified. The main purpose of user administration is to provide information that facilitates the identification of users. In general, SAS stores one external account ID for each user. SAS uses its copy of these IDs to establish a unique identity for each connecting user. All of a user's metadata-layer group memberships, role memberships, and permission assignments are ultimately tied to that user’s SAS identity.

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

As an alternative to creating a login for a user or administrator, you can give the new user or administrator an internal account. Enable the Internal Account option on the user’s Accounts page. An account is enabled when the Internal Account option settings are displayed. Before you add an internal account, see Limitations of Internal Accounts.

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 SAS Intelligence Platform: Security Administration Guide.

Tip

You can use the metadata promotion tools to import and export identity information. See SAS Intelligence Platform: System Administration Guide.

About Users

A user is an individual person or service identity.

You should create an individual SAS identity for each person who uses the SAS environment. You can then make access distinctions in the metadata layer and establish a personal folder for each user.

Note: If generic access is sufficient for some of your users, those users can instead share the generic PUBLIC group identity. Not all applications accept PUBLIC-only users.

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. For example, in the simplest configuration, each user has an account that is known to the metadata server's host.

If the metadata server is running in Windows, users typically have Active Directory accounts.
If the metadata server is running in UNIX, users might have UNIX accounts. Sometimes a UNIX host is configured to recognize LDAP, Active Directory, or other types of accounts.

Note: For metadata administrators and some service identities, you can use a SAS internal account instead of an external account.

About SAS Administrators

When creating SAS administrators, consider the following:

If you want to make someone an unrestricted administrator, assign them to the Metadata Server: Unrestricted role.
Administrators should not also serve as regular users. If you want someone to be an administrator only some of the time, create two user definitions for that person.
- One definition is based on an external account and is not a member of SAS Administrators.
- The other definition is based on an internal account and is a member of SAS Administrators.
A dual user logs on with an internal account in order to use administrative privileges and with an external account the rest of the time.

About Groups

A group is a set of users.

Creating groups enables you to simplify security management in the following ways:

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.
If you need to manage permissions for distinct classes of access, you can create custom groups. For example, you might create a group for each business unit or functional area of responsibility.

Tip

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

About Roles and Capabilities

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. Roles and capabilities have the following charateristics:

Roles determine which user interface elements (such as menu items or modules) you see when you use an application. In general, roles do not protect data or metadata.
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 additive. Assigning someone to a role never reduces what that person can do.
If necessary, you can adjust the distribution of capabilities by changing role memberships or by customizing the mapping of roles-to-capabilities.
If you need to decrease the level of granularity, you can create a new role that aggregates two or more existing roles. For example, you might create a role that includes all capabilities other than those of the most privileged roles.
If you need to increase the level of granularity, you can create a new role that provides only a subset of the capabilities of a predefined role.
If you need to create a cross-application role for a particular type of functionality, you can create custom roles. For example, you might create an OLAP role that includes the OLAP capabilities from SAS Enterprise Guide and the SAS Add-In for Microsoft Office.

For information about the predefined administrative roles, see SAS Intelligence Platform: System Administration Guide.

About Members

A member is a user or group that is assigned to a group or role.

When adding members to a group or role, consider the following:

You cannot use the SAS Environment Manager user interface to make a role a member of a group or of another role. You can instead make one role contribute all of its capabilities to another role.
On a group definition, do not confuse the Members tab with the Member of tab. Use a group's Member of tab only if you want to make that group a member of other groups or roles.
To reduce complexity, do not make the implicit groups (SASUSERS and PUBLIC) members of other groups. These groups can be members of certain roles.

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, userID@company.com, domain\userID, or machine\userID).

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 log on to 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 environments 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. You do not need to include a password in this login. The password column displays eight asterisks if a password is stored. For example, this is how Joe's login might look when a user administrator views Joe's Accounts settings:

Domain	Stored User ID	Stored Password (Optional)
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:

Domain	Stored User ID	Stored Password (Optional)
DefaultAuth	WIN\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:

Domain	Stored User ID	Stored Password (Optional)
DefaultAuth	WIN\Joe
OracleAuth	ORAjoe	********
web	WEB\joe

Note: Like his DefaultAuth login, Joe's web login is used only to launch clients, so there is no need to create a SAS copy of Joe's web realm password.

Logins for Groups

Logins are not required for groups. The main reason to assign 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:

Domain	Stored User ID	Stored Password (Optional)
DB2Auth	sharedDB2id	********

All members of the group can see and use this login. Because 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 only for administrators and some service identities. For these purposes, 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 another user registry.
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 you can add an internal account to any user definition, internal accounts are not intended for regular users. Someone who has only an internal account cannot perform the following tasks:

seamlessly launch a standard workspace server that runs under their own individual identity
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 in length, 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.
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.

These default policies are set in the metadata server’s omaconfig.xml file. For more information, see 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.

Note: 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, in some configurations, a standard workspace server.

Each user ID and password is valid within a specific scope. For example, the user ID and password that you use to log on to your computer at work are probably not the same as the user ID and password that you use at home. It is also common for database servers and web servers to have their own authentication mechanisms, which require yet another, different, user ID and password.

An enterprise application that provides access to many different resources might require that a user have several sets of credentials. Each time a user requests access to a resource, the software must determine which credentials to use to provide access. The software could challenge the user with an interactive prompt for user ID and password, but that quickly becomes an annoyance that interrupts the user experience. The software could randomly try different credentials until it finds a set that works, but authentication attempts can be expensive in terms of performance. In SAS Intelligence Platform, the software attempts to use only the credentials that it expects to be valid for a particular resource or system.

The software’s knowledge of which credentials are likely to be valid is based entirely on authentication domain assignments. For this reason, you must correctly assign an authentication domain to each set of resources that uses a particular authentication provider. You must also assign that same authentication domain to any stored credentials that are valid for that provider.

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

Managed Passwords

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

Passwords in Logins

It is usually not necessary to store an external password in the SAS metadata. The main reason to include a password in a login is to provide seamless access to a server that requires credentials that are different from the credentials that users initially submit. The most common example is a deployment that includes a third-party DBMS server that requires a different set of credentials.

Password management for logins is driven by changes that occur in other systems. For example, if you have a personal login for a third-party DBMS, and you change your DBMS password, you must also update the SAS copy of that password.

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 need to change these passwords, use SAS Deployment Manager. For instructions, see SAS Intelligence Platform: Security Administration Guide.

Requirement: Unique Names and IDs

Within a metadata server, the following 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. In this situation, the metadata server resolves each user ID to a single identity.

Note: The exception to this requirement is logins that are associated with outbound authentication domains. These logins are not subject to these constraints.
- 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.
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.

Tip

Avoid using spaces or special characters in the name of a user, group, or role that you create. Not all components support spaces and special characters in identity names.