In order to make access distinctions and track user activity, a security system must know who is making each request. In the platform, the primary user administration task is to store each user's external account ID in the SAS metadata. SAS uses its copy of these

IDs to establish a unique SAS identity for each connecting user. All of a user's metadatalayer memberships, permissions, and capabilities are ultimately tied to the user's SAS identity.

Note: It is not necessary to store passwords in the SAS metadata for the purpose of

identifying a user. SAS identity is determined by examining stored user IDs, not by examining stored passwords.

Note: For some service identities and metadata administrators, you can use a SAS

internal account instead of a stored SAS copy of an external account ID.

Who Can Manage Users, Groups, and Roles?

In the initial configuration for a new deployment, the SAS Administrators group has the user administration role, so members of that group can perform almost all user management tasks. The following table outlines the distribution of user administration capabilities.

Table 2.1 User Administration Capabilities

Metadata Server Role

Unrestricted

User administration

None

Actions Supported

Perform all identity management tasks.

Add, modify, and delete most identities.

Update your own personal logins.

For restricted user administrators (users who have the user administration role but are not unrestricted), the following constraints apply:

• Restricted user administrators cannot update the unrestricted role.

• To update or delete an identity, restricted user administrators must have the

WriteMetadata permission for that identity. For example, you can prevent a restricted user administrator from updating UserA’s metadata definition by taking away his or her default grant of the WriteMetadata permission (on UserA’s Authorization tab, explicitly deny the WriteMetadata permission to the restricted user administrator).

• To change a role's capabilities, restricted user administrators must have the

WriteMetadata permission for the associated software component.

• To access user management features in SAS Management Console, restricted user administrators must have the User Manager capability.

Metadata Users

Note: You can delegate administration of an existing identity to someone who is not a

user administrator. In the target identity's metadata definition, explicitly grant the

WriteMetadata permission to the delegated administrator.

Where is User Administration Performed?

Metadata-layer user administration is performed as follows:

• To manage identity information interactively, use SAS Management Console. See

SAS Management Console: Guide to Users and Permissions

• To import identity information in bulk from an external user store (such as Active

Directory) to the SAS metadata, write SAS code. See

Appendix 2, “User Import

Macros,” on page 229

• To copy identity metadata from one SAS repository to another, use the metadata promotion tools. See “Promotion Tools Overview” in SAS Intelligence Platform:

System Administration Guide

• To audit changes to metadata identity definitions, use the

Audit.Meta.Security.GrpAdm and Audit.Meta.Security.UserAdm log categories. See

“Auditing” on page 3 .

Metadata Users

In general, each SAS user has identity information in two distinct realms:

1. In an authentication provider, the user has an account that can access the metadata server.

2. In the SAS metadata, the user has a definition that includes a copy of the account ID with which the user accesses the metadata server.

Coordination between these two realms establishes a unique SAS identity for each user.

Each SAS identity is based on a match between the following two values:

• the account ID with which the user authenticates

• the account ID that is listed in the user's metadata definition

In the following figure, account refers to a user account in an authentication provider, and definition refers to a metadata object that represents the user. Bill cannot log on,

Susan has only the generic PUBLIC identity, and Tara has an individual SAS identity.

Chapter 2 • User Administration

Figure 2.1 Examples: User Accounts and User Definitions

User account?

User definition?

User account?

User definition?

Bill

No SAS identity

Susan

PUBLIC

Generic SAS identity

Tara

Tara Individual SAS identity

ETL

SASUSERS

PUBLIC

Direct membership

Implicit memberships

Here are some tips for working with user definitions:

• If the metadata server runs on Windows and uses SAS authentication, the SAS copy of each user's Windows user ID must be stored in a fully qualified format (for example, WindowsDomain\user-ID, MachineName\user-ID, or user-

[email protected]).

• If you find that a user has only the PUBLIC identity even though the user has a user definition, the user's stored account ID might be missing, not accurately entered, or not in the correct format. Passwords and authentication domain assignments are never the cause of this problem. The match is based only on the account ID.

• Regular users (non-administrators) can maintain their own logins, but cannot make other changes to their definitions.

• Permission settings on a user definition do not determine what that user can do.

Those settings can affect the ability of other identities to update or delete the user definition itself. Special rules automatically protect user, group, and role definitions.

The following table introduces some of the predefined users:

Table 2.2 Selected Predefined Users

User

SAS Administrator

Description

A predefined super user that has unrestricted access in the metadata layer.

A predefined first user that can be useful for demonstrations.

SAS Demo User

SAS Trusted User

A service identity that can act on behalf of other users.

SAS Anonymous Web User

A service identity that can provide anonymous access for a few web components.

For only SAS BI Web Services and the SAS Stored Processes application. See “PUBLIC Access and Anonymous Access” on page

130 .

Metadata Groups

Groups are primarily used in access controls, because it is more efficient to assign permissions to groups than to individual users. You can also use a group to populate a role or to make a shared credential available to multiple users. The following figure illustrates how the users in the previous topic might participate in a group structure:

Figure 2.2 Example: Users in a Group Structure

Bill

PUBLIC

Susan

ETL

SASUSERS

SAS

Administrators

Tara

Report

Users

Here are some tips for working with group definitions:

• You can create a nested group structure by making one group a member of another group.

• Most groups do not have logins (stored credentials). A group login makes a shared external account available to all members of the group. Such outbound logins typically provide access to a third-party database server and should include both a user ID and a password (as well as an authentication domain).

• Permission settings on a group definition do not determine what that group can do.

Those settings can affect the ability of other identities to update or delete the group definition itself. Special rules automatically protect user, group, and role definitions.

The following table introduces some of the predefined groups.

Table 2.3 Selected Predefined Groups

Group

PUBLIC

SASUSERS

Description

Automatically includes everyone who can access the metadata server, either directly or through a trust relationship. A user who does not have an individual identity has only the PUBLIC group identity.

Automatically includes those members of the PUBLIC group who have an individual identity. All members of the SASUSERS group are also members of the PUBLIC group.

Chapter 2 • User Administration

Group

SAS Administrators

SAS General Servers

SAS System Services

Description

A standard group for metadata administrators. In a standard configuration, membership in this group provides broad access and most administrative capabilities, but does not provide unrestricted status.

A service group that enables its member (the SAS Trusted User) to see server launch credentials.

A service group that enables its member (the SAS Trusted User) to see servers, cubes, and other objects.

Server launch credentials (for example, the SAS Spawned Servers account, sassrv) are stored in logins on the Accounts tab of the SAS

General Servers group. This facilitates launching of stored process servers and pooled workspace servers.

Metadata Roles

Role Definitions

Roles control the availability of application features such as certain menu items, plugins, and buttons. In the initial configuration, registered users have almost all nonadministrative capabilities. In many cases, this is appropriate and sufficient. However, you can choose to alter the initial configuration by using either or both of the following techniques:

• To increase or reduce the availability of a role, change the assignment of members to the role.

• To redistribute capabilities, change the assignment of capabilities to roles, or create additional roles.

Here are some tips for working with roles:

• Before you make changes, make sure you have a complete and current backup.

• Capability assignments can be redundant across roles. To prevent someone from having a capability, you must make sure they are not in any role that provides that capability.

• Never change the name of a predefined role.

• There are no negative capabilities (capabilities that limit what someone can do). You cannot deny a capability to anyone.

• Some roles have implicit capabilities (capabilities that are bound to the role and are not displayed in the user interface).

• Contributing role relationships are monolithic. You cannot deselect a contributed capability. These relationships are also dynamic. A change to the capabilities of one role affects any roles to which the first role contributes its capabilities.

Metadata Roles

• Permission settings on a role definition do not determine what that role can do.

Those settings can affect the ability of other identities to update or delete the role definition itself. Special rules automatically protect user, group, and role definitions.

Predefined Roles

The predefined roles and capabilities are described in the administrative documentation for the associated application. The following table helps you locate documentation for predefined roles.

Table 2.4 Documentation of Predefined Roles

Application

Metadata Server

Desktop Applications

Web Applications

Visual Analytics: Basic

Visual Analytics: Report Viewing

Visual Analytics: Analysis

