AD FS Help Troubleshooting All users can't login using AD FS from inside corpnet
What does this guide do?
This workflow resolves sign-in issues with Active Directory Federation Services (AD FS) inside corpnet. It does not cover seamless SSO / unexpected prompt configuration or troubleshooting of sign-in happening via the Web Application Proxy (WAP).
Who is the target audience?
Administrators who help diagnose SSO issues for their users.
How does it work?
We’ll begin by asking you the symptom and then we’ll take you through a series of troubleshooting steps that are specific to your situation.
This is not a good situation, let's fix this quickly. First, ensure that all AD FS servers are working as expected. We will use the AD FS diagnostic script to automatically check the health of the AD FS servers in your farm.
Go to AD FS Help and download the diagnostic script from Downloadable Tools.
Let's check DNS and any load balancer settings.
DNS checks for corpnet / internal access
An access attempt from an internal network should point directly to the AD FS server(s) or a load balancer in front of the servers.
Load Balancer
Firewall
Both the firewall located between the Web Application Proxy and the federation server farm and the firewall between the clients and the Web Application Proxy must have TCP port 443 enabled inbound.
In addition, if client user certificate authentication (clientTLS authentication using X509 user certificates) is required, AD FS in Windows Server 2012 R2 requires that TCP port 49443 be enabled inbound on the firewall between the clients and the Web Application Proxy. This is not required on the firewall between the Web Application Proxy and the federation servers.
If you have Azure AD Connect, you should use it for managing the SSL certificates on your AD FS and WAP farm. Refer to https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectfed-ssl-update
Is the certificate from a trusted authority?
AD FS requires that the SSL certificate be issued from a trusted root certificate authority. If AD FS is going to be accessed from non-domain joined machines, then it is suggested to get a certificate from a trusted third party root certificate authority like DigiCert, VeriSign, etc. If the certificate is not from a trusted root certificate authority, then SSL communication can break.
Is the certificate subject name valid?
The subject name of the certificate should match the federation service name. It can also be listed as a subject alternate name. You can get the federation service name by using the following cmdlet on the AD FS primary server:
Get-AdfsProperties | select hostnameThe certificate subject name cannot be the same as your AD FS server name
Is the certificate revoked?
Check for certificate revocation. If the certificate is revoked or the revocation list cannot be reached, the SSL connection cannot be trusted and will be blocked by clients.
Ensure the certificate is installed on all AD FS and WAP server's certificate stores
For successful configuration of the SSL certificate for your AD FS farm, it should be stored in the local computer personal certificates store on each federation server in your farm. You can install the certificate in the local computer personal store of each federation farm by double-clicking the .PFX file and completing the wizard. Ensure the certificate is installed in the local computer personal certificates store on each federation server.
PS:\>dir Cert:\LocalMachine\MyTo confirm, open a Windows PowerShell window and execute the following command to list the contents of the local machine store:
Check and ensure the SSL certificate is installed on all AD FS servers in the farm
To get the current AD FS SSL certificate thumbprint, use the PowerShell cmdlet: Get-AdfsSslCertificate
If the thumbprint of the SSL certificate already configured does not match the expected certificate thumbprint, use the cmdlet Set-AdfsSslCertificate –Thumbprint <thumbprint>.
Ensure the certificate is set as the Service Communication certificate
The SSL certificate also needs to be the service communication certificate in your AD FS farm. This does not happen automatically. You can do this via the MMC -> Certificates -> Set Service Communications Certificate. If the Service Communication certificate is not set properly, use the MMC to set the correct certificate and follow the below steps to set correct permissions on the new certificate:
Certificate has all correct DRS names as subject alternate names (SAN)?
If you have configured AD FS with DRS, then you must make sure that your new SSL certificate for AD FS is also properly configured for DRS. For example, if there are two UPN suffixes - contoso.com and fabrikam.com, then the certificate has enterpriseregistration.contoso.com and enterpriseregistration.fabrikma.com as SANs.
Use Get-AdfsDeviceRegistrationUpnSuffix to find all the UPN suffixes being used in the organization and whether the certificate has the required SANs configured.
Checking bindings and update if necessary
For addressing non-SNI cases, it is possible that administrators specify fallback mappings. Other than the standard federationservicename:443 binding, look for bindings under the two application IDs:
{5d89a20c-beab-4389-9447-324788eb944a} – AD FS App ID
{f955c070-e044-456c-ac00-e9e4275b3f04} – Web Application Proxy App ID
For exmple, if a binding for 0.0.0.0:443 has been specified, this is a binding for fallback. In case the SSL certificate has been specified for any binding like this, ensure that while updating the SSL certificate such bindings were taken care of.
AD FS provides various endpoints for different functionalities and scenarios. Not all endpoints are enabled by default. To check if a particular endpoint is enabled or disabled: