In most cases, users can launch SAS
applications using the same ID and password as they use in the rest
of your computing environment. However, when you create a SAS copy
of a Windows user ID, you must store the user ID in the appropriate
format. In most cases, you must use a particular qualified format
(for example,
WindowsDomain\user,
MachineName\user,
or
user@company.com). With
certain authentication configurations, a different format is required.
Failure to appropriately qualify a stored user ID causes the user
to have only the PUBLIC identity.
If
your site accepts Windows IDs in disparate formats, you must coordinate
the format of the copies with the format in which users submit their
IDs. This table describes the common forms for an Active Directory
user ID:
Overview: Forms of an Active Directory User ID
|
|
|
|
|
|
|
|
|
|
|
joe@orionsports.com or joe@sales.orionsports.com |
|
|
down-level-domain-name\user
|
orionsports\joe or sales\joe or mymachine\joe |
|
|
|
|
Note: User Principal Name (UPN)
is an Active Directory concept. Down-level domain is a Windows NT
concept. The realm in a Kerberos name is usually a Windows domain.
A Kerberos name can include an instance (in the format
user/instance@realm).
Additional site-specific variations might occur.
In the platform, follow
these guidelines for Windows user IDs:
-
If users log on interactively,
they can usually use the short form. Here are some exceptions:
-
The user has multiple accounts
with the same user ID in different down-level domains (for example,
machine\joe,
domain1\joe,
and
domain2\joe).
-
The site has configured direct
use of LDAP and has not specified
-primpd (the
PRIMARYPROVIDERDOMAIN system option).
-
If users log on interactively,
they can also use one other site-supported form (either the UPN form
or the down-level form). Use one of these approaches:
-
In the metadata, store each user
ID in UPN form. Tell users not to use the down-level form when they
log on.
-
In the metadata, store each user
ID in down-level form. Tell users to not use the UPN form when they
log on.
-
If users log on to SAS desktop applications through
Integrated Windows authentication, their user IDs should usually be
stored in down-level form. In general, that is the form in which SAS
obtains user IDs after Kerberos authentication occurs.
Note: If you prefer to store user
IDs in the native Kerberos form, add the setting
SASUSEKERBNAME
true as a Windows system environment variable on
the server host. For example, on the Windows desktop, right-click
My
Computer, select
Properties,
select the
Advanced tab, click the
Environment
Variables button, add the setting under
System
variables, and reboot the machine. This setting affects
only connections that use Integrated Windows authentication. If you
use this setting, you might want to make sure that the Integrated
Windows authentication process always chooses the Kerberos protocol.
-
If users log on to SAS Web applications
through Integrated Windows authentication (which occurs only if you
configure Web authentication and have set up Integrated Windows authentication
with your Web provider), the form of the returned user ID might differ.
See the documentation for your Web application server.
Note: In the status bar of some
applications, a currently connected Windows user ID is always displayed
in the format
user@VALUE, regardless
of how the user logged on or how the user's ID is stored in the metadata.
For example, if you log on as
Joe and
your stored user ID is
WIN\joe,
the status bar displays your authenticated ID as
joe@WIN.