2012R2 AD FS WAP proxy problem RRS feed

  • Question

  • I am trying to setup a test ADFS server environment with the goal of using federated Office 365.
    My test environment has 
    two domain controllers at 2008R2 functional level, 1 server 2008R2 and the other 2012 with one local (non-
    routable) internal domain name and one externally routable name for mail. I have added the externally routable 
    name as an alternate UPN suffix.
    two exchange servers, 1 2010 and the other 2013.
    one 2012R2 ADFS server and one 2012R2 WAP proxy server.
    The 2 AD FS servers seem to work alright. I can login (adfsmachinename/adfs/ls/idpinitiatedsignon) and also pull 
    the https://mycomp/adfs/fs/federationserverservice.asmx from any of the machines in the domain. All servers are 
    joined to the domain and in the same subnet.

    The problem is setting up the Web application Proxies to establish the trust. when I use the Web Application Proxy 
    Configuration Wizard I put in the wildcard cert that is from comodo for the routable domain name and is on both 
    the ADFS and WAP servers. I use either a domain admin or local admin of the ADFS server but it always fails with 
    the same message:

    "Unable to retrieve proxy configuration data from the Federation Server."

    On the AD FS WAP server the event logs event 422:
    Trust Certificate Thumbprint: 
    Status Code: 
    Exception details: 
    System.Net.WebException: The remote server returned an error: (401) Unauthorized.
       at System.Net.HttpWebRequest.GetResponse()
       at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()

    note: the process creates a new cert ADFS ProxyTrust-localservername which has the thumbprint in the error listed.

    at the same time the event log on the ADFS server it is trying to trust with comes up with event id 276:
    The federation server proxy was not able to authenticate to the Federation Service. 

    User Action 
    Ensure that the proxy is trusted by the Federation Service. To do this, log on to the proxy computer with the host 
    name that is identified in the certificate subject name and re-establish trust between the proxy and the 
    Federation Service using the Install-WebApplicationProxy cmdlet. 
    Additional Data 
    Certificate details: 
    Subject Name: 
    NotBefore Time: 
    NotAfter Time: 

    No matter what I seem to try with local admin account it has the same error. verified the passwords, try domain 
    admin, local admin, ADFS domain service admin etc.

    Wednesday, February 19, 2014 8:16 PM

