可供使用應用程式 Proxy 單一登入應用程式的 Kerberos 限制委派Kerberos Constrained Delegation for single sign-on to your apps with Application Proxy

您可以針對透過應用程式 Proxy 發佈並使用整合式 Windows 驗證保護的內部部署應用程式,提供單一登入。You can provide single sign-on for on-premises applications published through Application Proxy that are secured with Integrated Windows Authentication. 這些應用程式需要 Kerberos 票證以進行存取。These applications require a Kerberos ticket for access. 應用程式 Proxy 會使用 Kerberos 限制委派 (KCD) 來支援這些應用程式。Application Proxy uses Kerberos Constrained Delegation (KCD) to support these applications.

您可以在 Active Directory 中提供應用程式 Proxy 連接器權限來模擬使用者,以使用「整合式 Windows 驗證」(IWA) 啟用應用程式的單一登入。You can enable single sign-on to your applications using Integrated Windows Authentication (IWA) by giving Application Proxy connectors permission in Active Directory to impersonate users. 連接器會使用此權限來代表其傳送和接收權杖。The connectors use this permission to send and receive tokens on their behalf.

使用 KCD 單一登入的運作方式How single sign-on with KCD works

此圖說明當使用者嘗試存取使用 IWA 的內部部署應用程式時的流程。This diagram explains the flow when a user attempts to access an on premises application that uses IWA.

Microsoft AAD 驗證流程圖

  1. 使用者輸入 URL, 以透過應用程式 Proxy 存取內部部署應用程式。The user enters the URL to access the on premises application through Application Proxy.
  2. 「應用程式 Proxy」將要求重新導向至 Azure AD 驗證服務,以進行預先驗證。Application Proxy redirects the request to Azure AD authentication services to preauthenticate. 此時,Azure AD 會套用任何適用的驗證和授權原則,例如多重要素驗證。At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. 若使用者通過驗證,Azure AD 會建立權杖並將它傳送給使用者。If the user is validated, Azure AD creates a token and sends it to the user.
  3. 使用者將權杖傳遞給「應用程式 Proxy」。The user passes the token to Application Proxy.
  4. 應用程式 Proxy 會驗證權杖, 並從它抓取使用者主體名稱 (UPN), 然後連接器會透過雙重驗證的安全通道提取 UPN 和服務主體名稱 (SPN)。Application Proxy validates the token and retrieves the User Principal Name (UPN) from it, and then the Connector pulls the UPN, and the Service Principal Name (SPN) through a dually authenticated secure channel.
  5. 連接器會對內部部署 AD 執行 Kerberos 限制委派 (KCD) 協商, 模擬使用者以取得應用程式的 Kerberos 權杖。The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on premises AD, impersonating the user to get a Kerberos token to the application.
  6. Active Directory 會將應用程式的 Kerberos 權杖傳送至「連接器」。Active Directory sends the Kerberos token for the application to the Connector.
  7. 「連接器」會使用從 AD 接收的 Kerberos 權杖,將原始要求傳送至應用程式伺服器。The Connector sends the original request to the application server, using the Kerberos token it received from AD.
  8. 應用程式會傳送回應至「連接器」,然後再傳回至「應用程式 Proxy」服務,最後再傳回給使用者。The application sends the response to the Connector, which is then returned to the Application Proxy service and finally to the user.

必要條件Prerequisites

開始使用 IWA 應用程式的單一登入之前,請確定您的環境已完成下列設定和組態︰Before you get started with single sign-on for IWA applications, make sure your environment is ready with the following settings and configurations:

  • 您的應用程式 (例如 SharePoint Web 應用程式) 已設為使用「整合式 Windows 驗證」。Your apps, like SharePoint Web apps, are set to use Integrated Windows Authentication. 如需詳細資訊,請參閱啟用支援 Kerberos 驗證,或者若是使用 SharePoint,請參閱為 SharePoint 2013 中的 Kerberos 驗證做規劃For more information, see Enable Support for Kerberos Authentication, or for SharePoint see Plan for Kerberos authentication in SharePoint 2013.
  • 您的所有應用程式都有服務主體名稱All your apps have Service Principal Names.
  • 執行「連接器」的伺服器與執行應用程式的伺服器,皆已加入網域且屬於相同網域或信任網域。The server running the Connector and the server running the app are domain joined and part of the same domain or trusting domains. 如需有關加入網域的詳細資訊,請參閱 將電腦加入網域For more information on domain join, see Join a Computer to a Domain.
  • 執行「連接器」的伺服器有權限讀取使用者的 TokenGroupsGlobalAndUniversal 屬性。The server running the Connector has access to read the TokenGroupsGlobalAndUniversal attribute for users. 這個預設設定可能已受到環境強化安全性所影響。This default setting might have been impacted by security hardening the environment.

設定 Active DirectoryConfigure Active Directory

根據您的「應用程式 Proxy 連接器」和應用程式伺服器是否位於相同的網域,Active Directory 組態會有所不同。The Active Directory configuration varies, depending on whether your Application Proxy connector and the application server are in the same domain or not.

連接器和應用程式伺服器位於相同網域Connector and application server in the same domain

  1. 在 Active Directory 中,移至 [工具] > [使用者和電腦]。In Active Directory, go to Tools > Users and Computers.

  2. 選取正在執行連接器的伺服器。Select the server running the connector.

  3. 按一下滑鼠右鍵,然後選取 [屬性] > [委派]。Right-click and select Properties > Delegation.

  4. 選取 [信任這台電腦,但只委派指定的服務]。Select Trust this computer for delegation to specified services only.

  5. 選取 [使用任何驗證通訊協定]。Select Use any authentication protocol.

  6. 在 [這個帳戶可以呈送委派認證的服務] 下方,新增應用程式伺服器的 SPN 身分識別值。Under Services to which this account can present delegated credentials add the value for the SPN identity of the application server. 這可讓「應用程式 Proxy 連接器」針對清單中所定義的應用程式,在 AD 中模擬使用者。This enables the Application Proxy Connector to impersonate users in AD against the applications defined in the list.

    [連接器 SVR 屬性] 視窗螢幕擷取畫面

連接器和應用程式伺服器位於不同網域Connector and application server in different domains

  1. 如需跨網域使用 KCD 的先決條件清單,請參閱 跨網域的 Kerberos 限制委派For a list of prerequisites for working with KCD across domains, see Kerberos Constrained Delegation across domains.
  2. 使用「連接器」伺服器的 principalsallowedtodelegateto 屬性,讓應用程式 Proxy 能夠委派連接器伺服器。Use the principalsallowedtodelegateto property on the Connector server to enable the Application Proxy to delegate for the Connector server. 應用程式伺服器為 sharepointserviceaccount,而委派的伺服器為 connectormachineaccountThe application server is sharepointserviceaccount and the delegating server is connectormachineaccount. 在 Windows 2012 R2 中,以此程式碼作為範例:For Windows 2012 R2, use this code as an example:
$connector= Get-ADComputer -Identity connectormachineaccount -server dc.connectordomain.com

Set-ADComputer -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADComputer sharepointserviceaccount -Properties PrincipalsAllowedToDelegateToAccount

sharepointserviceaccount 可以是 SPS 電腦帳戶,或是用來執行 SPS 應用程式集區的服務帳戶。sharepointserviceaccount can be the SPS machine account or a service account under which the SPS app pool is running.

設定單一登入Configure single sign-on

  1. 根據 使用應用程式 Proxy 發佈應用程式中的所述指示來發佈您的應用程式。Publish your application according to the instructions described in Publish applications with Application Proxy. 請務必選取 [Azure Active Directory] 作為 [預先驗證方法]。Make sure to select Azure Active Directory as the Preauthentication Method.

  2. 應用程式出現於企業應用程式清單後,將其選取並按一下 [單一登入]。After your application appears in the list of enterprise applications, select it and click Single sign-on.

  3. 將單一登入模式設定為 [整合式 Windows 驗證]。Set the single sign-on mode to Integrated Windows Authentication.

  4. 輸入應用程式伺服器的 [內部應用程式 SPN] 。Enter the Internal Application SPN of the application server. 在此範例中,已發佈應用程式的 SPN 為 http/www.contoso.com。In this example, the SPN for our published application is http/www.contoso.com. 此 SPN 必須在連接器可以呈送委派認證的服務清單中。This SPN needs to be in the list of services to which the connector can present delegated credentials.

  5. 針對要代表使用者使用的連接器選擇 [委派的登入身分識別]。Choose the Delegated Login Identity for the connector to use on behalf of your users. 如需詳細資訊,請參閱使用不同的內部部署和雲端身分識別For more information, see Working with different on-premises and cloud identities

    進階應用程式組態

非 Windows 應用程式的 SSOSSO for non-Windows apps

Azure AD 應用程式 Proxy 的 Kerberos 委派流程會在 Azure AD 在雲端驗證使用者開始。The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the cloud. 一旦要求到達內部部署,Azure AD 應用程式 Proxy 連接器會利用與本機 Active Directory 互動,代表使用者發出 Kerberos 票證。Once the request arrives on-premises, the Azure AD Application Proxy connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. 此程序稱為「Kerberos 限制委派 (KCD)」。This process is referred to as Kerberos Constrained Delegation (KCD). 在下一個階段中,要求會傳送至具有此 Kerberos 票證的後端應用程式。In the next phase, a request is sent to the backend application with this Kerberos ticket.

有許多定義如何傳送這類要求的通訊協定。There are several protocols that define how to send such requests. 預期大部分的非 Windows 伺服器都會與 SPNEGO 進行交涉。Most non-Windows servers expect to negotiate with SPNEGO. Azure AD 應用程式 Proxy 支援此通訊協定,但預設為停用。This protocol is supported on Azure AD Application Proxy, but is disabled by default. 您可將伺服器設定為 SPNEGO 或標準 KCD ,但無法同時設定為兩者。A server can be configured for SPNEGO or standard KCD, but not both.

如果您為 SPNEGO 設定連接器電腦,請確定該連接器群組中的所有其他連接器也都已採用 SPNEGO 進行設定。If you configure a connector machine for SPNEGO, make sure that all other connectors in that Connector group are also configured with SPNEGO. 預定採用標準 KCD 的應用程式則應透過其他並非針對 SPNEGO 進行設定的連接器路由傳送。Applications expecting standard KCD should be routed through other connectors that are not configured for SPNEGO.

若要啟用 SPNEGO:To enable SPNEGO:

  1. 開啟以系統管理員身分執行的命令提示字元。Open an command prompt that runs as administrator.

  2. 透過命令提示字元,在需要 SPNEGO 的連接器伺服器中執行下列命令。From the command prompt, run the following commands on the connector servers that need SPNEGO.

    REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft AAD App Proxy Connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
    net stop WAPCSvc & net start WAPCSvc
    

如需有關 Kerberos 的詳細資訊,請參閱有關 Kerberos 限制委派 (KCD) 您想要知道的一切For more information about Kerberos, see All you want to know about Kerberos Constrained Delegation (KCD).

非 Windows 應用程式通常會使用使用者名稱或 SAM 帳戶名稱,而不是網域的電子郵件地址。Non-Windows apps typically user usernames or SAM account names instead of domain email addresses. 如果這種情況適用於您的應用程式,就必須設定指定的登入身分識別欄位,將您的雲端身分識別連線到您的應用程式身分識別。If that situation applies to your applications, you need to configure the delegated login identity field to connect your cloud identities to your application identities.

使用不同的內部部署和雲端身分識別Working with different on-premises and cloud identities

應用程式 Proxy 會假設使用者在雲端與內部部署中具有完全相同的身分識別。Application Proxy assumes that users have exactly the same identity in the cloud and on-premises. 但是在某些環境中, 由於公司原則或應用程式相依性的緣故, 組織可能必須使用替代識別碼來進行登入。But in some environments, due to corporate policies or application dependencies, organizations might have to use alternate IDs for sign-in. 在這種情況下, 您仍然可以使用 KCD 進行單一登入。In such cases, you can still use KCD for single sign-on. 為每個應用程式設定 [委派的身分識別登入],以指定在執行單一登入時所應使用的身分識別。Configure a Delegated login identity for each application to specify which identity should be used when performing single sign-on.

此功能可讓具有不同內部部署與雲端身分識別的許多組織,可從雲端單一登入到內部部署應用程式,而不需要使用者輸入不同的使用者名稱與密碼。This capability allows many organizations that have different on-premises and cloud identities to have SSO from the cloud to on-premises apps without requiring the users to enter different usernames and passwords. 這包括下列組織:This includes organizations that:

  • 在內部有多個網域 (joe@us.contoso.com、joe@eu.contoso.com),並且在雲端有單一網域 (joe@contoso.com)。Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the cloud (joe@contoso.com).
  • 在內部有無法路由傳送的網域名稱 (joe@contoso.usa),並且在雲端有合法網域名稱。Have non-routable domain name internally (joe@contoso.usa) and a legal one in the cloud.
  • 請勿在內部使用網域名稱 (joe)Do not use domain names internally (joe)
  • 在內部部署和雲端中使用不同的別名。Use different aliases on premises and in the cloud. 例如:joe-johns@contoso.com 對上 joej@contoso.comFor example, joe-johns@contoso.com vs. joej@contoso.com

使用應用程式 Proxy,您就可以選取要用來取得 Kerberos 票證的身分識別。With Application Proxy, you can select which identity to use to obtain the Kerberos ticket. 這項設定會因應用程式而異。This setting is per application. 其中的一些選項適合不接受電子郵件地址格式的系統,另外的選項則設計用於替代登入。Some of these options are suitable for systems that do not accept email address format, others are designed for alternative login.

[委派的登入身分識別] 參數螢幕擷取畫面

如果使用委派的登入身分識別,則組織的所有網域或樹系中的這個值可能不是唯一。If delegated login identity is used, the value might not be unique across all the domains or forests in your organization. 您可以藉由使用兩個不同的連接器群組發佈這些應用程式兩次來避免此問題。You can avoid this issue by publishing these applications twice using two different Connector groups. 因為每個應用程式有不同的使用者對象,您可以將其「連接器」加入不同的網域。Since each application has a different user audience, you can join its Connectors to a different domain.

設定不同身分識別的 SSOConfigure SSO for different identities

  1. 設定 Azure AD Connect 設定,讓主要的身分識別會是電子郵件地址 (郵件)。Configure Azure AD Connect settings so the main identity is the email address (mail). 這是在自訂程序中完成 (透過變更同步設定中的 [使用者主體名稱] 欄位)。This is done as part of the customize process, by changing the User Principal Name field in the sync settings. 這些設定也決定使用者如何登入 Office 365、Windows 10 裝置與其他使用 Azure AD 作為其身分識別存放區的應用程式。These settings also determine how users log in to Office365, Windows10 devices, and other applications that use Azure AD as their identity store.
    識別使用者螢幕擷取畫面 - [使用者主體名稱] 下拉式清單Identifying users screenshot - User Principal Name dropdown

  2. 在您想要修改之應用程式的應用程式組態設定中,選取要使用的 [委派的登入識別] :In the Application Configuration settings for the application you would like to modify, select the Delegated Login Identity to be used:

    • 使用者主體名稱 (例如 joe@contoso.com)User Principal Name (for example, joe@contoso.com)
    • 替代使用者主體名稱 (例如 joed@contoso.local)Alternate User Principal Name (for example, joed@contoso.local)
    • 使用者主體名稱的使用者名稱部分 (例如 joe)Username part of User Principal Name (for example, joe)
    • 替代使用者主體名稱的使用者名稱部分 (例如 joed)Username part of Alternate User Principal Name (for example, joed)
    • 內部部署 SAM 帳戶名稱 (視網域控制站組態而定)On-premises SAM account name (depends on the domain controller configuration)

疑難排解不同身分識別的 SSOTroubleshooting SSO for different identities

如果 SSO 程序發生錯誤,它會顯示在連接器電腦事件記錄中,如疑難排解所述。If there is an error in the SSO process, it appears in the connector machine event log as explained in Troubleshooting. 但在某些情況下,要求會成功傳送至後端應用程式,同時此應用程式會以各種其他 HTTP 回應來回覆。But, in some cases, the request is successfully sent to the backend application while this application replies in various other HTTP responses. 疑難排解這些情況應該要從檢查連接器電腦上應用程式 Proxy 工作階段事件記錄中的事件編號 24029 開始。Troubleshooting these cases should start by examining event number 24029 on the connector machine in the Application Proxy session event log. 用於委派的使用者身分識別會出現在事件詳細資料的 [使用者] 欄位內。The user identity that was used for delegation appears in the “user” field within the event details. 若要開啟工作階段記錄,請選取事件檢視器檢視功能表中的 [顯示分析與偵錯記錄]。To turn on session log, select Show analytic and debug logs in the event viewer view menu.

後續步驟Next steps

如需最新消息,請查閱 應用程式 Proxy 部落格For the latest news and updates, check out the Application Proxy blog