Jorge's Quest For Knowledge!

All 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!

Archive for the ‘Web Application Proxy’ Category

(2017-03-01) Hardening – Disabling Weak Ciphers, Hashes And Protocols On ADFS, WAP, AAD Connect, Azure AD MFA Server And Azure AD Application Proxy

Posted by Jorge on 2017-03-01


UPDATE 2017-05-08: Also disabled the cipher “Triple DES” and explained how to use a GPO

This post is about disabling weak ciphers, hashes, cipher suites and protocols in ADFS, WAP, AAD Connect, Azure AD MFA server and Azure AD Application Proxy Connector server. The main focus however, is disabling weak protocols in ADFS, WAP, AAD Connect, Azure AD MFA Server and Azure AD Application Proxy Connector server as these systems play a very important part in the hybrid solution with Azure AD and its backend services.

Please be very careful with these settings when hardening your systems and make sure to test first!!!

For quite some time now, SSL v2.0, SSL v3.0 and TLS v1.0 should be disabled and not be used anymore. Especially with disabling TLS v1.0 you may/will experience some challenges that need to taken care of. It may seem difficult to disable TLS v1.0, but it is not impossible. Just do your research!

For this blog post and the tests that I performed in my test/demo environment I used the following information:

As a starting point for this blog post I do assume that every client/server is up to date with the patches available through Windows update!

As soon as you disable TLS v1.0 on W2K8R2 and higher, the RDP client on Windows 7 and Windows Server 2008 R2 breaks. For Windows 7 and Windows Server 2008 R2 the hotfix Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2 exists to add support for TLS v1.1 and TLS v1.2 for RDP client on Windows 7 and Windows Server 2008 R2. The RDP client on Windows 8/8.1 and Windows Server 2012 (R2) and higher is not impacted.

SQL Server

Looking at both ADFS and AAD Connect, both can use SQL server for their data storage.

If ADFS is using WID, from my experience, you do not need to do anything in addition.

If you have installed AAD Connect without SQL server, then you are using SQL Server 2012 Express LocalDB (a light version of SQL Server Express). I do not fully understand why, but in my case the Azure AD Sync service did not start anymore. Exporting the custom sync rules, uninstalling AAD Connect, rebooting the server, reinstalling AAD Connect and importing the custom Sync rules and everything was fine again. Don’t ask why or how. Maybe a coincidence!

However, if either ADFS or AAD Connect is using SQL server, make sure to patch SQL server so that it supports TLS v1.2. More information about this can be found in TLS 1.2 support for Microsoft SQL Server.

If SQL Server is running on W2K8R2, then TLS v1.1 and TLS v1.2 are supported, but it is disabled by default. You will have to enable it through the following commands and reboot the server afterwards.

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

If SQL Server is running on W2K12 or higher, then TLS v1.1 and TLS v1.2 are supported and enabled by default.

Azure AD Connect

AAD Connect supports W2K8 and higher as the server OS. However:

  • W2K8 does not support TLS v1.1 or TLS v1.2. You will have move away to a more recent server OS version.
  • W2K8R2 does support TLS v1.1 or TLS v1.2, but it is disabled by default. You will have to enable it through the “REG ADD” commands or using the IISCRYPTO tool and reboot the server afterwards.
  • W2K12 does support TLS v1.1 or TLS v1.2 and it is enabled by default. Explicitly enabling it does not change or hurt anything.

When connecting to Azure AD, TLS v1.0 is used by default. This can be changed to start using TLS v1.2 instead. Azure AD by default supports this.

The Azure AD Connect server depends on .NET Framework 4.5.1 or later. Whichever version you have installed, you need to install a patch for it, unless you are already running it on W2K16 or higher. If you are running W2K8R2, W2K12 or W2K12R2 you need to install a patch. Which patch you need can be found in Microsoft Security Advisory 2960358.

In addition, configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. After installing the required patch (W2K12R2 and lower only) you need to tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Azure AD MFA Server

AAD MFA Server supports W2K3 and higher as the server OS. However:

  • W2K3 and W2K8 do not support TLS v1.1 or TLS v1.2. You will have move away to a more recent server OS version.
  • W2K8R2 does support TLS v1.1 or TLS v1.2, but it is disabled by default. You will have to enable it through the “REG ADD” commands or using the IISCRYPTO tool and reboot the server afterwards.
  • W2K12 does support TLS v1.1 or TLS v1.2 and it is enabled by default. Explicitly enabling it does not change or hurt anything.

When connecting to Azure AD, TLS v1.0 is used by default. This can be changed to start using TLS v1.2 instead. Azure AD by default supports this.

The Azure AD MFA server depends on .NET Framework 4 or later. Whichever version you have installed, you need to install a patch for it, unless you are already running it on W2K16 or higher. If you are running W2K8R2, W2K12 or W2K12R2 you need to install a patch. Which patch you need can be found in Microsoft Security Advisory 2960358.

In addition, configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. After installing the required patch (W2K12R2 and lower only) you need to tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Azure AD Application Proxy Connector Server (AADAppPrx)

AADAppPrx Server supports W2K12R2 and higher as the server OS. However:

  • W2K12 does support TLS v1.1 or TLS v1.2 and it is enabled by default. Explicitly enabling it does not change or hurt anything.

When connecting to Azure AD, TLS v1.0 is used by default. This can be changed to start using TLS v1.2 instead. Azure AD by default supports this.

The AADAppPrx server depends on .NET Framework 4 or later. Whichever version you have installed, you need to install a patch for it, unless you are already running it on W2K16 or higher. If you are running W2K12R2 you need to install a patch. Which patch you need can be found in Microsoft Security Advisory 2960358.

In addition, configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols (not really needed for W2K12R2/W2K16 as these are already enabled by default in the OS)

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. After installing the required patch (W2K12R2 and lower only) you need to tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

ADFS In General

From a federation perspective, if a target ADFS server does not support the weaker protocols when updating the metadata from the target ADFS server, you will most likely see an error equal or at least similar to the one below. Now please be aware that testing the protocols by reading the target metadata in a browser compared to reading the target metadata in the ADFS management console use a different configuration. If the browser, as a client, does support the stronger protocols you will/may not see an error. However, doing the same in the ADFS management console might return the following error

image

Figure 1: Connection Being Closed By Remote ADFS Server Because Local ADFS Server Does Not Support/Use Stronger Protocols

In this setup I will have a secured ADFS server (ADFS v3.0 or ADFS v4.0) which will be configured to only support stronger protocols and no weak protocols. I will have other remote ADFS servers, clients, applications, etc. with which the secured ADFS server needs to communicate with in any form (e.g. read metadata through URL from remote ADFS servers and/or applications). The other way around the remote ADFS servers, WAP Server, clients, applications, etc. need to communicate with the secured ADFS server to read its metadata/configuration or deliver or get a security token. In the case the secured ADFS server needs to communicate with SQL server, than if above in the section “SQL Server”. The idea here is also to configure remote servers/clients to be able to use TLS v1.1 and TLS v1.2 against the secured ADFS/WAP servers, but NOT to disable TLS v1.0 on them. This is about what you need to do at least on other systems if you secure one specific ADFS/WAP farm.

Secured ADFS/WAP To Only Support Stronger Protocols And Disable Weaker Protocols

ADFS/WAP v3.0 is based on W2K12R2, ADFS/WAP v4.0 is based on W2K16. W2K12R2 and W2K16 both already supports TLS v1.1 and TLS v1.2 and it is also already enabled. Again, explicitly enabling it does not change or hurt anything. See commands below to disable/enable stuff

.NET is hardcoded to use TLS v1.0 by default. For W2K12R2 and W2K16 you need to tell .NET to use the stronger protocols. That is done by executing the commands below to set the required registry settings. However, for W2K12R2 you must install some patches first to be able to tell .NET to use the stronger protocols in use by the OS. For that see Microsoft Security Advisory 2960358 (probably MS-KB2898847 and MS-KB2898850). For W2K16 you do not need to install the patches. You only need to configure the registry settings .

Configure the server to disable/enable (whichever is applicable) the following ciphers, hashes and protocols:

Disabling Weak Ciphers/Hashes/Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Enabling Strong Protocols (not really needed for W2K12R2/W2K16 as these are already enabled by default in the OS)

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

.NET is hardcoded to use TLS v1.0 by default. To tell .NET to use the stronger protocols. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

Looking at all this from the the IISCRYPTO tool it will look like

image

Figure 2: Settings Viewed/Configured From The IISCRYPTO Tool

You might also think in disabling weak(er) cipher suites on both ADFS/WAP. For that you can configure a GPO to target the specific servers, or use the local GPO to do so. Nevertheless, you can configure this as follows:

image

Figure 3: Setting To Disable Weaker Cipher Suites

Enable that setting and specify the following Cipher Suites that are allowed (for readability I put everything on multiple lines, but it must be a comma-separated list in a single line):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA

After configuring all this, DO NOT forget to reboot the ADFS/WAP servers!

If you have configured this on all your WAP server and you have those scanned through SSL Labs (URL:  https://www.ssllabs.com/ssltest/analyze.html) you will see a rating similar to

image

Figure 4: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 1)

image

Figure 5: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 2)

image

image

image

Figure 6: Qualys SSL Labs Report For WAP Configured With Settings Listed Above (Part 3)

Browsers Communicating With Secured ADFS

Internet Explorer must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Internet Explorer –> Internet Options –> Advanced TAB –> Scroll down to the end

image

Figure 7: Internet Explorer Settings For TLS Support

Firefox must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Firefox –> As URL enter “about:config” –> Accept warning –> In the search box enter “security.tls.version.max” –> This tells you the highest TLS version supported

1 means TLS 1.0; 2 means TLS 1.1; 3 means TLS 1.2; 4 means TLS 1.3;

image

Figure 8: Firefox Settings For TLS Support

Chrome must be configured to support TLS v1.1 and TLS v1.2 if not already enabled by default.

Open Chrome –> As URL enter “chrome://settings”" –> Click on Settings on the left –> Scroll down to Network –> Click on Change Proxy Settings –> Advanced TAB –> Scroll down to the end

Yes, you guessed it correctly. Chrome inherits these settings from IE!

Remote ADFS On W2K8R2 (ADFS v2.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v2.0 on W2K8R2” and “ADFS v2.0 on W2K8R2 reading metadata from Secured ADFS”

W2K8R2 by default supports TLS v1.1 and TLS v1.2, but it is disabled by default. Therefore you need to enable it. You can use the following commands to do so.

Enabling Strong Protocols

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

Looking at all this from the the IISCRYPTO tool it will look like

image

Figure 9: Settings Viewed/Configured From The IISCRYPTO Tool On W2K8R2 With ADFS v2.0

Applies To Direction –> “ADFS v2.0 on W2K8R2 reading metadata from Secured ADFS”

Install the hotfix listed in Support for TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and Server 2008 R2 SP1

Tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v2.0 servers!

Remote ADFS On W2K12 (ADFS v2.1) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v2.1 on W2K12” and “ADFS v2.1 on W2K12 reading metadata from Secured ADFS”

W2K12 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v2.1 on W2K12 reading metadata from Secured ADFS”

I think you do need to install the hotfixes listed in Microsoft Security Advisory 2960358 (probably MS-KB2898845 and MS-KB2898849).

However, you still need to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings.

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v2.1 servers!

Remote ADFS On W2K12R2 (ADFS v3.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v3.0 on W2K12R2” and “ADFS v3.0 on W2K12R2 reading metadata from Secured ADFS”

W2K12R2 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v3.0 on W2K12R2 reading metadata from Secured ADFS”

In this case I would expect to have to install the hotfixes listed in Microsoft Security Advisory 2960358 (probably MS-KB2898847 and MS-KB2898850). However, funny enough it was not needed

However, I still needed to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings.

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v3.0 servers!

Remote ADFS On W2K16 (ADFS v4.0) To Be Able To Communicate With Secured ADFS

Applies To Directions –> “Secured ADFS reading metadata from ADFS v4.0 on W2K16” and “ADFS v4.0 on W2K16 reading metadata from Secured ADFS”

W2K16 by default supports TLS v1.1 and TLS v1.2 and it is also enabled by default. Nothing to do for that.

Applies To Direction –> “ADFS v4.0 on W2K16 reading metadata from Secured ADFS”

No need to install patches for this.

However, I still needed to tell .NET to use the stronger protocols in use by the OS. That is done by executing the following commands to set the required registry settings

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f

After configuring all this, DO NOT forget to reboot the ADFS v4.0 servers!

Remote Applications/Federation Systems (On-premises Or Cloud) To Be Able To Communicate With Secured ADFS

Applies To Direction –> “Secured ADFS reading metadata from remote Application/Federation System”

Just make sure the connected application/federation system supports TLS v1.1 and TLS v1.2 as a server. You may need to contact system owners and/or vendors and ask if their system supports TLS v1.1 and/or TLS v1.2. You can also setup a separate secured ADFS server and try to read its metadata from the application/federation system. If it succeeds it most likely does support TLS v1.1 and/or TLS v1.2.

Or….

Use the PowerShell script from Vadims Podans to check if the target server supports TLS v1.1/1.2 as a server: Test web server SSL/TLS protocol support with PowerShell

Applies To Direction –> “Remote Application/Federation System reading metadata from Secured ADFS”

Just make sure the connected application/federation system supports TLS v1.1 and TLS v1.2 as a client. You may need to contact system owners and/or vendors and ask if their system supports TLS v1.1 and/or TLS v1.2. By performing the previous test, you may be able to assume (not sure of course) that it will also support TLS v1.1 and TLS v1.2 as a client if it supports TLS v1.1 and TLS v1.2 as a server

Additional Findings:

  • At the time of writing, it looks like Azure AD Connect Health DOES NOT support TLSv1.1/v1.2 only. It appears to need TLSv1.0 <== NOT TRUE!
  • Many agents or on-premises solutions that interact with Azure AD somehow may use client certificates to authenticate against Azure AD. That may start to fail after configuring these settings (specially after disabling TLS v1.0 and only allowing TLS v1.1 and TLS v1.2) and if you are running either W2K8R2 or W2K12 or W2K12R2 for Azure AD Connect Health Agent for ADDS/ADFS/Sync or the Azure AD Application Proxy Connector server. By default those client certificates use the SHA512 signature algorithm which is disabled by default, unless you have installed a patch to enable it. More info about this through SHA512 is disabled in Windows when you use TLS 1.2

REMARKS:

  • All the registry settings listed in this blog post can also be configured in a GPO by using preferences. On one of the servers you want to harden, configure the required registry settings by running the commands, then after opening the GPO in the preference section, run the registry wizard, target the server already configured and select the configured settings to be included in the GPO

image

Figure 10: Registry Settings Through Preferences In A GPO

Troubleshooting

If you find a error like the following one in the System Event Log:

"A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 70. The Windows SChannel error state is 105."

Check the underlined error code, a.k.a. the fatal error code, and look it up in SSL/TLS Alert Protocol & the Alert Codes. In this case “fatal error code 70 ” means: “The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal.”

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD Application Proxy Connector, Azure AD Connect, Hardening, Web Application Proxy | 5 Comments »

(2017-02-17) Accessing Published Application Through Web Application Proxy With ADFS Pre-Authentication Fails

Posted by Jorge on 2017-02-17


You are using ADFS v3.0, or higher, in combination with the Web Application Proxy (WAP) to publish internal applications to the outside. Some of those applications are published with “pre-authentication” and some of those applications are published with “pass-through”.

On a device that is on the outside of your network, in a browser you enter the URL of an application that is published through the WAP with ADFS pre-authentication. The issue I’m about to explain DOES NOT occur with applications published through the WAP with pass-through.

Most likely you will hit a similar screen as the one below that is asking for Forms Based Authentication (FBA).

image

Figure 1: The ADFS Forms Based Authentication Screen

After entering the credentials you are redirected back to the application, and you end up stuck in an empty screen. When you look up at the URL, you may see something like “authToken=”.

image

Figure 2: After Being Redirected To The Application An Empty Screen

When looking in the Web Application Proxy Event Log you may find a similar event as the one below, telling you the Edge Token signing is not correct.

image

Figure 3: Event About An Invalid Edge Token

Web Application Proxy received a nonvalid edge token signature.
Error: Edge Token signature mismatch. edgeTokenHelper.ValidateTokenSignature failed: Verifying token with signature public key failed

Received token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw

Details:
Transaction ID: {3419c608-8894-0000-40c7-19349488d201}
Session ID: {3419c608-8894-0000-3fc7-19349488d201}
Published Application Name: Show My Claims (ASP.NET) (Basic)
Published Application ID: 53B426A6-162E-C09B-4D8F-62AAB4E79989
Published Application External URL:
https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
Published Backend URL: https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
User: <Unknown>
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Device ID: <Not Applicable>
Token State: Invalid
Cookie State: NotFound
Client Request URL:
https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw&client-request-id=3419c608-8894-0000-3fc7-19349488d201
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>

When you look up the error in the first line you might find one of the following URLs:

In the beginning, you had to configure the WAP with the primary Token Signing certificate in use by ADFS, with the command:

Set-WebApplicationProxyConfiguration -ADFSTokenSigningCertificatePublicKey MIIFvTCCA6WgAwIBAgITPQAAAL…..

After the update http://support.microsoft.com/kb/2935608, you will the “ADFSTokenSigningCertificatePublicKey” property is marked as obsolete. That means you do not have to manually populate the public key of the ADFS Token Signing certificate, but rather WAP will leverage the ADFS metadata to discover the Token Signing certificates in use by ADFS.

Within ADFS you can define multiple Token Signing certificates and one of those certificates is marked as PRIMARY and all others are marked as SECONDARY. As you can see below you can see that my test/demo environment has 3 Token Signing certificates.

image

Figure 4: List Of Token Signing Certificates In The ADFS Console

When you look into the ADFS metadata (URL: /federationmetadata/2007-06/federationmetadata.xml">https://<FQDN ADFS Service>/federationmetadata/2007-06/federationmetadata.xml), you will find all the Token Signing certificates listed in the “IdPSSODescriptor” section (for the role of IdP) and in the “SPSSODescriptor” section (for the role of SP), which have been marked as “use=”signing””. As you can expect and compare it to figure 4 above, you will see (in my case!) 3 “KeyDescriptor”s, one for each Token Signing certificate in use by ADFS. ADFS will always publish all Token Signing certificates in the metadata. no matter if they’re primary or secondary. In addition, ADFS will always publish only the primary Token Encryption certificate in the metadata.

image

Figure 5: List Of Token Signing Certificates In The ADFS Metadata

Using this website you can check the certificates in the metadata and get some output you can understand. You copy the value between “<X509Certificate>…………..</X509Certificate> “ and enter that in the certificate text window.

After doing that 3 times I got (in my case!):

image

Figure 6: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

image

Figure 7: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

image

Figure 8: One Of The Token Signing Certificates In Use By ADFS (Marked As Primary As Shown In Figure 4)

As mentioned before, WAP reads the ADFS metadata and picks up the Token Signing certificates in use by ADFS. HOWEVER, it only picks the first 2 occurrences designated as “use=”signing”” as disregards all other occurrences!. Therefore in my case it reads the first and second occurrence (Figure 6 and 7) and ignores the third occurrence (Figure 8). However, when you look in Figure 4 you will see that the certificate listed in Figure 8 is the primary Token Signing certificate that is being actively used by ADFS to sign issued tokens. Because of that WAP can verify the signature of the issued Edge Token and fails with the error as shown in Figure 3.

The Figure below show you that WAP will only read the first 2 occurrences of the Token Signing certificates in the ADFS Metadata

image

Figure 9: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIDXzCCAkegAwIBAgIQVR5qR+aSho5MH9eWFSXqWDANBgkqhkiG9w0BAQsFADAoMSYwJAYDVQQDDB1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVELk5FVzAeFw0xNjA1MjExMTAyNTFaFw0xODA1MDExMTAyNTFaMCgxJjAkBgNVBAMMHVRPS0VOLlNJR05JTkcuU0VMRi5TSUdORUQuTkVXMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyP5e8em3Y+2Yq57gePRoEjCymWjxozVoVlPn9JuZAQ94KLcVpFDAwJBoD1eNM587hX17WFDUqN6ZM6LMUuPiNSzdugieb+k3kQnTagkJV4vHiwo8qcBHX27DEri/pD81J+6DdiKjrqGVut6+llNP+ab0LXdsuEvoq89eGSNRoUTDHr556CFw4Y+VgwMuXwPVnJoLpj8I9Ml4kItGoBxyAA1RnWNzNBy1GKQ1vIBQxX4/aWAGqBzCs81vrpKhy0HfA/kR9eGoW3GvjJyeSXNkXMfI/5N7SAk11EPopqh6tt1XgjvbyJjiwdE1f79E3mX4ceaz2OQ4H17lYW4jtTZe4QIDAQABo4GEMIGBMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAwMQYDVR0RBCowKIImRE5TIE5hbWU9VE9LRU4uU0lHTklORy5TRUxGLlNJR05FRC5ORVcwHQYDVR0OBBYEFODJ6In6M+5pyaZqU1ygso7MRdBoMA0GCSqGSIb3DQEBCwUAA4IBAQCddGlhNBR+HKWM9kN/EIgH6lc5HYaAzx6zdAiez3X6F/sbGzj0dSAeFrhGGMa/8S4U/lwy01z/FyDPydpoyySnVCStTRYwm1VwRKzen+YwwFWpuSZbdv/TpUm3JfPKzA6Rjaja3M+c7R+2SWZ5/lo5sJwUlhA2O+G4MZOi4F7odxa13XviOCQnnbsTM2JX8Dgue8uMe5M037xDlggeP3vNTXXChtbFTXa+S6NJksOkjL7GSC9VmHJQUPqcqyc8QJH5ynsmPtkr3txrq/HrViSEOynC3klyHOniHNitaW1TK3XHfvLK8tuNI2GL8cFmMP9hzAxANFXPA2FeESiMASJT.
Secondary key: MIIDUTCCAjmgAwIBAgIQc4D9JdgHWYxG5BMq0w06kzANBgkqhkiG9w0BAQsFADAkMSIwIAYDVQQDDBlUT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB4XDTE1MDkyMTA5MDc0OVoXDTE3MDgyMjA5MDc0OVowJDEiMCAGA1UEAwwZVE9LRU4uU0lHTklORy5TRUxGLlNJR05FRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/KaQ7oQYUF7KZ7cV/PijzuxcgPurRjsoUhFOtZd0wPQz57z8dTWVa2L0Yecuu/qOXvvI5W6XtuRshhQuRpgMZohqw8/y9cVmHrLPVLsyjmSKQtXD8Xd3je+xnY01uMWW6BSB8udbPWaRKG0wnrdpFVRDVlcJKosuLAxCbwXOJbKDX27GAmYGcZSfrlCk/acTGmd7652CZKxNllPwUiX2L5zxJ0BMiEG+xurngsxqzDryrQvMz/ldzwgBZa4wQvnaoevKRTkfp/NfbY34LZxBUMNK7bwbS8dlIrGGeoGSo9q8M9QeIw5URE2CCa8/+UBZuEuorQMWQ9J5nDCzfwK+8CAwEAAaN/MH0wHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDAtBgNVHREEJjAkgiJETlMgTmFtZT1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB0GA1UdDgQWBBQ61L+viK+SHtuwZ7OjXrARHQlFHzANBgkqhkiG9w0BAQsFAAOCAQEAr+cI1HlQUlZwxlXZchow3kWPc165qOGqu3xp2B3R1nDrMgTSlBPnIQwLCM9+X9xZ1PaQLRmPLDDOV+0CoimzvHJU+1AjdTnU82gNYBCM3ULQk+HTliilTZL3fcJE+QSOH/03TxGyopfw52v4kITGa5KsZpkemvFUnCEkgWk74D2AqDj9j0zwq5zSoJrC9eIWM8ztl3srmiFrhHmEsPSw8hbe20OdTu1xfmI/UgtnVBL2LwJnXuWpv/GgxSC41SS7F5AS2Y42Ojter6Tk5Vu1OnQwKjkJb6JvoHQcVYQaqSb4ufS1aU6kkC8U1qNAgwmv86Mhhqpf66H05UtMtKo/zg==.

Although this is my test/demo environment, what are the lessons learned here?

Please make sure to always follow the following guidelines:

  • Always have 1 Token Signing certificate and 1 Token Encryption certificate that are configured as primary and valid for some time (at least 2 or 3 years or more)!
  • Some time before the Token Signing certificate and/or the Token Encryption certificate are going to expire (e.g. 2 months before expiration) add a new Token Signing certificate and/or Token Encryption certificate (whatever is applicable) and make sure it is marked as secondary.
  • To all connected IdPs and connected SPs communicate you will be changing certificates, and where applicable:
    • Ask to check if they have updated metadata when consuming the metadata URL of your ADFS
    • Mail the metadata XML file containing the current and new certificates or mail the individual certificate files or just mail both
  • To all connected IdPs and connected SPs communicate you will be switching the certificates on a specific date
    • If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports 2 Token Signing certificates, the metadata can be updated right away
    • If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports only 1 Token Signing certificate, the metadata should be updated on the specified date
    • If the connected system allows the import or configuration of individual certificates and it supports at least 2 Token Signing certificates, the import or configuration of individual certificates can occur right away
    • If the connected system allows the import or configuration of individual certificates and it supports only 1 Token Signing certificate, the import or configuration of individual certificates should only occur on the specified date
  • Somewhere between 2 and 4 weeks before the certificate expires switch the certificates from primary to secondary and vice versa by configuring the new Token Signing certificate and/or Token Encryption certificate as primary
  • After the old Token Signing certificate and/or Token Encryption certificate (the one configured as secondary) have expired remove it from ADFS and remove it from the certificate store on every ADFS server

In my case the solution is: remove at least one of the secondary certs. I removed all secondaries! ending with only one as you can see below.

image

Figure 10: List Of Token Signing Certificates In The ADFS Console

On all WAP servers restart the “Web Application Proxy Service” service. You will then see the following event telling you that WAP has fetched the Token Signing certificates from ADFS

image

Figure 11: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIFvTCCA6WgAwIBAgITPQAAALW+MGZzrC/smgAAAAAAtTANBgkqhkiG9w0BAQsFADBKMRMwEQYKCZImiZPyLGQBGRYDTkVUMRYwFAYKCZImiZPyLGQBGRYGSUFNVEVDMRswGQYDVQQDExJQS0ktUk9PVC1DQS1JQU1URUMwHhcNMTcwMTExMjI0MjM3WhcNMTkwMTExMjI0MjM3WjAlMSMwIQYDVQQDExpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvFCaJ9uV+4PWn9x/SN9cDv1uw5iv/PAyM+0KaN9O+Z+bpC8Zg2BKG+niEnhgOL44Ju/HFq8B05ri+FTRuaF++MsbULgNspIAT/YR57O01qdHmp+/U99aAKFQGkLQzYY5H/oSvsf6KkcX/48+GdeYHJIdqaHVHoebDr/jRuFdeF+QNOhPJSa/LdFD0FkZp3E4/UbgJLNkAyI3JMfj/d0ylO/H//+/UGazfeGfCMQ25KilIjVVDypo80I9YMLuqc4SnUVLpbz907P62tL+A6bU4nsSim84zxzZ2OVqr+prCALRnQ1dGtDG1tGqGk2nCcJJrcaK6HhtalQRcypc8RZn8CAwEAAaOCAb8wggG7MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIPFnQuG8tIrgrWTDIODjlqE/NNggXmH0e1q5JkwAgFkAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBEGA1UdDwEB/wQHAwUEQDAwMDAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBRPO9BFXvhThi2Ill1j1IyuQWJVDDAlBgNVHREEHjAcghpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzAfBgNVHSMEGDAWgBSf9NVzUtr9IOSgZRN8SP8W+TbR5zBBBgNVHR8EOjA4MDagNKAyhjBodHRwOi8vY2RwLklBTVRFQy5ORVQvY3JsL1BLSS1ST09ULUNBLUlBTVRFQy5jcmwwgYoGCCsGAQUFBwEBBH4wfDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuSUFNVEVDLk5FVC9vY3NwMFEGCCsGAQUFBzAChkVodHRwOi8vY3J0LklBTVRFQy5ORVQvY3J0L1IxRlNSV0RDMS5JQU1URUMuTkVUX1BLSS1ST09ULUNBLUlBTVRFQy5jcnQwDQYJKoZIhvcNAQELBQADggIBAGv392nwZGDgSq7rapUXPdDcoM69a+nsGQhdH59TYwRhHWkgcCZH7la01ZYxky0Kf9ucaAbvBDlIXP088exB44Tqal30N/umZaKpddi1l5qtyJJ2vjNbNSA8wh+iLPpNf6h3uJwGDajoSIeONnuP5imVWlH0MFNhtgcF0nTDrDiST1xzvuquWDG806NEgIZXNx2RKzEi4JHjKnMDYSaPChEF8AtUGKHKd6XfW3vtqD3PUkyTP5wF1uVJ4W7iIb9C7PcR3UlcBzs3mfUOtOUkRiKzGzPCt8agDQ+lKOXshF3vjX0oB7ZJHuGoVI9brKzI0DyxB1JJ75rvIGBIhL/CGUvYwf9tGWUr1UfXykFQGZHSw5gpNesyHlEKjfm/vmwDBDYZpkXr09/ngCJ33HKFYIdvQWZuN8GFmb14HcM5tWV+A5rJMTyAD0+ybisBIt77VZBQU3lQvdAPVeNxYePyECxPRER/Mpwmu8ctxfvkmn7a3CBa9n6G+ZPTeYLKI3vMdjUSQdCRC4/Bgupv1c9Awsf93orjaRVcu1IIfTLUlUykFTieyBzcx5jUGxvlvPNhHDDkRo9fS9eD7m/ypTEIpV2JM/0rjepE0afCva+OAlHic0T4FgZGOTguIwnAQxkVCAig3WflGRuxtqLniYllubrGkJSHQjPLT6R27QtxcxPQ.
Secondary key: <none>.

After these actions the application published through the WAP and configured with ADFS pre-authentication was accessible again from the outside!

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Certificates, Forms Based AuthN, Pre-Authentication, Security Tokens, Web Application Proxy | Leave a Comment »

(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/ ########
———————————————————————————————

 

Posted in Active Directory Federation Services (ADFS), Kerberos Constrained Delegation, Web Application Proxy | 5 Comments »

(2014-04-02) Building An ADFS Lab In W2K12(R2)

Posted by Jorge on 2014-04-02


The guys from AskPFE have written an interesting series of building an ADFS lab on W2K12 and then upgrade that to ADFS on W2K12R2 .

How to Build Your ADFS Lab on Server 2012 Part 1

How to Build Your ADFS Lab on Server 2012, Part2: Web SSO

How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxy

How to Build Your ADFS Lab Part4: Upgrading to Server 2012 R2

With regards to migrating ADFS v2.x to ADFS v3.0, also have a look at (2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Based Apps, Migration, Proxy Service, Security Token Service (STS), Web Application Proxy | Leave a Comment »

(2014-03-24) ADFS v3.0 In W2K12R2 And Related Features In Summary With Details

Posted by Jorge on 2014-03-24


Mylo has written a number of blog posts focusing on his first impressions regarding ADFS v3.0 in W2K12R2 and related features (e.g. Workplace Join, Device Registration, Web Application Proxy, etc). The blog posts are a perfect summary with lots of interesting details. Wow, my compliments!

First Impressions – AD FS and Windows Server 2012 R2 – Part I

First Impressions – AD FS and Windows Server 2012 R2 – Part II

First Impressions – AD FS and Windows Server 2012 R2 – Part III (to be published by Mylo)

In addition to this Ramiro Calderon has written great blog posts focusing on MFA in ADFS v3.0. Again, my compliments!

Under the hood tour on Multi-Factor Authentication in ADFS – Part 1: Policy

Under the hood tour on Multi-Factor Authentication in ADFS – Part 2: MFA aware Relying Parties

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Device Registration, Security Token Service (STS), Web Application Proxy, Workplace Join | Leave a Comment »

(2014-02-27) Exchange OWA Through ADFS

Posted by Jorge on 2014-02-27


In following blog posts you can read how you can access OWA through federation and kerberos constrained delegation (KCD):

In the scenarios above the Claims To Windows Token Service (C2WTS) was used to perform the KCD part as ADFS itself is not capable of doing that

With the release of Exchange 2013 SP1, it is now natively supported and you do not need to perform all kinds of manual steps. Instead of using the C2WTS, you can now use the Web Application Proxy (WAP) to perform the KCD part.

see: Using AD FS claims-based authentication with Outlook Web App and EAC

Although I have not tried this myself, after reading it quickly I noticed a few weird things:

  • Step 1: Although true what is said, I would like to suggest the following regarding the certificates:
    • Service Communication Certificate for ADFS –> CA issued from an internal PKI if available, otherwise CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.)
    • Token Signing Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
    • Token Encryption Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
  • Step 2: If you are using CA issued certs for Token Signing Certificate and the Token Encryption Certificate you need to install ADFS through FSCONFIG.EXE (ADFS v2.0 and ADFS v2.1) or INSTALL-ADFSFARM (ADFS v3.0) and specify the thumbprint of the certificates. You need to make sure those certificates are in the local certificate store first!
  • Step 2: it is not true you require a group Managed Service Account. Sure that would be preferred, you must have at least one W2K12 DC or higher to be able to support that. However in all cases you can still use a normal service user account.
  • Step 3: I’m kind of surprised to see the so called require claims rules for both the OWA relying part trust as the EAC relying party trust. Like I said, I have not done this myself yet, but I would expect to only require the pass-through of the UPN claim on both RP trusts. Of course you need to ask yourself "if I pass it through, where do I pass it from then?" Right! You gather the UPN claim by using a claim rule on the claims provider trust. How you do that differs from ADFS v2.x and ADFS v3.0. With ADFS v2.x you need to perform an LDAP query (using the LDAP Claim Rule Template) and in ADFS v3.0 you can pass it through (see: "(2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0" and "(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)")
  • Step 4: No clue WHY the claims rules are being added, again. That was already done in step 3. Again no clue why you need the Primary SID and the Group SID
  • Step 5: I saw the following line: "Although Web Application Proxy isn’t required" Huh? Who’s going to do the KCD part then? I agree you should use WAP when allowing external access. But for internal access, if WAP is not required, is that the reason why they are sending the "Primary SID" claim and the "Group SID" claim? Hmmmm, interesting. I wonder if ADFS has some hidden feature regarding KCD. To be investigated!

Well, have fun!

If you try it yourself, please let me know your findings. Thanks in advance

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/ ########
———————————————————————————————

 

Posted in Active Directory Federation Services (ADFS), Claims Based Apps, Exchange Server, OWA, Security Token Service (STS), Web Application Proxy | Leave a Comment »

 
%d bloggers like this: