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 “https://somemetadataurl.com/saml”

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. 
Commands.AddRelyingPartyTrustCommand

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:

HKEY_LOCAL_MACHINE\SOFTWARE\
   \Microsoft\.NETFramework\\<version>
      SchUseStrongCrypto = (DWORD): 00000001

HKEY_LOCAL_MACHINE\SOFTWARE\
    Wow6432Node\Microsoft\\.NETFramework\\<version>
       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.

 

ADFS Authentication Workflow

In this article we take a look at the Active Directory Federation Services (ADFS) Authentication Workflow that occurs when a client attempts to access a third-party federated web service.

The following diagram depicts the authentication workflow for ADFS when accessing third-party federated web services (applications).

CN_ADFS-Authentication-Workflow

Walking through the above diagram step-by-step:

  1. The user (client) accesses the web URL for the Fabrikam Web Server using their client web browser. The client doesn’t have an authentication token and must be federated to access this application.
  2. The website issues a HTTP redirect to the user’s web browser, directing them to visit the Fabrikam federation services URL.
  3. The user’s browser accesses the Fabrikam Federation Service.
  4. The Fabrikam federation service attempts to resolve the URL for Contoso Identity Provider (IDP) and issues an HTTP redirect to the user’s browser.
  5. The user’s browser accesses the Contoso ADFS server.
  6. The user initialises authentication with the Contoso ADFS server and is issued with a token signed by the ADFS server’s Token Signing Certificate. The ADFS service issues a HTTP redirect to the user’s browser, directing them back to the Fabrikam ADFS service.
  7. The user’s browser presents the token to the Fabrikam Federation service.
  8. The Fabrikam Federation service validates the token and issues the user with a new token which is valid for Fabrikam web service. The ADFS service issues a HTTP redirect to the Fabrikam web server.
  9. The user accesses the Fabrikam Web Server and presents the token which was issued by the Fabrikam ADFS service. The web server validates the token and authorises the user to access the application.

Closing

In this article we looked at the workflow process that occurs each time a user attempts to access an ADFS federated web service.

 

ADFS: WIA Supported User Agents

One of my customers had issues with SSO not working as expected. Upon investigation I found that this was because additional configuration was required in order to enable the SSO capabilities and support for Microsoft Edge and Mozilla Firefox web browsers. The following process enables you to modify the WIA Supported User Agents in ADFS which will enable SSO for various web browsers.

1. First we check the current configuration of the WIASupportedUserAgents properties using Get-ADFSProperties cmdlet as shown below:

1
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

The following output was recorded for the existing configuration of WIASupportedUserAgents properties.

MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge

2. Next we need to add support for Mozilla Firefox web browsers using the Set-ADFSProperties cmdlet as shown below:

1
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Mozilla/5.0')

3. Finally, add the configuration to support SSO for the Microsoft Edge web browsers using the Set-ADFSProperties cmdlet:

1
2
3
4
5
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Edge/12')
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Edge/13')
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Edge/14')
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Edge/15')
Set-ADFSProperties -WIASupportedUserAgents (((Get-ADFSProperties).WIASupportedUserAgents)+'Edge/16')

4. After applying the above changes, restart the ADFS Service on all ADFS Servers using:

1
Restart-Service adfssrv

5. After the services have been restarted, check that the configuration has applied successfully and test that the ADFS IDP Initiated Sign-on is fully operational.

1
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

The following output was recorded for the configuration post-changes.

MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge
Mozilla/5.0
Edge/12
Edge/13
Edge/14
Edge/15
Edge/16

From the above, we can note that support for the additional browsers has been added to the configuration as expected.

ADFS: Enable Sensible Logging

To enable sensible logging, perform the following steps.

1
AuditPol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

ADFS: Enable End-User Password Change Functionality

To enable the capability for users to be able to change their passwords via ADFS login page, the following command will enable the functionality.

1
2
3
Enable-ADFSEndPoint –TargetAddressPath “/adfs/portal/updatepassword/”
Set-ADFSEndPoint “/adfs/portal/updatepassword/” –Proxy:$true
Restart-Service ADFSSrv -Force

ADFS: Increase the Validity of ADFS Generated Certificates

To increase the validity period for ADFS Self-Generated Certificates for the Token-Signing and Token-Decrypting certificates, execute the command below to set them to three years.

1
2
Set-ADFSProperties –CertificateDuration 1095
Update-ADFSCertificate -Urgent

ADFS: Enable Automatic Certificate Rollover

To enable Automatic Certificate Rollover feature for  ADFS Token-Signing and Token-Decrypting certificates execute the following powershell command.

1
2
Set-ADFSProperties –AutoCertificateRollover $true
Update-ADFSCertificate -Urgent

ADFS: Set Account Lockout Threshold and Duration

To enable protection against brute-force hacking against your domain user accounts, it is recommended that account lockout threshold and duration be enabled. To do so, execute the following command, changing any parameters as required.

1
2
3
4
Set-ADFSProperties –EnableExtranetLockout $true `
–ExtranetLockoutThreshold 15 `
–ExtranetObservationWindow ( New-TimeSpan –Minutes 30 ) `
–ExtranetLockoutPDC $false