Authentication Mechanisms

SAS Internal Authentication

Internal Authentication
Summary	Participating SAS servers validate incoming user IDs that have a special suffix (@saspw) against a list of accounts that exist only in the metadata.
Scope	Primarily used for connections to the metadata server. Also supported for direct connections to the OLAP server.¹
Benefits	Minimizes the need to create external accounts for service identities. Facilitates intermittent use of an administrative role by enabling a user to have a second metadata identity without having a second external account. See Add Administrators. Provides independence from the rest of your computing environment. For example, internal accounts don't have to follow your general password change requirements, can't be used to access resources beyond the SAS metadata, and aren't affected by changes in machine names or in your authentication configurations.
Limits	Internal accounts aren't intended for regular users (they are intended for only metadata administrators and some service identities). Someone who has only an internal account can't seamlessly access the workspace server. See Credential Gaps. An internal account can't participate in Integrated Windows authentication or Web authentication. You can't use an internal account to delete, unregister, add, or initialize a foundation repository. You can't run a server under an internal account. For example, the SAS General Server User (sassrv) must be a host account.
Use	Always available
1 This isn't a common use. In the SQL procedure, a connection to the OLAP server can be made using an internal account.

Internal accounts exist only in the metadata and are created in the User Manager plug-in in SAS Management Console. The following displays depict the General tab and Accounts tab for an administrator named Joe. Notice that Joe's internal user ID is Joe@saspw. The user ID for an internal account is always in the format name@saspw. The name comes from the Name field on the user's General tab.

[untitled graphic]

The following figure depicts the internal authentication process:

Internal Authentication

[Internal Authentication]

The numbers in the preceding figure correspond to these actions:

At a logon prompt, Joe enters his internal credentials. The client sends those credentials to the metadata server for verification.
The metadata server recognizes that the ID is for an internal account (because the ID has the @saspw suffix), so the metadata server checks the credentials against its list of internal accounts.
After validating the ID and password, the metadata server accepts the client connection. The connection is under the identity of the SAS user who owns the account.

Note: Joe can have logins in addition to his internal account, but he doesn't need a login to establish his SAS identity.

Here are some tips for working with internal accounts:

There are two distinct expiration settings. Don't confuse the account expiration date with the password expiration period.
If repeated attempts to log on with an internal account fail, make sure you are including the @saspw suffix in the user ID. Another cause of failure is the account is locked. See How to Unlock an Internal Account.
If you have both an internal account and an external account, use a dedicated connection profile for your internal account. In that profile, leave the Authentication domain field blank. This ensures optimal credential reuse.
If you don't have user administration capabilities, you can't see internal accounts, unless you are viewing your own definition and you happen to have an internal account.

Because internal accounts exist only in the metadata, they don't automatically follow the policies of other authentication providers. Here are the initial policies for internal accounts:

Accounts don't expire and aren't suspended due to inactivity.
Passwords must be at least six characters, don't have to include numbers or mixed case, and don't expire.
The five most recent passwords can't be reused.
After three failed attempts to log on, an account is locked for one hour. An administrator can unlock the account by accessing the Accounts tab in the user's definition in SAS Management Console.
A forced password change occurs on first use and after a password is reset. This policy applies only to accounts with passwords that periodically expire. By initial policy, passwords don't expire, so forced password changes don't occur.

You can set all of these policies globally (at the server-level). You can also selectively override many of these policies on a per-account basis. See How to Change Internal Account Policies.

	How to Configure SAS Internal Authentication
	Authentication to the Metadata Server