Error 500 on Web Application Proxy for Non-claims based application

Question

I am configuring Windows Active Directory SSO I built a Lab according to the tutorial here: https://technet.microsoft.com/en-us/library/dn280943.aspx

After setting the lab, I am connecting from an external client using internet explorer:

• The claims-based webapp is working perfectly fine
• I have a problem with the non-claims-based webpage (IIS startpage with windows authentication)

The authentication page appears

After login, I am redirected to a HTTP 500 error page.

The URL worked fine from internal network, without using the Web App Proxy.

Is there someone that could help me to solve this issue?

Wishing you pleasant day

P.S: You can find the the lab diagram and configurations details and screenshots below

Windows 2012 R2 Domain controller + DNS Server

• IP: 192.168.22.1
• Domain: contoso.com
• Trusting computer WAP for authentication delegation (192.168.22.15) for specified SPNs: HTTP/WAP and HTTP/WAP.contoso.com

Windows 2012 R2 Active Directory Federation Service

• IP: 192.168.22.2
• Domain: contoso.com
• Federation URL: adfs1.contoso.com
• Relying Party trust: Non Claim aware, iddentifier: webapp2.contoso.com, issuance authorization "Permit Access to all users"

Windows 2012 R2 IIS Server

• IP: 192.168.22.20
• Non-claims aware application
• URL: webapp2.contoso.com
• Domain: contoso.com
• SPNs: HTTP/WEBAPP2 and HTTP/WEBAPP2.contoso.com

Windows 2012 R2 Web Application proxy

• IP: 192.168.22.15
• IP External: 10.0.0.1
• SPN: HTTP/WAP and HTTP/WAP.contoso.com
• Using the Non claim aware relying party trust
• Frontend and Backend URL: webapp2.contoso.com
• Backend SPN: HTTP/WEBAPP2.contoso.com

External Client

• IP: 10.0.0.2

Host file

10.0.0.1 webapp2.contoso.com
10.0.0.1 adfs1.contoso.com
10.0.0.1 enterpriseregistration.contoso.com

Diagram

Web App Proxy config

ADFS Config

IIS Config

Client config

DC Config

DNS Config

Answer 1

Technet articles are a bit vague about correct SPN entries.

Try checking for duplicates using:

setspn -X

Also you can check Event Log:

• WAP server in 'Remote Access' section. It would give you an idea which step of the communication fails.
• AD server, enable Kerberos logging first.

As a last resort you can use WireShare or Message Analyzer to sniff through network traffic and see what's wrong with the communication.

Answer 2

This is apparentlty a WAP/kerberso issue. you need to restart the WAP server in KCD mode.