See Also
 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Context requirements are expressed as a combination of bit flags passed to either the InitializeSecurityContextfunction or the AcceptSecurityContextfunction. These flags affect the context in many ways: not all flags apply to all contexts, some flags are valid only for the server, and other flags are valid only for the client.
The caller uses the fContextReqparameter of the InitializeSecurityContextor the AcceptSecurityContextfunction to specify a set of flags that indicate the required capabilities. When the function returns, the pfContextAttrparameter indicates the attributes of the established context. The caller is responsible for determining if the final context attributes are acceptable. For example, if the caller requested mutual authentication, but the security package indicates that it did not perform such authentication, the caller must decide whether to cancel the context or continue without authentication.
Initialization Flags
Flags requested from or returned by InitializeSecurityContextare prefixed by ISC. Flags passed into a function include REQ, while returned flags include RET.
For example, ISC_REQ_DELEGATE is a request flag for delegation passed to InitializeSecurityContext.
Acceptance Flags
Flags requested from or returned by AcceptSecurityContextare prefixed by ASC. Flags passed into a function include REQ, while returned flags include RET.
For example, ASC_REQ_MUTUAL_AUTH is a request flag for mutual authentication passed to AcceptSecurityContext. If mutual authentication is achieved, InitializeSecurityContextreturns ISC_RET_MUTUAL_AUTH and AcceptSecurityContextreturns ASC_RET_MUTUAL_AUTH.
The following table shows the various context requirements.
| Type | Description |
|---|---|
|
DELEGATE |
Indicates that the server in the transport application requires simple delegation rights, that is, impersonation of the client on the node at which the server is executing. |
|
MUTUAL_AUTH |
Indicates that both client and server must authenticate the peer identity. |
|
REPLAY_DETECT |
Indicates that the context should be established to enable detection of replayed packets later through the message support functions: MakeSignatureand VerifySignature. This context implies INTEGRITY. |
|
SEQUENCE_DETECT |
Indicates that the context should be established to enable detection of out-of-order delivery of packets later through the message support functions. This context implies INTEGRITY. |
|
CONFIDENTIALITY |
Indicates that the context should be established to protect data while in transit. This context type is reserved for future use. |
|
USE_SESSION_KEY |
Indicates that a new session key should be negotiated. |
|
PROMPT_FOR_CREDS |
Indicates that the security package should prompt the user for the appropriate credentials, and, if possible, determine if the client is an interactive user. |
|
USE_SUPPLIED_CREDS |
Indicates that package-specific credential data is available in the input buffer. The security package should use these credentials to authenticate the connection. |
|
ALLOCATE_MEMORY |
Indicates that the security package should allocate memory. The caller must eventually call the FreeContextBufferfunction to free memory allocated by the security package. |
|
USE_DCE_STYLE |
Indicates that the caller expects a three-transfer authentication transaction. |
|
DATAGRAM |
Indicates datagram semantics should be used. |
|
CONNECTION |
Indicates connection semantics should be used. |
|
STREAM |
Indicates stream semantics should be used. |
|
EXTENDED_ERROR |
Indicates that if the context fails, the application will generate an error reply message for the peer. |
|
INTEGRITY |
Indicates that buffer integrity can be verified, but that no sequencing or reply detection is enabled. |
See Also
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at webmaster@systemmanager.forsenergy.ru to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.