Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2014-12-07) Web Application Proxy With Kerberos Constrained Delegation (KCD)

Posted by Jorge on 2014-12-07


I was setting the Web Application Proxy to publish three apps to the outside, 2 Claims Based Apps and 1 Windows Token Based App. All three apps were using ADFS pre-authentication. Because of that in ADFS I had 2 Claims Aware Relying Party Trusts and 1 non-Claims Aware Relying Party Trust.

image

Figure 1: Published Apps Through The Web Application Proxy (WAP)

After setting up all three apps in the WAP, I wanted to test the if all apps were working through WAP. Before doing that I tried accessing all apps from the inside. From the inside all apps worked. From the outside, through WAP, the Claims Based apps worked, but the Windows Token Based app did not work, or better said, it was not accessible.

image

Figure 2: IE Error When Trying To Access The Windows Token Based App Through WAP And ADFS

image

Figure 3: Error 1 Information In the Web Application Proxy Event Log

Web Application Proxy received an HTTP request with a valid edge token.

Audience: urn:AppProxy:com
Issuer: urn:federation:fs4.adcorp.lab
Valid From: ‎2014‎-‎10‎-‎26T21:38:41.000000000Z
Expires: ‎2014‎-‎10‎-‎26T22:38:41.000000000Z
Relying Party Trust Id: c064e4b5-345d-e411-8166-000c2929d8bc
UPN: jalmeidapinto@partner.lan
Device Registration Certificate Thumbprint: <Not Applicable>

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode:
State Machine State: Idle
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 4: Error 2 Information In the Web Application Proxy Event Log

Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: No credentials are available in the security package
(0x8009030e).

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: BackendRequestProcessing_Pending
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 5: Error 3 Information In the Web Application Proxy Event Log

Web Application Proxy encountered an unexpected error while processing the request.
Error: No credentials are available in the security package
(0x8009030e)

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: OuOfOrderFEHeadersWriting
Response Code to Client: 500
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

Now, let’s think out loud to see why this is wrong, or not working. The following occurs in the order listed

  • The user on the external network uses the external URL in IE to target the application
  • The external URL resolves to the IP of the WAP and the WAP is targeted
  • WAP knows about the app being targeted and sees that pre-authentication through ADFS is enabled for it.
  • WAP sends the request to ADFS and because the user is coming from the extranet, the forms based logon page is presented to the user. If ADFS has more than claims provider trust, the home realm discovery page is shown first where the user must determine which identity provider will authenticate the user.
  • After the user has been authenticated, WAP goes to the next step. It sees the app being accessed is a Windows Token app
  • Because it is a Windows Token app, WAP expects to receive a the UPN claim type "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" with a value. Currently it is not possible to change that to expect another claim type like was possible in Unified Access Gateway (UAG)
  • Using the value from the UPN claim, it queries AD to determine the AD user account does exist, and assuming it exists, it will request kerberos tickets on behalf of the user for the service through kerberos constrained delegation (KCD). The service is identified through the SPN configured in the published app through WAP (WAP is able to do this when the Windows Server with WAP is joined to an AD domain! It cannot perform KCD when not joined to an AD domain! Also see: What’s New in Kerberos Authentication)

image

Figure 6: Backend Server SPN Identifying The Service Being Requested By The User

With just the errors above, I did not get it the first time. However, after thinking out loud, I realized I had forgotten to configure SPNs and delegation for the computer account of the WAP

So, let’s configure what needs to be configured.

WAP itself is running through a Network Service. It is not using some shared service account, but rather it is using its own computer account for KCD. Therefore the computer account of the individual WAP servers need to be configured, even if they are load balanced.

Doe every WAP server in the ball game, perform the following actions, as you can also see in the picture:

  • Add 2 SPNs to the WAP computer account:
    • HTTP/<FQDN> (e.g. HTTP/R1FSMBSVynext.ADCORP.LAB)
    • HTTP/<NetBIOS> (e.g. HTTP/R1FSMBSVynext)

image

Figure 7: Configuring 2 SPNs On The Computer Account Of The WAP Server

Now we need to configure delegation for the WAP computer account so that it is allowed to request kerberos service tickets for configured services. Also see: (2014-03-25) An Account With "Trusted For Delegation" – What Are The Risks?

In this case configure:

  • Trust this computer for delegation to specified services only
  • Use any authentication protocol

Then click the [Add] button to add the service to the list of allowed services

image

Figure 8: Configuring 2 SPNs On The Computer Account Of The WAP Server

However, which account do you add? There are a few ways to find out. Either query AD using the SPN specified in figure 6 using any of the three method in figure 9

image

Figure 9: Querying AD In Three ways For The Account Configured With A Specific SPN

…Or just go to the server and check which credentials the corresponding service is using. In this case it was a sharepoint site, whereas the IIS site was configured to use an application pool that was configured with an account.

image

Figure 10: Checking First If It Was Forced To Use An Application Pool

image

