Objective: Configure Single Sign-On with KCD and synchronization with Azure AD Connect

Reference: Kerberos Constrained Delegation for single sign-on to your apps with Application Proxy

To support single sign-on, configure with Integrated Windows Authentication mode

In the Azure Portal, go to Azure AD > Enterprise Applications > click on your Enterprise Application > click Single sign-on > Select Mode Integrated Windows Authentication

For Internal Application SPN, enter http/rksp.eastus.cloudapp.azure.com (Go to blog Part 2 for KCD setup)Click Save

By visiting the SharePoint application again and attempting to login, the browser displays the error message:This is because the user does not exist in on-premises AD.

Let’s install Azure AD Connect in the on-premises environment to synchronize users from on-premises AD to Azure AD.

Download Azure AD Connect. For my lab environment and for simplicity, I installed it on the SP server. It is recommended to install on a dedicated server.
In the Azure AD Directory, add a domain that is the same as your on-premises environment that you own and can verify.

In my case, contoso.com is the default domain that was provisioned with the SharePoint Non-HA Azure ARM template, I cannot own this public domain from any domain registrar, such as GoDaddy. Therefore I cannot verify in my Azure AD. Therefore, I will resort to the UPN as spb2b.onmicrosoft.com in my Azure AD. This will be sufficient for the purposes of this demo.

As a result of the Azure AD Sync, we can see users from the AD server. However, note that the on-premises AD user accounts end with @spb2b.onmicrosoft.com rather than @contoso.com.

Now you are one step closer to login with these accounts given that they have permissions to the SharePoint site. The next blog will finish the configuration and test a successful login scenario to the published SharePoint site.

Next: Azure AD Azure Application Proxy with SharePoint Server 2013/2016 Blog Part 6