All replies

  • Hi,

    For the ADFS issue, i would suggest you may ask in:



    Vivian Wang

    Thursday, February 20, 2014 8:49 AM
  • Did you ever get to the bottom of this? I have the same issue.
    Friday, February 28, 2014 4:55 PM
  • +1 to this same issue.  Has anyone had any luck with this?

    Consultant | Nerd | Visionary. http://www.ethertech.com.au/ | http://www.deeperstates.com.au

    Monday, March 31, 2014 11:54 AM
  • Have you checked your certificates on both servers (adfs & WAP) that certificate path is ok?

    You have in your WAP server hostfile:
    adfspublicname.domain.com which is pointed to your private adfs server ip?
    443 port should be also allowed between servers.

    in proxy wizard you should use account which have local admin rights on your adfs server

    Friday, April 4, 2014 4:32 PM
  • I just noticed this problem on 2 out of 4 WAP servers we just built in our QA domain four weeks ago. We have several Microsoft consultants in to help implement a large and complex setup and will be asking them to take a look shortly, as I have the same errors you are seeing. I will follow up with an answer as soon as we have one :)
    • Proposed as answer by Rumiku Friday, April 4, 2014 9:59 PM
    • Unproposed as answer by Rumiku Friday, April 4, 2014 10:00 PM
    Friday, April 4, 2014 5:55 PM
  • Re-reading over your error, your issue isn't 100% exactly what mine was (just figured it out and will list it below so that it is searchable). However, here are some things that might help:

    The ADFS server must have an SSL certificate that is issued with the same name as the ADFS service name (for example, if you called the ADFS service name sts.contoso.com, the ssl cert needs to be installed on the local computer store issued with the same name as sts.contoso.com. A local server name SSL is fine too, as long as the ADFS service name you used during setup is the same).

    On the WAP server, import the same cert you used for the ADFS service (In this example, sts.contoso.com) into the local computer personal store AND the local logged on user personal store (this is due because the active session logon will look to the personal local user store, only during initial setup)

    Back on the ADFS server, ensure the service account you used to install the ADFS service has full rights over the ADFS service name ssl cert. You have do this by going into CERTLM.msc (shortcut to local computer store), then navigating to Personal>Certificate and right click on the ssl cert you are using for the ADFS service name (such as sts.contoso.com), selecting All tasks>Manage Private Keys, then adding the domain service account and ensure it has full control.

    Run through the WAP install process. Ensure you use the same name for the federation service (sts.contoso.com), and when it asks for local administrative credentials, use a Domain Admin account (such as yourself) or a service account with domain admin rights (if your WAP server is not attached to the domain, use a domain admin account, as this is only used for setting up the initial trust). Be sure to select the same cert as used on the ADFS servers (this is very important as WAP needs this cert to act on behalf of the ADFS servers).

    You should now have a successful trust and WAP/ADFS setup.

    A few things to note:
    You should ensure first that you can access your ADFS metadata file correctly from the WAP server. On the WAP server(s), navigate to the metadata XML file, usually at https sts.consto.com/federationmetadata/2007-06/federationmetadata.xml. If you cannot access this page while on the WAP server, your install will fail.

    In my case, should your WAP server begin to fail authenticating to your ADFS server AFTER it has been configured and working, you can try the following which helped me:
    On the WAP server, to into the registry and set the following from "2" to "1"
    HKLM\Software\Microsoft\ADFS "proxyConfigurationStatus". Once you set this back to "1", run "ramgmtui.exe" and click on "Web Application Proxy" in the upper right hand window. This will allow you to re-run the WAP configuration and renew the token and trust certs that are generated during the configuration process of WAP.

    • Proposed as answer by Rumiku Friday, April 4, 2014 10:01 PM
    Friday, April 4, 2014 10:01 PM
  • Same problem. My details are ADFS installed on two DCs (2012 R2), not currently load balanced but DNS points to first server in farm.  Cert from public CA has fs.mydomain.com as subject and subject alternative name.  ADFS has fs.mydomain.com for service name.  IIS on ADFS and WAP servers has this cert bound to Default Web Site, also using fs.mydomain.com as host name for binding to port 443. My ADFS server IP is listed in hosts file on WAP server.  All machines can access private key.  gMSA has Full Control access to cert.  port 443 is open through firewall.  Domain Admin credentials are supplied for WAP setup (and same cert and service name previously mentioned).

    I can get to login page and metadata file from all machines including WAP server.

    When I run WAP setup I get the same errors as above.  Why does it say <null> under all certificate details?  Seems like ADFS couldn't possibly trust a blank cert, but none of those fields should be <null>, what gives?


    Thursday, October 8, 2015 9:28 PM
  • Turns out certificate binding precedence is the culprit.  While IIS is not required for 2012 R2 ADFS roles anymore, it can actually get in the way if it is on the same machine.  Binding cert to default web site in IIS will place an ip:port entry into sslcert bindings, which has a higher precedence than service:port entries that ADFS sets up.  Since the IIS entry has no Ctl Store Name, the WAP certificate is placed in a store that is filtered out when ADFS checks for its presence. 

    Type "netsh http show sslcert" in a terminal on your ADFS machines and look for entries higher on the list than your ADFS service name entries.  If those don't have Ctl Store Name of AdfsTrustedDevices and they can resolve to your ADFS service, the install will fail. 

    My problem is solved and I'd bet IIS, or another app with a cert binding on the same machines, had something to do with the problem listed at the top of this page. I'd also say the other suggested answer is flawed since it's a workaround that requires you to re-run the setup whenever it breaks.

    • Proposed as answer by plekkenpol Monday, October 12, 2015 2:13 PM
    Monday, October 12, 2015 2:13 PM