Figure 11: Checking The Advanced Settings Of The Service To Determine The Application Pool Name

image

Figure 12: Checking The Advanced Settings Of The Service To Determine The Application Pool Name

image

Figure 13: Specifying The sAMAccountName In The Object Dialog Window

image

Figure 14: Selecting The Service For Which The SPN Matches The SPN As Specified In Figure 6

image

Figure 15: After All, Committing The Config To The Directory

Now let’s try accessing the App again through WAP and ADFS….

image

Figure 16: Successful Access To The Windows Token App

Reviewing Web Application Proxy Event Log again…

image

Figure 17: Event ID Information In the Web Application Proxy Event Log

Web Application Proxy received an HTTP request with a valid edge token.

Audience: urn:AppProxy:com
Issuer: urn:federation:fs4.adcorp.lab
Valid From: ‎2014‎-‎10‎-‎26T22:02:06.000000000Z
Expires: ‎2014‎-‎10‎-‎26T23:02:06.000000000Z
Relying Party Trust Id: c064e4b5-345d-e411-8166-000c2929d8bc
UPN: jalmeidapinto@partner.lan
Device Registration Certificate Thumbprint: <Not Applicable>

Details:
Transaction ID: {b1f99230-f13d-0000-40a6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-30a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTczMjYsImV4cCI6MTQxNDM2MDkyNiwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0zMGE2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMjE6MDI6NTUuODA5WiIsInZlciI6IjEuMCJ9.GTOChpYcBD8zMgHvMPfrbNEEmYPDHi4iBVd513NJXYgPMTHZJMnD7n7ndAgN8sTPY330VLICHS2ccSXgRzGcayNyA_MJU-0awnklSQBLos5saAkUYi6yesZbyML0OFQ3ERL_aU-BuWMBiPE9oxG2V1v0uo6ESLAZ1Gh2KeRgDG0KiRtENzout5nz3gOprksgDGpKMIPyC5NDEotBgmOnVMQAw9UfWFALTr1Ovmuxhlp9jhbOz1EsgON8YzwHOar96DteGHX4hPPeCUzeuAERW8tUoT1FJocfEq9LtHH_oK-OLR2gLO2CMvng9AWGv4I9PLVHQp25pjyqtR6F4pOFgQ&client-request-id=b1f99230-f13d-0000-30a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode:
State Machine State: Idle
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 18: Event ID Information In the Web Application Proxy Event Log

Web Application Proxy successfully retrieved a Kerberos ticket on behalf of the user.

Details:
Transaction ID: {b1f99230-f13d-0000-40a6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-30a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTczMjYsImV4cCI6MTQxNDM2MDkyNiwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0zMGE2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMjE6MDI6NTUuODA5WiIsInZlciI6IjEuMCJ9.GTOChpYcBD8zMgHvMPfrbNEEmYPDHi4iBVd513NJXYgPMTHZJMnD7n7ndAgN8sTPY330VLICHS2ccSXgRzGcayNyA_MJU-0awnklSQBLos5saAkUYi6yesZbyML0OFQ3ERL_aU-BuWMBiPE9oxG2V1v0uo6ESLAZ1Gh2KeRgDG0KiRtENzout5nz3gOprksgDGpKMIPyC5NDEotBgmOnVMQAw9UfWFALTr1Ovmuxhlp9jhbOz1EsgON8YzwHOar96DteGHX4hPPeCUzeuAERW8tUoT1FJocfEq9LtHH_oK-OLR2gLO2CMvng9AWGv4I9PLVHQp25pjyqtR6F4pOFgQ&client-request-id=b1f99230-f13d-0000-30a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: BackendRequestProcessing_Pending
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

That’s all folks!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

 

5 Responses to “(2014-12-07) Web Application Proxy With Kerberos Constrained Delegation (KCD)”

  1. RK said

    Very detailed information. This helped us a lot in Troubleshooting. But why is the ADFS Logon Page presented for an application with Integrated Windows Authentication? The procedure looks like with any other unix or windows application that uses Kerberos.

    • Jorge said

      because the Web Application Proxy does not support Windows Integrated Authentication (WIA) and with that in mind it defaults back to Forms Based logon

  2. Rob said

    The whole purpose of having a reverse-proxy in form of the WAP is to minimise the exposure to the Internet.
    WAP is therefore situated in the DMZ with only HTTPS traffic allowed both from the Internet and to the ADFS server on the internal network.

    What I don’t understand is how this “resolution” to join the WAP server located in DMZ to the domain is suggested by Microsoft.

    Please consider revising the “resolution” and advise the use of NTLM authentication for SharePoint exclusively – Kerberos is not the way forward in this instance!

  3. […] Web Application Proxy with Kerberos Constrained Delegation (KCD) […]

  4. Wolfgang said

    Why does the WAP still need Kerberos, if the user is already ADFS-authenticated? Is that not a valid token to authenticate to (say) Exchange inside?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: