2

I'm working on setting up a lab environment with two Windows Server (virtual) machines that cooperate in an AD FS configuration.

High level architecture overview

  • WIN-TORHJGJ7N: Windows Server 2012, running AD FS 2.0. Also the domain controller.
  • ADFSSERVERPROXY: Despite its name, not really set up as a proxy (yet). Most importantly, it contains a web application running on https://adfstest.sub.domain.com/. It is protected with AD FS Windows Token-Based Agent, as shown on the below image. The web application is a simple "hello world" program, so no authentication logic on that side whatsoever.

enter image description here

On my first machine, I want to configure my Relying Party Trust, but I'm having trouble configuring my endpoints. I tried http://sts1.sub.domain.com/adfs/ls/, http://adfstest.sub.domain.com/ and other variations, but really I'm just not sure what is intended to go there. Is it an arbitrary value, or does it need to point to a specific location? If it should point to my web application, do I need to implement authentication logic at the application?

Relying Party Trust Endpoint

So, cutting a long story short: what is expected to be the relying party trust endpoints in this setup?

EDIT:
One of the errors I get when I point the endpoint to an arbitrary url on the application side (https://adfstest.sub.domain.com/), is the following:

The AD FS Web Agent for Windows NT token-based applications encountered a serious error. The cookies that were presented by the client could not be validated.

This condition occurs when a client presents well-formed cookies that are not valid. If the client is known to be a valid user, this error might be caused by a transient issue. For instance, trust properties (for example, certificates) may have changed recently or revocation status may not be available from the certification authority.

User Action Look for additional events in the security log that may contain more details. Consider enabling failure auditing on this Web server if auditing is not already enabled.

Community
  • 1
Honoki
  • 121
  • 1
  • 4

1 Answers1

1

Is this lab just for your learning or for some proof of concept intended to be used in production later?

The token based agent approach you are trying to implement is the old school method introduced in 2003 R2. Are you sure you need to do it this way for production?

The current way of federating apps is to use WIF. See http://msdn.microsoft.com/en-us/library/hh987037(v=vs.110).aspx for a sample using the latest WIF version.

In that sample replacing the references to

  • http://localhost:13922/wsFederationSTS/Issue with http://sts1.sub.domain.com/adfs/ls/ and
  • http://localhost:28503/ with http://adfstest.sub.domain.com/ and
  • 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 with your AD FS token signing cert hash as visible when running get-adfscertificate cmdlet on AD FS

Also see http://www.cloudidentity.com/blog/2014/02/12/use-the-on-premises-organizational-authentication-option-adfs-with-asp-net-in-visual-studio-2013/ for and to end example of using WIF and AD FS. That article shows AD FS on Windows Server 2012 R2 in use but is perfectly applicable here.

maweeras
  • 2,674
  • 2
  • 16
  • 23
  • So that means I do need some authentication logic at the application side? I was hoping AD FS provided a way to add this form of authentication to any web application, without needing too much configuration at that side. I read that WIF only supports Ws-fed, and not SAML as token protocol. What would I need if I want to use SAML between the IdP and the SP? Thanks for your reply. – Honoki Oct 06 '14 at 07:27