Recently we upgraded a customers Microsoft Dynamics CRM deployment from MS CRM 2011 to MS CRM 2015. Go Live day came and all was well. Users were accessing the system from inside the network and from outside the network using IFD. Job well done!
Not so quick! Come the next day and without warning, users could no longer access CRM from either the internal URL nor the external URL. After a bit of research we found that CRM could be accessed using the default machine name and port 5555. Knowing that this method bypasses ADFS, the issue must either be with ADFS or the security certificate.
Next stop, Event Viewer! Here we found two Events that confirmed our suspicions. Event ID 364 encountered an error during federation passive request and Event ID 317 encountered an error during an attempt to build the certificate chain for the relying party trust.
This directed us to confirm that the relying party trusts were correct and that the SSL certificate was valid. Everything checked out, so we were slightly stumped at this point.
While researching this issue, we found that the server hosting MS CRM could not access the internet. Browse requests met with Page Cannot be Found errors, pings met with time-outs, however DNS resolutions were successful. In addition, users from outside the LAN were obviously connecting to the server as the server logs showed and of course the connection over port 5555.
We discovered that in order for a client to make a secure connection using SSL, the client can validate that the certificate was not incorrectly issued or that it had not been revoked using information provided in the certificate. For more information on this, check out this blog on Understanding Certificate Revocation Checks.
Because the server could not access the internet, the client was unable to use the ADFS Revocation Check to determine if the sites certificate was valid. Thus the users were being denied access to the site.
As a quick work around in order to allow users to connect to CRM, the requirement to check for a revoked certificate was temporarily turned off. To do this we used PowerShell and the following commands on each Relying Party Trust in ADFS:
SET-ADFSRelyingPartyTrust -TargetName <YourRelyingPartyName> -EncryptionCertificateRevocationCheck None
Our next task was to determine why the server could not access the internet. For this the clients networking team was engaged. They discovered that the servers TCPIP stack had become corrupted. After a quick fix the server could now access the internet and we reversed our work around.
Crisis over and users were once again able to access their MS CRM 2015 environment securely.
Beringer Associates is always here to provide expert knowledge on topics like these. Please contact us with any questions you may have.