A security engineer needs to implement Microsoft Entra ID Application Proxy to publish an internal AI web application securely for remote workers, without requiring a VPN. The AI application uses Windows Integrated Authentication (WIA) for on-premises users. How should Kerberos Constrained Delegation (KCD) be configured for Application Proxy?

Configuring KCD on the Application Proxy connector server's computer account in Active Directory for the AI application's service account SPN is correct because, for Kerberos Constrained Delegation with Microsoft Entra Application Proxy, the connector server's computer account or a dedicated service account must be configured in Active Directory with constrained delegation rights to the target application's Service Principal Name. This is done in Active Directory Users and Computers on the connector machine's account properties, on the Delegation tab. Configuring KCD in the Microsoft Entra Application Proxy settings in the Entra admin center by entering the application's SPN is incorrect because, while the Entra admin center Application Proxy settings can specify the Internal Application SPN used to configure KCD, the actual KCD permission must be granted in on-premises Active Directory, not just in the Entra admin center. Deploying Microsoft Entra Kerberos for cloud Kerberos trust and configuring the connector to use cloud TGTs is incorrect because Microsoft Entra Kerberos for cloud Kerberos trust is for enabling passwordless or FIDO2 authentication to on-premises resources, not for Application Proxy KCD scenarios. Configuring the Application Proxy connector to use certificate-based authentication instead of KCD for WIA applications is incorrect because certificate-based authentication would change the authentication method for all users, not preserve WIA for existing internal users.