The Authentication Endpoint Username Was Not Found On The Configured Secure Token Service and Port 808

While not recommended, circumstances sometime present the need to install CRM and ADFS on the same server. If this is done on Windows Server 2012 R2, you will likely run into issues connecting anything through the discovery service such as the Outlook Add-In, Email Router, and Plugin Registration Tool. The error will read:

The authentication endpoint Username was not found on the configured Secure Token Service.

If taken literally, one would be tempted to go to the ADFS Configuration and enable the /adfs/services/trust/13/username endpoint as shown below:

DO NOT DO THIS! On the outside chance that it does actually fix the immediate issue it can cause further authentication problems and is NOT recommended – despite what some other blogs/forums may tell you.

Further investigation should eventually lead you to this error in the ADFS event viewer logs:

System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:808. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. —> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

With ADFS for Server 2012 R2, net.tcp port 808 is utilized for a function of the federation service. You may recall that port 808 is also used by CRM for its sandbox service so it’s easy to see the problem here. Port conflict! Luckily, the solution is rather simple. Just open a PowerShell prompt on the server and enter the following:

Set-ADFSProperties -nettcpport 809

(Note: In the above the command, 809 is just an example of a port that can be used and is not required. If something else is running over port 809 on your server, substitute it for some other number.)

After the command has been run, restart the ADFS service, IIS, and the email router service (if the email router was having the issue connecting) – to be on the safe side, you could just reboot the whole server. Give it another go and you should be in business! If you are wondering why this hasn’t been an issue with past versions of ADFS, it's because the federation services used to run on ports 1500 and 1501.

Next Button Grayed Out in Internet-Facing Deployment Configuration Wizard

While recently assisting a colleague with setting up IFD, we stumbled upon an interesting bug with CRM 2016 in which we could not advance in the IFD wizard because the “Next” button was grayed out and disabled. No matter what we typed in the field, it would not enable the button. Tried an IISReset, restarting CRM services, and even a reboot but they all failed to help.

Realizing this had to be an issue within MSCRM_CONFIG database, we took a look at the tables that hold the IFD properties that we input in these wizards. What we found was that somehow the NVarCharColumn value of ExternalRelyingPartyPassiveIdentifier in the FederationProviderProperties table was set to “uri:ifdMicrosoftCRM”. Typically we would see the Auth URL in this field so we updated it manually to “https://auth.domain.com” in SQL. Make sure to include the “https://” - even though we do not enter this in the field during the configuration wizard, it gets appended automatically and set in the database. Issue an IISRESET on the CRM server and then re-launch the CRM Deployment Manager.

Please note that editing the database manually via SQL is not supported by Microsoft and you are doing so at your own risk. Always take backups and use caution.

CertificateDuration of ADFS Token Certificates

At the end of a past blog post on my page (http://blog.gagepennisi.com/2016/01/understanding-adfs-token-signing-and.html), I touched on the subject of extending the certificate validity period from the default of one year. Recall that when these certificates expire or rollover automatically, CRM becomes inaccessible so reducing the frequency of how soon these expire will reduce the downtime associated. Let’s dig in:

1. Open an administrative PowerShell prompt on the ADFS server
2. If using Server 2008 R2 (ADFS 2.0), add the ADFS Snap-in:
             Add-PSSnapin Microsoft.ADFS.PowerShell
3. Set the CertificateDuration property (Note: ‘1095’ below is an example and represents the number of days desired. 1,095 days = 3 years):
             Set-AdfsProperties -CertificateDuration 1095
4. Create new token certificates with the new duration:
             Update-AdfsCertificate –Urgent
5. Update the ADFS metadata stored in the CRM databases by running through the Claims-based Authentication and IFD Wizards in the CRM Deployment Manager.
6. Issue an IISRESET on CRM Server(s).

CRM and ADFS should both now be working with your extended-duration token certificates!

Note: If you have just installed ADFS, and not yet set CRM up for Claims-based Authentication/IFD, you do not need to perform steps 5 and 6.