ADFS Error When Adding a RP Trust

I run into an error that was being thrown when I was attempting to add a new Relying Party Trust for one of my customers. When executing the following PowerShell code:

Add-AdfsRelyingPartyTrust -Name "My App Name" `
-Notes "My App Notes" `
-MetadataUrl “”

I received the following error:

Add-AdfsRelyingPartyTrust : The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Add-AdfsRelyingPartyTrust -Name "My App" -Notes "My App Notes"...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Add-AdfsRelyingPartyTrust], WebException
+ FullyQualifiedErrorId : The request was aborted: Could not create SSL/TLS secure channel.,Microsoft.IdentityServer.Management. 

After checking over the PowerShell CMDLET and some scouring of the internet I managed to find a solution which involved editing the registry to force .NET applications to use stronger cryptography.

I changed the following registry key values as instructed:

      SchUseStrongCrypto = (DWORD): 00000001

       SchUseStrongCrypto = (DWORD): 00000001

After making these changes, a reboot of the servers was required to ensure that the new registry values were picked-up correctly by all .NET applications on the server (including ADFS).

After the reboot had completed, I attempted to execute my PowerShell code mentioned earlier, this time the code executed without error and my new Relying Party Trust was created.


DNS Architecture

DNS Architecture

The following article describes and depicts the recommended architecture for integrated DNS with Active Directory. It is highly recommended that Active Directory Integrated DNS be deployed within enterprise networks that utilise Active Directory as the authoritative authorisation and authentication mechanism, the following diagram builds on the standard Active Directory Integrated DNS architecture to provide higher levels of DNS resiliency and security.

The following solution doesn’t account for deployment of DNSSEC. DNSSEC is a large topic, something that I hope to document in a future article.

Walking through the above diagram from bottom to top:

  1. The domain client devices are configured (using group policy) for a Primary and Secondary DNS settings pointing to the main Active Directory Integrated DNS Servers. In this diagram, Domain Controller 1 is the Primary and Domain Controller 2 is the secondary DNS server.
  2. TLD Root Hints have been removed from the DNS Service on the Domain Controllers. The Domain Controller DNS Service is configured to Forward all “unknown” DNS requests to DNS Server 1 and/or DNS Server 2, respectively.
  3. DNS Servers 1 and 2 have had their TLD Root Hints removed from the DNS Service configuration. Both DNS servers are configured with Forwarders to the ISP DNS Services.
  4. There are three layers to the network security boundaries for the depicted solution. Campus being the location for client devices and campus infrastructure. Intranet being the internal server boundary. Perimeter being the internet facing services boundary. Finally, internet being the far edge of the network boundary for the depicted enterprise infrastructure.


In this article we briefly examined the recommended architecture for DNS within an Active Directory Integrated DNS Environment.