locked
ADFS 4.0 and WAP on server 2016: WAP not communicating : cipher suite or protocol issue? RRS feed

  • Question

  • Problem on server 2016 ADFS and Server 2016 WAP:

    I am seeing event 224, AD FS on my WAP server every minute and getting "Service not available" when accessing https://fs.mydomain.com/adfs/ls/idpinitiatedsignon.aspx from outside the domain (via WAP)

    Internally ADFS is working fine.

    Event 224 on the WAP server every minutes refers to a certificate which does not exist on the ADFS server-

    The federation server proxy configuration could not be updated with the latest configuration on the federation service.

    Additional Data

    Error: 

    Retrieval of proxy configuration data from the Federation Server using trust certificate with thumbprint '17F70D67515E1E50F8ACEAC31DE6AC9ABEDA838B' failed with status code 'InternalServerError'.

    The WebApplicationProxyCertificate is set to use another (public) certificate, this is the one I want to use, screen shot from WAP:

    And this certificate (the 96FD... one) is installed on the ADFS server as the service communications certificate.

    Cert I want to use on ADFS

    The certificate mentioned in the error exists ONLY in the WAP server with a short lifetime. It does not exist on the ADFS server.

    Certificate in error message, does not exist on ADFS server


    CarolChi


    Monday, July 10, 2017 4:02 PM

Answers

  • Hi,

    Have a look at this one: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs 

    This solved the problem for me on Server 2016, after tighten insecure ciphers and old SSL/TLS versions on WAP server (and ADFS) by using IISCrypto from Nartac Software(https://www.nartac.com/Products/IISCrypto). WAP and ADFS is built using .NET and default to TLS 1.0. I was using the "SchUseStrongCrypto"=dword:00000001 method in above link to enable Strong Authentication for .NET applications:

    "For the .NET Framework 4.0/4.5.x use the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 "SchUseStrongCrypto"=dword:00000001"

    /Rune.

    • Proposed as answer by 1U Techops Friday, May 18, 2018 10:56 AM
    • Marked as answer by Carol Chisholm Friday, May 18, 2018 11:30 AM
    Friday, March 16, 2018 3:18 PM
  • Thanks for the help. I have found the solution. 

    I had been hardening the servers to PCI 3.1 and this is what caused the problems. 

    So the link between WAP and ADFS must use an insecure cipher or old TLS version. Recently I have disabled 3DES.

    Can anyone help with more details? I don't really want to go through one by one all the key exchange, cipher and cipher suites on both the ADFS and WAP servers, with a restart at each time :(


    CarolChi

    Tuesday, July 11, 2017 1:48 PM
  • https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

    My question answered.


    CarolChi

    Friday, May 18, 2018 11:30 AM

All replies

  • The WAP doesn't have a domain-join requirement because it is using TLS authentication (regardless of it is domain-joined or not).The ADFS ProxyTrust - WAP certificate is the one used by the WAP to authenticate against the ADFS farm. It has nothing to do with the other certs you see in the database. Actually, you don't see it anywhere in the GUI. You can still see it from the ADFS server with the following PowerShell cmdLets:

    dir Cert:\LocalMachine\AdfsTrustedDevices | Where-Object { $_.Subject -like "CN=ADFS ProxyTrust*" }

    But anyways, if your WAP doesnt' work at all, maybe you have a configuration issue. Do you use a load balancer in front of the ADFS servers? If so are you sure you are not doing any sort of SSL inspection between WAP and ADFS? This breaks the TLS authentication.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, July 10, 2017 5:37 PM
  • WAP is domain joined (it always has been).

    No load balancer.

    No SSL inspection. 

    WAP and ADFS in the same subnet

    What version of TLS is it using? Maybe a cipher issue?


    CarolChi

    Monday, July 10, 2017 6:01 PM
  • Thanks for the help. I have found the solution. 

    I had been hardening the servers to PCI 3.1 and this is what caused the problems. 

    So the link between WAP and ADFS must use an insecure cipher or old TLS version. Recently I have disabled 3DES.

    Can anyone help with more details? I don't really want to go through one by one all the key exchange, cipher and cipher suites on both the ADFS and WAP servers, with a restart at each time :(


    CarolChi

    Tuesday, July 11, 2017 1:48 PM
  • Hi,

    I've just changed only 1 thing in my new ADFS4 setup: disable of TLS 1.0 on the ADFS server itself. This gives this issue with 'InternalServerError' on the ADFSProxy. Re-enabling TLS 1.0 (delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\Enabled) on the ADFS + restart fixed it. You can safely disable TLS 1.0 on the WAP, just not on the ADFS server itself....go figure!

    Thursday, March 8, 2018 3:45 PM
  • Hi,

    Have a look at this one: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs 

    This solved the problem for me on Server 2016, after tighten insecure ciphers and old SSL/TLS versions on WAP server (and ADFS) by using IISCrypto from Nartac Software(https://www.nartac.com/Products/IISCrypto). WAP and ADFS is built using .NET and default to TLS 1.0. I was using the "SchUseStrongCrypto"=dword:00000001 method in above link to enable Strong Authentication for .NET applications:

    "For the .NET Framework 4.0/4.5.x use the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 "SchUseStrongCrypto"=dword:00000001"

    /Rune.

    • Proposed as answer by 1U Techops Friday, May 18, 2018 10:56 AM
    • Marked as answer by Carol Chisholm Friday, May 18, 2018 11:30 AM
    Friday, March 16, 2018 3:18 PM
  • https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

    My question answered.


    CarolChi

    Friday, May 18, 2018 11:30 AM
  • So for me the problem was that after I joined the WAP servers to the ADFS farm it tries to use the federation service name to communicate with the ADFS farm.  It apparently does not try to talk to the farm primary using an IP address or FQDN.  So when I take the federation service name and point it to the WAP servers they are trying to get their configuration updates from themselves rather than the primary ADFS farm server.  If I go into the hosts file on the WAP servers and put in the IP address of the primary ADFS farm server the errors go away (in a matter of minutes).  It would be nice if the setup allowed for the WAP servers to have a configuration server set on them that is different than the federation service name.  Modifying the hosts file is a terrible work-around.
    Monday, December 16, 2019 11:44 PM