Visual Analytics: Data Building

Visual Analytics: Administration

Documentation of Predefined Roles

SAS Intelligence Platform: System

Administration Guide

SAS Intelligence Platform: Desktop

Application Administration Guide

SAS Intelligence Platform: Web Application

Administration Guide

SAS Visual Analytics: Administration Guide

Differences between Roles and Groups

Roles and groups serve distinct purposes. You cannot assign permissions to a role or capabilities to a group. Here are some additional distinctions:

• The identity hierarchy is relevant for groups, but not for roles. If you are a member of a role, you have all of that role's capabilities, regardless of whether you are a direct member of that role and what your other memberships are.

• You can deny a permission to a group, but you cannot deny a capability to a role.

Each role either provides or does not provide each capability. No role takes capabilities away from its members.

• A group's permissions are not displayed as part of a group definition, but a role's capabilities are displayed as part of a role definition.

• A group can be a member of another group, but a role cannot be a member of another role. Instead, one role can contribute its capabilities to another role.

Chapter 2 • User Administration

Availability of Application Features in a New Deployment

In general, the initial configuration provides appropriate access to application features.

Most nonadministrative capabilities are available to either PUBLIC (everyone who can access the metadata server) or SASUSERS (those members of PUBLIC who have a well-formed user definition). To ensure appropriate availability of features for your applications, see the administrative documentation for each application.

Password Management

Password Policies

Each authentication provider sets password policies for accounts in that provider. For example, the password expiration policy for a host account is determined by that host.

For the SAS internal authentication provider, you can set server-level policies (in the metadata server’s omaconfig.xml file) and per-account policies (in a user’s metadata definition). See

“How to Change Internal Account Policies” on page 177

Client-Side Storage of Passwords

In the initial configuration, users can choose to store their credentials in their client-side connection profiles. This prepopulates the logon dialog box in desktop applications.

For most desktop applications, the SASSEC_LOCAL_PW_SAVE= option controls the availability of a check box that enables users to choose whether to store credentials locally. To prevent users from creating a local copy of their credentials, set

SASSEC_LOCAL_PW_SAVE="N" (or ="0" or ="F") in the metadata server's omaconfig.xml file and restart the server.

Note: A change to the SASSEC_LOCAL_PW_SAVE= setting takes effect after the

metadata server is restarted. Each client uses the previous setting for its first connection, discovers the revised metadata server setting, and conforms to that revised setting for subsequent connections. If you change the setting to disallow saved credentials, and credentials are already present in a user's connection profile, those credentials must be manually removed.

Note: For a few solutions rich clients (for example, SAS Model Manager, SAS

Enterprise Miner, and SAS Forecast Studio), the ability to store credentials in clientside connection profiles is instead controlled by the

Policy.AllowClientPasswordStorage property. This property is available on the Plug-

ins tab in SAS Management Console (under Application Management

Configuration Manager

SAS Application Infrastructure

Settings

Policies) as the property Allow client password storage.

External Login Passwords

In most cases, the SAS copy of an external account includes only a user ID. For these cases, no password updates in metadata are necessary.

For any external passwords that are stored in the SAS metadata, updates are driven by changes that first occur in the external authentication provider. For example, if a copy of

Identity Hierarchy

the password for an Oracle account or a host account is stored in a group login, you must maintain that copy so that it always matches the actual password. Any change to the actual password (in Oracle) must be followed by a corresponding update to the SAS copy of the password (in the group login in the SAS metadata).

You can update stored passwords in SAS Management Console. If you own logins that include passwords, you can also update those passwords in SAS Personal Login

Manager. For example, to update the SAS copy of an external password in SAS

Management Console, navigate to the owning user or group definition, select the

Accounts tab, select a login, and click Edit.

Internal Account Passwords

Every SAS internal account has a password. By initial policy, these passwords do not expire.

To update a SAS internal password in SAS Management Console, navigate to the owning user definition, select the Accounts tab, and click Update (at the bottom of the tab). If you have your own SAS internal account, you can also update your internal password in SAS Personal Login Manager.

T I P

If repeated attempts to log on with an internal account fail, that account might be locked. See

“Unlock an Internal Account” on page 37 .

Managed Passwords

Passwords for a few service accounts require special coordination because these passwords are included in configuration files. To update these passwords, use the SAS

Deployment Manager.

Identity Hierarchy

The identity hierarchy can affect authorization decisions and login priority (in credential retrieval from the SAS metadata). The identity hierarchy is not relevant for roles.

The identity hierarchy establishes the following precedence ranking:

1. the user's individual identity, based on the user's authenticated ID.

2. a group that has the user as a direct member. This is a first-level group membership for the user.

3. a group that has another user group as a direct member. For example, assume that the user belongs to a group named ETL_Advanced, and that group is a member of another group called ETL_Basic. In that case, the ETL_Basic group is a second-level group for that user. If you have additional levels of nesting, each successive level has less precedence.

Chapter 2 • User Administration

4. the SASUSERS implicit group, which includes everyone who has an individual identity.

5. the PUBLIC implicit group, which includes everyone who can access the metadata server (regardless of whether they have an individual identity or not).

The following table provides examples of the hierarchy:

Table 2.5 Examples of Identity Hierarchies

Scenario

User has no individual identity.

User has an identity and no explicit group memberships.

User is a direct member of GroupA and GroupB.

GroupA is a member of the Report Users group.

User's Identity Hierarchy

Primary identity: PUBLIC

Primary identity: self

First-level memberships: SASUSERS

Second-level memberships: PUBLIC

Primary identity: self

First-level memberships: GroupA, GroupB

Second-level memberships: Report Users

Third-level memberships: SASUSERS

Fourth-level memberships: PUBLIC

T I P

To avoid introducing unnecessary complexity, do not make PUBLIC or

SASUSERS a member of another group. For example, if you make PUBLIC a member of GroupA, then a user who is an indirect member of GroupA (through his automatic membership in PUBLIC) has GroupA as his lowest precedence membership. This contradicts the usual expectation that every user's lowest precedence membership is PUBLIC. It is not a problem for PUBLIC or SASUSERS to be a member of a role.

Note: Avoid creating circular or reciprocal group memberships (for example, GroupA is

in GroupB, GroupB is in GroupC, and GroupC is in GroupA). Such relationships introduce unnecessary complexity and can negatively impact performance. When you define nested group memberships (interactively or through importing identity information), the best practice is to use as simple and non-redundant a structure as possible.

External Identities

An external identity is a synchronization key that facilitates coordination between identity entries in the metadata and identity entries in your authentication provider. If you use batch processes to coordinate metadata identity information with your authentication provider, external identities are set up and used as follows:

Windows Privileges

1. In your authentication provider, you select a field to use for the mapping. This should be a field that contains a unique and unchanging value for each user, group, and role that you want to manage with batch processes. Typically, this is an identifier such as employee number.

2. When you perform an initial import from your authentication provider into the metadata, the keyid values in the canonical tables become external identity values in the metadata. Each imported identity has at least one external identity value.

3. During the synchronization process, external identity values that are extracted from the metadata are used as the keyid in the target tables. Because these values also exist in the extraction from your authentication provider, external identity values can be used to match corresponding entries in the two sets of tables.

Note: If you need to incorporate manually created identities into a batch synchronization

process, manage each identity’s external identity value from the General properties of its metadata definition.

Windows Privileges

Access This Computer from the Network

Table 2.6 Access This Computer from the Network

Description

To Whom

How

This privilege is required in order to connect to SAS servers.

Give this privilege to all users who access SAS servers on Windows.

Typically, this right is already granted to the Windows group Everyone. To confirm, check the

Windows local policy settings.

Log on as a Batch Job

Table 2.7 Log on as a Batch Job

Description

To Whom

This privilege is required in order to run a stored process server or any type of workspace server.

On the Windows computer that hosts the SAS object spawner, give this privilege to the accounts under which workspace servers and stored process servers run:

• any service account under which one of these servers run

• all puddle logins for any client-side pooled workspace servers

• any user accounts under which a standard workspace server runs (users who authenticate by

Integrated Windows authentication or SAS token authentication do not need this privilege)

Chapter 2 • User Administration

How Modify the local security policy. For example, on Windows XP, this right is managed from the

Windows control panel under Administrative Tools ð Local Security Policy ð User Rights

Assignment ð Log on as a batch job. If you have an operating system group (such as SAS Server

Users) that has this right, you just add users and service account identities to that group.

Trusted for Delegation

Table 2.8 Trusted for Delegation

Description

To Whom

How

This privilege enables a process to allow each user's credentials to be sent to further machines for authentication (for example, to access a UNC path). The privilege is needed if the workspace server is accessed through Integrated Windows authentication and provides access to network resources.

Note: With Integrated Windows authentication, the workspace server does not receive the requesting user's credentials, so the workspace server cannot provide credentials for downstream servers. Instead, the spawner account must be trusted to delegate each requesting user's identity as necessary.

If the workspace server runs on Windows, give this privilege to the account under which the object spawner runs. By default, the spawner runs as a service under the local system account, so the computer account for spawner's host needs the privilege.

If the workspace server runs on UNIX, give this privilege to the service principal account that is referenced in the relevant keytab (the keytab is based on service principal names that correspond to a particular service principal account). For more information, see the chapter "Configuring Integrated

Windows Authentication" in Configuration Guide for SAS Foundation for UNIX Environments at http://support.sas.com/documentation/installcenter ).

As a Windows domain administrator, under Start ð Control Panel ð Administrative Tools ð

Active Directory Users and Computers, access the properties dialog box for the relevant account and grant the privilege.

If your spawner runs on Windows under the local system account, select the spawner host machine in

Active Directory under Computers. On the Delegation tab (or the General tab), select the Trust this

computer for delegation check box.

If your spawner runs on Windows under a domain account, select that account in Active Directory under Users. On the Delegation tab (or the Accounts tab), select the Account is trusted for

delegation check box.

If your spawner runs on UNIX, select the appropriate service principal account in Active Directory under Users. On the Delegation tab (or the Accounts tab), select the Account is trusted for

delegation check box.

Note: In most cases, an object spawner on Windows runs as a service under the local

system account. If the spawner instead runs under some other account, that account must be a Windows administrator on the spawner's host and have the Windows user rights Adjust memory quotas for a process and Replace a process level token.

These user rights assignments are part of the local security policy for the Windows computer that hosts the spawner.

Windows User ID Formats

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 [email protected]). 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:

Table 2.9 Overview: Forms of an Active Directory User ID

Form

Short

UPN

Basic Syntax

user user@UPNsuffix

Down-level

down-level-domain-name\user

Kerberos

user@REALM

Examples joe [email protected]

[email protected]

orionsports\joe

sales\joe

mymachine\joe [email protected]

Note: User Principal Name (UPN) is an Active Directory concept. Down-level domain

is a Windows NT concept. The realm in a Kerberos principal is usually a Windows domain. A Kerberos principal can include an instance (in the format user/

instance@REALM). Additional site-specific variations might occur. The realm

qualifier in a Kerberos principal is always in uppercase.

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

Chapter 2 • User Administration

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.

Uniqueness Requirements

The metadata server enforces the following identity-related constraints:

• You cannot create a user definition that has the same name as an existing user definition. The display names do not have to be unique.

T I P

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

• You cannot change the name of an existing user, group, or role in SAS Management

Console. You can change the display name.

• You cannot create a group or role definition that has the same name as an existing group or role definition. The display names do not have to be unique.

• You cannot assign the same external account ID to two different identities. All of the logins that include a particular ID must be owned by the same identity. This requirement enables the metadata server to resolve each ID to a single identity.

However, a login that is associated with an outbound authentication domain is exempt from this requirement. For more information, see

“Outbound and Trusted

Authentication Domains” on page 124 .

DefaultAuth. In that case, you cannot give any other user a login with the ID

smith, even if you plan to assign the login to a different SAS authentication

domain.

T I P

To enable multiple users to share an account, store the credentials for that account in a login as part of a group definition. Then add the users who share the account as members of that group definition.

• If you give a user two logins that contain the same ID, the logins must be associated with different authentication domains. Within an authentication domain, each ID must be unique. For example, if you give the person Tara O'Toole two logins that both have an ID of tara, then you cannot associate both of those logins with the

OraAuth authentication domain.

Note: Like the previous requirement, this requirement is case-insensitive.

Note: You cannot circumvent this constraint by supplying the same user ID in

different formats. For example, if you give a user a login that contains the user

ID WIN\user and another login that contains the user ID user@WIN, those logins must be in different authentication domains.

• A user can have multiple locations, email addresses, and telephone numbers.

However, each user can have only one item of a given type. For example, a user can have one home email address and one work email address, but not two work email addresses.

•

“Create Metadata User Definitions” on page 33

•

“How SAS Identity Is Determined” on page 114

Configuring Client Machines to Use Integrated

Windows Authentication

About Configuring Client Machines to Use IWA

This information applies to client machines that are running Java rich clients, including those that might run clients launched through Java Web Start. In addition to enabling the

Use Integrated Windows authentication (single sign-on) option during installation, there are manual steps that must be completed from each client machine. The following sections provide information about the manual steps that must be completed.

Chapter 2 • User Administration

Updating Registry Settings

By default, Windows does not allow Java to access the session key that is associated with the ticket-granting ticket (TGT) in the cache. This might cause the Java client to prompt the user for their password, or it might refuse to authenticate with the server. To enable Java access to the session key, complete one of the following workarounds:

• Update the Windows registry. Microsoft recommends performing a system backup before editing the registry. Access the HKEY_LOCAL_MACHINE\System

\CurrentControlSet\Control\Lsa\Kerberos\Parameters registry subkey. Add the

DWORD value with a name of allowtgtsessionkey and value of 1. For more information, see http://support.microsoft.com/kb/308339 .

• Run the

kinit -f

command to get a new TGT and session key from the Key

Distribution Center and cache it on the filesystem.

Note: The TGT has a limited lifespan. If you chose this workaround, you have to

periodically repeat this process.

Note: Use the kinit command that is provided in the

SASHOME

\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin

directory.

Configuring the Java Cryptography Extension

Determining Whether a Machine Is Using AES-256

IWA requires that the Java environment be updated with the Java Cryptography

Extension (JCE) Unlimited Strength Jurisdiction Policy files if the machine is using

AES-256 encrypted tickets or session keys. By default, Java is not shipped with support for AES-256 enabled. Kerberos uses AES-256 in the aes256-cts-hmac-sha1-96 encryption type that is associated with the keytab.

Determine whether a machine is using AES-256 encrypted TGT by running the

klist

command. The command displays currently cached Kerberos tickets. Here is an example of the output that you might see:

C:\Users\user_name>klist

Current LogonId is LUID

Cached Tickets: (number)

#0> Client: user_name @ domain

Server: krbtgt/domain @ domain

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent

Start Time: 5/12/2014 11:09:03 (local)

End Time: 5/12/2014 19:50:18 (local)

Renew Time: 5/19/2014 9:50:18 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: user_name @ domain

Server: krbtgt/domain @ domain

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

Note: Use the klist command that is provided in the

SASHOME

\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin

directory.

Enabling AES-256

To enable AES-256, you must download the Unlimited Strength Java Cryptography

Extension (JCE) policy files and install them into the directory where the JRE is configured, follow these steps:

1. Download the JCE Unlimited Strength Jurisdiction Policy files from Oracle. Be sure to download the version that corresponds to the version of Java that is installed. It is available from http://www.oracle.com/technetwork/java/javase/downloads/ index.html

2. Extract the archive. In the

jce

directory, extract all three files (local_policy.jar,

README.txt, and US_export_policy.jar) to

JAVA_HOME\jre\lib\security

Note: For a SAS installation, the default JRE is located in

SASHome

\SASPrivateJavaRuntimeEnvironment\9.4\jre

. For client machines using Java Web Start, the JRE location depends on the Java Web Start configuration. Verify the JRE settings in the Java Control Path by navigating to

Control Panel

Java.

•

“Integrated Windows Authentication” on page 139

•

“How to Configure Integrated Windows Authentication” on page 165

Chapter 2 • User Administration