Authentication Model

Credential Gaps

A credential gap is a situation in which a user doesn't seamlessly access the workspace server for any of these reasons:

Server configurations are incorrect, incomplete, or incompatible.
The user's context doesn't include credentials that are known to the workspace server's host.
The user's context doesn't pair credentials that are known to the workspace server's host with the workspace server's authentication domain.
The workspace server is on Windows, using credential-based authentication and the user's host account doesn't have the Log on as a batch job privilege (see Windows Privileges).

The usual symptom of a credential gap is a prompt for a user ID and password after a user makes a request that requires a workspace server (for example, querying relational data). A credential gap can be problematic for these reasons:

The prompts interrupt the user experience.
Users have to know credentials that are valid for the workspace server's host and know that those are the correct credentials to provide.
Not all middle-tier services and Web applications prompt for credentials (and, without a prompt, the user request fails).

You can use the questions in the following table to diagnose and troubleshoot a credential gap.

Credential Gaps: Causes and Solutions
	Is the user logging on with a user ID that ends in @saspw? If so, tell the user that they get the prompt because they are using an internal account. When the user gets the additional prompt, they must enter a user ID and password that are known to the workspace server's host.¹ See Add Administrators.
	Is the user logging on with a connection profile that contains a user ID that ends in @saspw? If so, the user's context doesn't pair the credentials from the user's initial logon with the DefaultAuth authentication domain. Tell the user to create a new connection profile with external credentials (and no value in the Authentication domain field) and try again. To ensure optimal credential reuse, users shouldn't use the same connection profile for both internal and external accounts. See Credential Management.
	Is the user using a connection profile that has a value other than DefaultAuth for the authentication domain? If so, the user's context doesn't pair the credentials from the user's initial logon with the DefaultAuth authentication domain. Tell the user to either clear this field or enter the value DefaultAuth and try again. See Credential Management.
	Is the user in SAS Enterprise Guide and accessing a workspace server that is set to prompt? If so, verify the setting on the Options tab of the logical workspace server. If the setting is intentional, tell the user to supply host credentials.¹ See About the Workspace Server's Options Tab.
	Do the metadata server and the workspace server accept different accounts? If so, the credentials that are added to the user's context from the user's initial logon aren't valid for the workspace server. For example, this can happen if the metadata server is on Windows and the workspace server is on UNIX. See Mixed Providers.
	Is the workspace server assigned to the wrong authentication domain? If so, credential reuse might be impaired. In most configurations, the workspace server should be in DefaultAuth.² To verify (and, if necessary, correct) the workspace server's authentication domain assignment, select the Plug-ins tab in SAS Management Console, navigate to the server , select its connection object , right-click, and select Properties. The authentication domain assignment is on the Options tab. See Credential Management.
	Is the user using a Web application at a site that has configured Web authentication? If so, the user's initial logon doesn't add a password to the user's context. Make sure that the Web application uses some form of pooling. See Choices in Workspace Server Pooling. If the problem persists, the user is performing one of a few tasks that require a standard workspace server. Either restructure the activity (for example, a stored process in an information map uses pooling but a stored process that is opened directly from SAS Web Report Studio does not) or see Coordinate the Workspace Server.
	Is the user connecting to the metadata server with Integrated Windows authentication? If so, the user's initial logon doesn't add a password to the user's context. Configure the workspace server for IWA. See Integrated Windows Authentication. If the problem persists, make sure there is a logical pooled workspace server available to the user. See Choices in Workspace Server Pooling. Or, tell the user to deselect the IWA setting in his or her connection profile and try again. If this resolves the problem, the user must opt out of IWA when performing this task.
1 The host account must correspond to a metadata identity that has ReadMetadata permission for the server definition. On Windows, the host account must have the Log on as a batch job privilege. 2 Unless you resolved mixed providers by putting the workspace server in its own authentication domain.

Top of Page