AcceptSecurityCoNtext (NTLM) 函式

  • 發行項

AcceptSecurityCoNtext (NTLM) 函式可讓傳輸應用程式的伺服器元件在伺服器與遠端用戶端之間建立安全性內容。 遠端用戶端會使用 InitializeSecurityCoNtext (NTLM) 函式來啟動建立 安全性內容的程式。 伺服器可能需要來自遠端用戶端的一或多個回復權杖，才能完成 建立安全性內容。

語法

SECURITY_STATUS SEC_Entry AcceptSecurityContext(
  _In_opt_    PCredHandle    phCredential,
  _Inout_opt_ PCtxtHandle    phContext,
  _In_opt_    PSecBufferDesc pInput,
  _In_        ULONG          fContextReq,
  _In_        ULONG          TargetDataRep,
  _Inout_opt_ PCtxtHandle    phNewContext,
  _Inout_opt_ PSecBufferDesc pOutput,
  _Out_       PULONG         pfContextAttr,
  _Out_opt_   PTimeStamp     ptsTimeStamp
);

參數

phCredential[in, optional]

伺服器的認證控制碼。 伺服器會呼叫 AcquireCredentialsHandle (NTLM) 函式，並將 SECPKG_CRED_INBOUND 或 SECPKG_CRED_BOTH 旗標設定為擷取此控制碼。

phCoNtext[in, out, optional]

CtxtHandle結構的指標。 在第一次呼叫 AcceptSecurityCoNtext (NTLM) 時，此指標為 NULL 。 在後續呼叫時， phCoNtext 是第一次呼叫 在 phNewCoNtext 參數中傳回之部分形成內容的控制碼。

警告

請勿在 對 AcceptSecurityCoNtext 的 並行呼叫中使用相同的內容控制碼， (NTLM) 。 安全性服務提供者中的 API 實作不是安全線程。

pInput[in, optional]

用戶端呼叫InitializeSecurityCoNtext (NTLM) 包含輸入緩衝區描述項的SecBufferDesc結構指標。

除了呼叫InitializeSecurityCoNtext (General) 函式所產生的緩衝區之外，還可以傳入 type SECBUFFER_CHANNEL_BINDINGS類型的SecBuffer結構來指定通道系結資訊。 您可以在用戶端用來驗證的通道內容上呼叫 QueryCoNtextAttributes (Schannel) 函式，以取得通道系結緩衝區的通道系結資訊。

fCoNtextReq[in]

指定伺服器建立內容所需屬性的位旗標。 您可以使用位OR 作業來合併位旗標。 此參數可以是下列一或多個值。

值 意義
ASC_REQ_CONFIDENTIALITY 加密和解密訊息。
ASC_REQ_CONNECTION 安全性內容不會處理格式化訊息。
ASC_REQ_EXTENDED_ERROR 發生錯誤時，將會通知遠端合作物件。
ASC_REQ_INTEGRITY 簽署訊息並驗證簽章。
ASC_REQ_REPLAY_DETECT 偵測重新執行的封包。
ASC_REQ_SEQUENCE_DETECT 偵測序列外收到的訊息。

如需可能的屬性旗標及其意義，請參閱 內容需求。 用於此參數的旗標前面會加上 ASC_REQ，例如ASC_REQ_DELEGATE。

用戶端可能不支援要求的屬性。 如需詳細資訊，請參閱 pfCoNtextAttr 參數。

TargetDataRep[in]

目標上的資料標記法，例如位元組排序。 這個參數可以是SECURITY_NATIVE_DREP或SECURITY_NETWORK_DREP。

phNewCoNtext[in, out, optional]

CtxtHandle結構的指標。 在第一次呼叫 AcceptSecurityCoNtext (NTLM) 時，此指標會收到新的內容控制碼。 在後續呼叫時， phNewCoNtext 可以與 phCoNtext 參數中指定的控制碼相同。 phNewCoNtext 不應該是 NULL 。

pOutput[in, out, optional]

SecBufferDesc結構的指標，其中包含輸出緩衝區描述項。 這個緩衝區會傳送給用戶端，以輸入至 對 InitializeSecurityCoNtext (NTLM) 的其他呼叫。 即使函式傳回SEC_E_OK，也可能產生輸出緩衝區。 產生的任何緩衝區都必須傳回給用戶端應用程式。

pfCoNtextAttr[out]

變數的指標，接收一組位旗標，指出已建立內容的屬性。 如需各種屬性的描述，請參閱 內容需求。 用於此參數的旗標前面會加上 ASC_RET，例如ASC_RET_DELEGATE。

在最終函式呼叫成功傳回之前，請勿檢查安全性相關屬性。 屬性旗標與安全性無關，例如ASC_RET_ALLOCATED_MEMORY旗標，可以在最終傳回之前檢查。

ptsTimeStamp[out, optional]

TimeStamp結構的指標，可接收內容的到期時間。 建議 安全性套件 一律以當地時間傳回此值。

注意

在最後一次呼叫驗證程式之前，內容到期時間可能不正確，因為交涉稍後階段會提供更多資訊。 因此， ptsTimeStamp 必須 NULL 等到最後一次呼叫函式為止。

傳回值

此函式會傳回下列其中一個值。

傳回碼/值描述
SEC_E_INSUFFICIENT_MEMORY
0x80090300L
函式失敗。 記憶體不足，無法完成要求的動作。
SEC_E_INTERNAL_ERROR
0x80090304L
函式失敗。 未對應至 SSPI 錯誤碼的錯誤。
SEC_E_INVALID_HANDLE
0x80100003L
函式失敗。 傳遞至函式的控制碼無效。
SEC_E_INVALID_TOKEN
0x80090308L
函式失敗。 傳遞至函式的權杖無效。
SEC_E_LOGON_DENIED
0x8009030CL
登入失敗。
SEC_E_NO_AUTHENTICATING_AUTHORITY
0x80090311L
函式失敗。 無法連絡任何授權單位以進行驗證。 這可能是因為下列情況所造成：
  • 驗證物件的功能變數名稱不正確。
  • 網域無法使用。
  • 信任關係失敗。
SEC_E_OK
0x00000000L
此函數已成功。 [*security coNtext*] (..接受從用戶端收到的 /secgloss/s-gly.md) 。 如果函式產生輸出權杖，則必須將它傳送至用戶端進程。
SEC_I_COMPLETE_AND_CONTINUE
0x00090314L
此函數已成功。 伺服器必須呼叫 [CompleteAuthToken] (/windows/win32/api/sspi/nf-sspi-completeauthtoken) 並將輸出權杖傳遞至用戶端。 然後，伺服器會等候用戶端的傳回權杖，然後呼叫 [AcceptSecurityCoNtext (NTLM) ] (acceptsecuritycoNtext--ntlm.md) 。
SEC_I_COMPLETE_NEEDED
0x00090313L
此函數已成功。 伺服器必須從用戶端完成建置訊息，然後呼叫 [CompleteAuthToken] (/windows/win32/api/sspi/nf-sspi-completeauthtoken) 函式。
SEC_I_CONTINUE_NEEDED
0x00090312L
此函數已成功。 伺服器必須將輸出權杖傳送至用戶端，並等候傳回的權杖。 傳回的權杖應該在 pInput 中傳遞，以呼叫 [AcceptSecurityCoNtext (NTLM) ] (acceptsecuritycoNtext--ntlm.md) 。

備註

AcceptSecurityCoNtext (NTLM) 函式是與 InitializeSecurityCoNtext (NTLM) 函式對應的伺服器。

當伺服器從用戶端收到要求時，伺服器會使用 fCoNtextReq 參數來指定會話所需的專案。 如此一來，伺服器就可以指定用戶端必須能夠使用機密或 完整性檢查的會話，而且可以拒絕不符合該需求的用戶端。 或者，伺服器不需要任何專案，而且任何用戶端都可以在 pfCoNtextAttr 參數中傳回或要求的任何專案。

對於支援多回合驗證的套件，例如相互驗證，呼叫順序如下所示：

  1. 用戶端會將權杖傳送至伺服器。
  2. 伺服器第一次呼叫 AcceptSecurityCoNtext (NTLM) ，這會產生接著傳送至用戶端的回復權杖。
  3. 用戶端會接收權杖，並將其傳遞至 InitializeSecurityCoNtext (NTLM) 。 如果 InitializeSecurityCoNtext (NTLM) 傳回SEC_E_OK，則已完成相互驗證，而且可以開始安全會話。 如果 InitializeSecurityCoNtext (NTLM) 傳回錯誤碼，則相互驗證交涉會結束。 否則， InitializeSecurityCoNtext (NTLM) 傳回的安全性權杖會傳送至用戶端，並重複步驟 2 和 3。
  4. 請勿在對AcceptSecurityCoNtext 的並行呼叫中使用 phCoNtext 值， (NTLM) 。 安全性提供者中的實作不是安全線程。

fCoNtextReq和pfCoNtextAttr參數是代表各種內容屬性的位元遮罩。 如需各種屬性的描述，請參閱 內容需求。

注意

pfCoNtextAttr參數在任何成功傳回時都是有效的，但只有在最終成功傳回時，才應該檢查內容安全性層面的相關旗標。 中繼傳回可以設定，例如ISC_RET_ALLOCATED_MEMORY旗標。

呼叫端負責判斷最終內容屬性是否足夠。 例如，如果要求機密性 (加密) ，但無法建立，某些應用程式可能會選擇立即關閉連線。 如果無法建立 安全性內容 ，伺服器必須呼叫 DeleteSecurityCoNtext 函式來釋放部分建立的內容。 如需何時呼叫 DeleteSecurityCoNtext 函式的相關資訊，請參閱 DeleteSecurityCoNtext。

建立 安全性內容 之後，伺服器應用程式可以使用 QuerySecurityCoNtextToken 函式來擷取用戶端憑證所對應的使用者帳戶控制碼。 此外，伺服器可以使用 ImpersonateSecurityCoNtext 函式來模擬使用者。

規格需求

需求 值
最低支援的用戶端 Windows XP [僅限傳統型應用程式]
最低支援的伺服器 Windows Server 2003 [僅限傳統型應用程式]
標頭 Sspi.h (包含 Security.h)
程式庫 Secur32.lib
DLL Secur32.dll

另請參閱

SSPI 函式

DeleteSecurityCoNtext

InitializeSecurityCoNtext (NTLM)