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 ‘Active Directory Federation Services (ADFS)’ Category

(2017-03-28) Why You Should Turn On Forms Based Authentication (FBA) For The Intranet In ADFS!

Posted by Jorge on 2017-03-29


Right after the install, every ADFS farm by default has Windows Integrated Authentication explicitly enabled and Forms Based Authentication disabled on the intranet. Below you see a screenshot from ADFS v4.0, and the settings for ADFS v2.x and ADFS v3.0 are similar.

image

Figure 1: Authentication Methods For The Intranet In ADFS (WIA Enabled And FBA Disabled)

Previously you only had to enable Forms Based Authentication (FBA) for the Intranet in ADFS when you for example used Microsoft CRM Dynamics.

Now with Azure AD playing a very important role in almost every infrastructure, I’m suggesting/recommending to enable FBA by default for the Intranet in ADFS.

Of course you ask: “WHY?”

With Azure AD on the playground you also need FBA for the Intranet in ADFS for the following scenarios:

  1. Azure AD/MSOnline PowerShell Module
  2. Azure AD Self-Service Password Reset

[AD.1]

Every time you connect to Azure AD using a federated account where a browser based window is opened, FBA will be used. If FBA is not enabled, you will get an error

This problem does not occur if you use a native Azure AD Account, or you use a federated account that is specified in the credentials parameter of the PowerShell CMDlet and is also not enforced for MFA!

image

Figure 2: Authentication Screen When Using The Azure AD/MSOnline PowerShell Module

image

Figure 3: Error After Entering Your Federated Account Credentials

[AD.2]

Sometimes with Self-Service Password Reset, Azure AD will ask you to reconfirm your password. You may experience this when:

  • Navigating to https://myapps.microsoft.com/ with a browser, for which WIA is enabled in ADFS. Logon as you normally do with your corporate desktop/laptop
  • Next to your picture, click on “Profile”
  • The click on “Set up self service password reset”
  • It could be the case, the next screen will say “Confirm you current password”
  • Click on “Re-enter my password” and you will be redirected to ADFS and that’s were it will go wrong if FBA is not enabled

In both scenarios you will see the following error in the ADFS Event Log

image

Figure 4: Error In The ADFS Admin Event Log When FBA (In This Case) Is Not Enabled For The Intranet

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.
   at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.ProcessRequestedAuthMethodsV2(IEnumerable`1 requestedAuthMethods, HashSet`1 globalPolicyAuthProviders, String[] authProvidersInToken, Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicyV2(IList`1 mappedRequestedAuthMethods, IList`1 mappedRequestedACRAuthProviders, AccessLocation location, ProtocolContext context, HashSet`1 authProvidersInToken, Boolean isOnWiaEndpoint, Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomainV2(Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Therefore: enable FBA for the Intranet in ADFS as soon as you install ADFS. If you want to enabled it later on, make sure first no application is impacted when the “Active Directory” IdP is used.

image

Figure 5: Authentication Methods For The Intranet In ADFS (WIA Enabled And FBA Enabled)

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), Forms Based AuthN, Windows Integrated AuthN | Leave a Comment »

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

Posted by Jorge on 2017-03-01


This post is about disabling weak ciphers, hashes, cipher suites and protocols in ADFS, WAP, AAD Connect and Azure AD MFA server. The main focus however, is disabling weak protocols in ADFS, WAP, AAD Connect and Azure AD MFA 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\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\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

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\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 one line, but it must be a comma-separated list):

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

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 Connect, Hardening, Web Application Proxy | 3 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 »

(2017-02-10) Latest MSOnline And AzureAD PoSH CMDlets Require FBA On The Intranet Within ADFS

Posted by Jorge on 2017-02-10


When using the latest MSOnline or the AzureAD PoSH CMDlets with a federated account in the following scenarios:

  1. Running the “Connect-MSOnline” or the “Connect-AzureAD” CMDlets with the credentials parameter
  2. Running the “Connect-MSOnline” or the “Connect-AzureAD” CMDlets with/without the credentials parameter for a federated account for which MFA is enforced through conditional access in AAD

… you might experience the issues as explained in this blog post.

The issues do not occur when using native Azure AD accounts (non-federated).

Running the “Connect-MSOnline” or the “Connect-AzureAD” CMDlets in any of the scenarios above you will see the following logon screen for Azure AD pop up

clip_image002

Figure 1: Azure AD PowerShell Logon Screen

After enter the username of the federated account and clicking on the password field, you will be redirected to ADFS to actually logon after providing your AD account password. At least, that’s the idea.

However, instead you will see an error very similar to what you see below.

image

Figure 2: Error Thrown By ADFS After The Redirection For Authentication

Looking at the ADFS/Admin Event Log and searching for the event ID that has the same correlation ID as the activity ID shown above, you will find the following event ID.

clip_image006

Figure 3: Error Event In The ADFS/Admin Event Log

Encountered error during federation passive request.

Additional Data

Protocol Name:

wsfed

Relying Party:

urn:federation:MicrosoftOnline

Exception details:

Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.

   at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)

   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)

   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)

   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)

   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)

   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

After closing the Azure AD PowerShell Logon Screen, you will see the following error

clip_image008

Figure 4: Error In The PowerShell Command Prompt Window After Closing The Azure AD PowerShell Logon Screen

Connect-MsolService : Authentication Error: Unexpected authentication failure.

At line:1 char:1

+ Connect-MsolService

+ ~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Exception

    + FullyQualifiedErrorId : System.Exception,Microsoft.Online.Administration.Automation.ConnectMsolService

PS C:\>

The solution to all these problems is to enable “Forms Authentication” for the Intranet within the ADFS Global Authentication Policy. By default for the intranet only “Windows Authentication” is enabled, but you need to enable “Forms Authentication” in addition as shown in the picture below

clip_image010

Figure 5: Enabling Forms Authentication For The Intranet On The ADFS Global Authentication Policy

Now, after entering the username of the federated account and clicking on the password field, you will be redirected to ADFS to actually logon after providing your AD account password. After providing the password and clicking “Sign In”, ADFS will try to authentication you. This will succeed assuming you have the correct federated accounts and its corresponding password.

image

Figure 6: ADFS Forms Based Logon Screen After Being Redirected Successfully To ADFS

After clicking “Sign In” and having ADFS authenticate you successfully through Forms Authentication, you will see that authentication has succeeded as the screen below does not show any errors

clip_image014

Figure 7: Successful Authentication Through ADFS To Azure AD

PS: Another application that will behave like this, when Forms Authentication is not enabled for the Intranet, is CRM Dynamics from Microsoft!

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), Forms Based AuthN, PowerShell, Windows Azure Active Directory | Leave a Comment »

(2017-01-15) Azure AD Connect Health Telling The ADFS Farm Just Dropped Dead!

Posted by Jorge on 2017-01-15


When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

(Don’t worry, this is just my test/demo environment that was turned for the holidays)

image

image

image

Figure 1: E-mail From Azure AD Connect Health Mentioning The Token Signing Certificate Has Expired

image

image

image

Figure 2: E-mail From Azure AD Connect Health Mentioning The Token Encryption/Decryption Certificate Has Expired

image

image

Figure 3: E-mail From Azure AD Connect Health Mentioning The SSL Certificate Has Expired

In addition, your ADFS Admin Event Log only displays one color, RED, lots of it!

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 Connect Health, Certificates, Windows Azure Active Directory | Leave a Comment »

(2016-12-24) Can You Use ADFS v2.x To Federate With Azure AD?

Posted by Jorge on 2016-12-24


You might still be running ADFS v2.0 and you want to know if you can federate with Azure AD and what possible limitations are.

Below you can find my experiences:

  1. Federated user authentication against Azure AD will work
  2. Federated computer authentication against Azure AD will NOT work. In other words Auto Azure AD join will not work
  3. Redirecting MFA from Azure AD to on-premises ADFS will NOT work, unless you have a custom developed MFA solution for ADFS v2.x

[AD.1]

The read about the configurations required, see (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail. Look at the claims rules for user authentication on the RP trust for Azure AD and the CP trust for AD.

[AD.2]

All the required configurations as mention in (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail can be achieved in ADFS, except one! You just configure the "AllowedAuthenticationClassReferences" on the RP trust for Azure AD, which is not possible in ADFS v2.0

[AD.3]

To use MFA with ADFS v2.0, like it is possible in ADFS v3.0 and higher, you have bought or developed a custom MFA solution. Any investment in that is pointless as you cannot reuse it in any way in ADFS v3.0 or higher due to the different architecture. Therefore, without an MFA solution in ADFS v2.0 you will not be able to redirect any MFA required to the on-premises ADFS. It must be processed by Azure AD itself.

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 / Office 365, Workplace Join | Leave a Comment »

(2016-10-05) Exporting And Importing ADFS Configuration For Cloning Or Recovery Purposes

Posted by Jorge on 2016-10-05


Microsoft has released a tool to export and import the complete ADFS configuration to/from a file on either the local file system or in Azure.

With this tool the assumption is made your complete ADFS farm is dead and the only thing you got is a backup or the exported configuration, OR you want to rebuild ADFS farm in another environment. As it mandatory to encrypt the backup/export, make sure to store the password in a safe and controlled accessible location. You don’t want to end up with a backup/export and not knowing the password anymore to decrypt it! When you want to rebuild the ADFS farm in another environment (e.g. production environment to test environment), please be very careful where that backup/export ends up. Remember it contains all the certificates in used by the ADFS farm, and especially the Token Signing certificate and the Token Encryption certificate are very important.

With the backup, it exports everything in the ADFS configuration database. The ADFS configuration is stored in the files “config.xml”, “db.xml”, “installParams.xml” and “metadata.xml”. Except for that last file, the other files are encrypted with the password specified during the backup/export.

It also exports all ADFS related certificates and corresponding private keys from the local machine certificate store if those private keys are exportable. To find out which certificates to export to a PFX file, the tool looks in ADFS to find all the primary and secondary configured certificates for the service communication certificate, the token signing certificate and the token encryption certificate. It also looks which certificate is configured for the binding “<FQDN Federation Service>:443” as the SSL certificate (viewable with NET HTTP SHOW SSLCERT). The SSL certificate is stored in the file “SSLCert-<Thumbprint>.pfx”. The primary and secondary certificates for the service communication certificate, the token signing certificate and the token encryption certificate are exported to a file “OtherCert-<Thumbprint>.pfx”. All PFX files are protected with the password specified during the backup/export.

image

Figure 1: Backup/Export Created By The ADFS Rapid Creation Tool

As mentioned earlier, main use of the tool is to either recreate a dead ADFS farm or clone an ADFS farm in another environment. When using the tool during backup, it backups everything in ADFS.When using the tool during restore, it restored everything in from the export. It is not possible to select individual components from the backup and only restore those. Maybe in a next version. In theory it would be possible to also restore one or more ADFS configuration components after an admin mistake (e.g. deletion of one or more RP trusts). However if the backup/export used to restore a missing component still contains that missing component but is outdated you will restore that missing component, but it will also bring your ADFS farm back in time.

In a WID based ADFS farm I restored the backup/export that was created on the primary ADFS server on that primary ADFS server. The other secondary WID based ADFS servers were still running happily with no issues. After the backup you may still need to install software/DLLs to support any configured MFA provider or attribute store. This is especially important when cloning the ADFS farm. After that you need to start the ADFS service on the primary ADFS server. After restarting the ADFS service on the other already existing secondary ADFS servers, those secondary ADFS servers started to  replicate again from the primary ADFS server. Although I did not test it, I assume it would have a similar behavior when using a SQL based ADFS farm. Please be aware I did not check everything, and I do not know if this is a supported scenario or not. My advise is to not use this to restore individual components. To restore individual components (e.g. CP and/or RP trusts) use PowerShell scripting (see future blog post)

Now, let’s install this tool. After executing the MSI, the following screen is displayed

image

Figure 2: Welcome Screen

image

Figure 3: License Agreement Screen

The default installation folder by default is “C:\Program Files (x86)\ADFS Rapid Recreation Tool\”

image

Figure 4: Installation Folder And Who Will Be Using The Tool Screen

image

Figure 5: Install Confirmation Screen

image

Figure 6: Install Completed Screen

Afterwards to load the module execute the following command:

Import-Module "C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll"

To find out all the available CMDlets, execute the following command:

Get-Command -Module ADFSRapidRecreationTool

image

Figure 7: Importing PowerShell Module And Listing All Available CMDlets

For example, to create a backup/export to some folder on the file system, execute the following command, and make sure to replace the values with your own values:

Backup-ADFS -StorageType FileSystem -BackupComment "2016-10-02 16:30:00" -StoragePath "C:\ADFS-Support\Config-Export\2016-10-02_16.30.00_FedSvcConfig_MSFT-Tool" -EncryptionPassword ‘Pa$$w0rd’

image

Figure 8: Creating A Backup/Export To The File System

For example, to restore a backup/export from some folder on the file system, execute the following command, and make sure to replace the values with your own values:

Restore-ADFS -StorageType FileSystem -StoragePath "C:\ADFS-Support\Config-Export\2016-10-02_16.30.00_FedSvcConfig_MSFT-Tool" -DecryptionPassword ‘Pa$$w0rd’

image

Figure 9: Restoring A Backup/Export From The File System – Entering The Credentials Of The ADFS Service Account

image

Figure 10: Restoring A Backup/Export From The File System

After the restore the ADFS service is not running! Also pay attention to the text file mentioned

image

Figure 11: Text File With Additional Steps To Execute Before Starting The ADFS Service

After installing the additional software or placing the DLLs on the ADFS folder to support additional MFA providers or attribute stores, restart the ADFS service

Also have a look a the following links for additional information and the download location of the tool:

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), Export/Import | Leave a Comment »

(2016-08-08) Configuring Custom Logos For Your Identity Providers/Claim Providers Trusts

Posted by Jorge on 2016-08-08


As the page “Customizing the AD FS Sign-in Pages” already explains, use configure custom logos for your HRD page, being

  • The Illustration (in figure 1 – on the left)
  • The Logo (in figure 1 – upper right)
  • The Local STS Icon (in figure 1 – IdP called “IAM Technologies”)
  • The Remote IdP Icon for which no suffixes have been configured (in figure 1 – last 3 IdPs)

That then looks like it is displayed in figure 1

image

Figure 1: HRD Page With A Custom Illustration, A Custom Logo, A Custom Icon For the Local STS And a Custom Icon For Other Remote IdPs

However, have you ever wanted to see it like it is displayed in figure 2?

image

Figure 1: HRD Page With A Custom Illustration, A Custom Logo, A Custom Icon For the Local STS And a Custom Icon For Every Individual Remote IdP

Yes, that is possible!

To configure the logo execute the following command:

Set-AdfsWebTheme –TargetName <Web Theme> -Logo @{path="<Path To Logo JPG/PNG>"}

To configure the illustration execute the following command:

Set-AdfsWebTheme -TargetName <Web Theme> -Illustration @{path="<Path To Illustration JPG/PNG>"}

To configure the logo for the local STS execute the following command:

Set-AdfsWebTheme -TargetName <Web Theme> -AdditionalFileResource @{Uri=’/adfs/portal/images/idp/localsts.png’;path="<Path To Local STS Logo JPG/PNG>"}

To configure the logo for the Remote IdP/STS, for which no suffix is configured, execute the following command:

Set-AdfsWebTheme -TargetName <Web Theme> -AdditionalFileResource @{Uri=’/adfs/portal/images/idp/idp.png’;path="<Path To General IdP Logo JPG/PNG>"}

To configure the logo for the Remote IdP/STS, for which at least one suffix is configured, execute the following command:

Set-AdfsWebTheme -TargetName <Web Theme> -AdditionalFileResource @{Uri=’/adfs/portal/images/idp/otherorganizations.png’;path="<Path To Other Organizations Logo JPG/PNG>"}

To configure the logo for the Remote IdP/STS with a custom (company) logo, execute the following command

Set-AdfsWebTheme -TargetName <Web Theme> -AdditionalFileResource @{uri="/adfs/portal/images/idp/<CP Trust Name>.png";path="<Path To Custom IdP Logo JPG/PNG>"}

REMARK: If you rename a CP trust, you also need to rename the web file in the URL! If you do not, the general IdP logo is displayed

REMARK: Instead of using PNG files, you can also use JPG files! Whatever extension you use, the extension of the file being imported must match the extension of the web file in the URL!

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), Home Realm Discovery (HRD), Web Themes | Leave a Comment »

 
%d bloggers like this: