Internal Authentication
|
|
Participating SAS servers
validate incoming user IDs that have a special suffix (@saspw) against
a list of accounts that exist only in the metadata.
|
|
|
-
Primarily used for connections
to the metadata server.
-
Also supported for direct connections
to the OLAP server. This isn't a common use. In the SQL procedure,
a connection to the OLAP server can be made using an internal account.
|
|
|
-
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.
-
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.
|
|
|
-
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.
-
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.
|
|
|
|
Internal accounts exist only in the metadata and can
be created 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.
The following figure
depicts the internal authentication process:
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.
-
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.
