Things to Check Before Troubleshooting AD FS 2.0
Updated: May 5, 2010
Applies To: Active Directory Federation Services (AD FS) 2.0
Before you begin troubleshooting Active Directory Federation Services (AD FS) 2.0, ensure that you can provide administrative credentials. You should also verify that AD FS 2.0 is set up and running properly.
Make sure that you have administrative credentials on the computer that you are troubleshooting
You cannot modify AD FS 2.0 settings unless you are a member of the Administrators group on the computer that you are troubleshooting.
To make sure that you are a member of the Administrators group
Open the Computer Management snap-in.
To open Computer Management, click Start, point to Administrative Tools, and then click Computer Management.
In the console tree, double-click Local Users and Groups, and then click Groups.
In the details pane, double-click Administrators, and then verify that your account name (or a group in which your account is a member) appears in the Members list.
You can also make sure that you have the appropriate administrative credentials by completing the procedures in the following section.
Verify that AD FS 2.0 is installed and running
Before you perform the configuration and troubleshooting processes that are described in this guide, verify that you have AD FS 2.0 installed and that the AD FS 2.0 Windows service itself is running.
The AD FS 2.0 Federation Service is deployed as either a stand-alone federation server, as part of federation server farm, or in the role of a federation server proxy. For each installation of AD FS 2.0, use the following procedure to verify that AD FS 2.0 is running as expected.
To verify that AD FS 2.0 is installed and running
Open the Server Manager snap-in.
To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.
In the console tree, double-click Configuration, and then click Services.
In the details pane, click AD FS 2.0 Windows Service, and verify that the service is started.
Note
Regardless of whether AD FS 2.0 is running as a federation server or as a federation server proxy, the service is named the same. You can use net start adfssrv or net stop adfssrv, respectively, to start and stop the service in a Command Prompt window.
Tip
To verify that the service has been started successfully, you can also look for Event ID 100 in the AD FS 2.0 event log. This event indicates successful startup of the AD FS 2.0 Windows service.
If the service is not running, AD FS 2.0 might be installed but not fully configured. To reconfigure a federation server or federation server proxy, you can run the appropriate configuration wizards in AD FS 2.0. For more information see Configure a New Federation Server (https://go.microsoft.com/fwlink/?LinkId=179284) or Configure a New Federation Server Proxy (https://go.microsoft.com/fwlink/?LinkId=215238).
Check for AD FS-related events
Before you make configuration changes to enable trace logging or use tools for viewing traces, use Event Viewer to verify that AD FS 2.0–related events are appearing in application logs. For more information about setting up AD FS 2.0 event logging, see Configuring Computers for Troubleshooting AD FS 2.0.
Verify network connectivity
In most AD FS 2.0 deployments, the first thing to check when you isolate a service outage is to verify that network connectivity exists. To investigate network connectivity, it is best to start at end of the network path in a distributed application (typically, the one client computer where the outage was first diagnosed or reported) and test connectivity to itself and its local subnet first. After you establish that the client computer has local network connectivity, verify connectivity from the originating (client) network to all internetworks that are required as part of your deployment.
For example, suppose two companies, Contoso and Fabrikam, have established a relationship using federated trust. Contoso hosts a Web site in its network that a Fabrikam client computer cannot currently access using this trust relationship. To verify the network connectivity across all required network segments, it might be necessary to verify connectivity in a progressive set of diagnostic tests that trace the network path from end to end, using tools such as Ping.exe, Tracert.exe, or Nslookup.exe:
Use tools such as ipconfig /all at the Fabrikam client computer to verify that the client computer has a valid IP address configuration and connectivity to its local network, including any default gateway or Domain Name System (DNS) server that it is configured to use.
Verify that the Fabrikam client computer has valid DNS name resolution configuration and that it can use ping to verify that it can reach its intended DNS server. Also, you might have to use nslookup to verify that the DNS servers that are configured for the use of the Fabrikam client are able to resolve Contoso domain names, such as the domain name for the Contoso Web server.
Verify that the Fabrikam client computer can access its router or default gateway.
Verify that any other critical network segments are reachable and that they remain linked along the network route between the local Fabrikam network and the remote Contoso network.
For more information about using tools and processes to verify network connectivity, see the support documentation that is applicable to the operating systems in your deployment. For example, for troubleshooting network issues in a range of Windows-based systems, see article 169790 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=184929). For troubleshooting networking issues that are specific to Windows XP workstation computing, see article 314067 (https://go.microsoft.com/fwlink/?LinkId=184930) and article 325487 (https://go.microsoft.com/fwlink/?LinkID=64268) in the Microsoft Knowledge Base.
Verify router, firewall, and HTTP proxy configurations
In addition to verifying network connectivity, you may also have to verify that any routers, firewalls, or HTTP proxies in your network (or any routers, firewalls, or HTTP proxies that your federation partner is using) have been configured properly to support Web applications and protocols required with AD FS 2.0. For example, Web applications can require both TCP port exceptions to be enabled for HTTP and HTTPS traffic using Secure Sockets Layer (SSL). To ensure that the exceptions are configured appropriately, you may have to verify that the default TCP port numbers (80 for HTTP and 443 for HTTPS), which typically allow Web traffic, are in use. Also, check to see whether alternate TCP port numbers have been configured in any part of the network route between the client computer and all server computers that are involved. If alternate TCP port numbers are configured for Web application protocols, you may have to update your AD FS 2.0 deployment so that federation server and federation server proxy computers can support the alternate TCP ports. For more information about how to create an alternate TCP/IP configuration with AD FS 2.0, see Configure a Computer for the Federation Server Proxy Role (https://go.microsoft.com/fwlink/?LinkID=182471).
For non-Microsoft router and firewall systems, refer to the product documentation or support personnel for more information about enabling router and firewall settings on all application pathways for your federated application. For more information about troubleshooting Windows Firewall and Advanced Security, see Windows Firewall with Advanced Security Troubleshooting Guide: Diagnostics and Tools (https://go.microsoft.com/fwlink/?LinkId=184934)
Verify that HTTP proxy settings are correctly configured
AD FS 2.0 uses HTTP proxy settings in the following ways:
Proxy local area network (LAN) settings that are configured in Internet Explorer are used for completing administrative tasks that use the AD FS 2.0 user interface (UI), such as the AD FS 2.0 Management snap-in in Microsoft Management Console (MMC) or AD FS 2.0 cmdlets with Windows PowerShell.
In network operations, settings that are applied with the WinHTTP Proxy Configuration Utility (Proxycfg.exe) can enable network operations for AD FS 2.0 if the proxy service is used to forward HTTP or HTTPS traffic in your deployment.
If you are working with AD FS 2.0 UI tools to manage the Federation Service, first ensure that your Internet Explorer proxy settings are correct. If the Federation Service is reporting that it cannot complete a network operation while performing a regular scheduled task, WinHTTP proxy settings for the computer must be updated and configured correctly.
For information about updating your LAN proxy settings in Internet Explorer, see Change proxy settings in Internet Explorer (https://go.microsoft.com/fwlink/?LinkId=184937). For more information about setting WinHTTP proxy settings, see Using the WinHTTP Proxy Configuration Utility (https://go.microsoft.com/fwlink/?LinkId=184939).
Validate certificates that the Federation Service uses
AD FS 2.0 uses certificates for issuing and receiving tokens, publishing federation metadata, communicating through SSL, or issuing Information Cards. Some basic verification tasks that you can make to ensure that you have valid certificates configured for these purposes include the following:
Verify that certificates that are configured for use by the Federation Service are not expired or revoked.
Verify that certificates that are configured for the Federation Service have a trusted chain to a root certification authority (CA).
Confirm that private keys for certificates that are configured on the Federation Service are accessible by the user service account for AD FS 2.0 Windows service.
For more information about certificates and their use in AD FS 2.0, see Certificates (AD FS 2.0 Product Help) (https://go.microsoft.com/fwlink/?LinkId=184942).
Verifying that certificates are not expired or revoked
To verify that certificates are not expired or revoked, you can use the AD FS 2.0 Management snap-in to browse to certificates that are configured for use with your deployment.
To verify that certificates that are configured for use with AD FS 2.0 are not expired
Open the AD FS 2.0 Management snap-in.
Click Start, point to Administrative Tools, and then click AD FS 2.0 Management.
Under AD FS 2.0\Service, click the Certificates folder.
In the details pane, review the dates in the Expiration date column for all listed certificates to ensure that they are not yet expired.
To verify that certificates that are configured for use with AD FS 2.0 are not revoked
Open the AD FS 2.0 Management snap-in.
Click Start, point to Administrative Tools, and then click AD FS 2.0 Management.
Under AD FS 2.0\Service, click the Certificates folder.
In the details pane, do the following for each listed certificate that you want to review:
On the Action menu, click View Certificate.
Click the Certificate Path tab.
In the Certificate status text box, verify that the status of the certificate is still valid.
To verify that partner certificates that are configured for use with AD FS 2.0 are not expire dor revoked
Open the AD FS 2.0 Management snap-in.
Click Start, point to Administrative Tools, and then click AD FS 2.0 Management.
Under AD FS 2.0\Trust Relationships, click the Claims Provider Trusts folder.
In the details pane, do the following for any claims provider trusts that you have configured:
Double-click the claims provider trust in the list.
In the *<CP Trust>*Properties dialog box, click the Certificates tab, and then click View.
In the Certificates dialog box, on the General tab, you can verify the dates for which the certificate is valid. Use this information to confirm that the certificate has not expired. Click the Certification Path tab, and review the Certificate status to confirm whether the certificate is valid or has been revoked.
If you are using encryption with this partner trust, click the Encryption tab, and then click View.
Repeat step c.
Under AD FS 2.0\Trust Relationships, click the Relying Party Trusts folder.
In the details pane, do the following for any claims provider trusts that you have configured:
Double-click the claims provider trust in the list.
In the *<RP Trust>*Properties dialog box, click the Signature tab, and then click View.
In the Certificates dialog box, on the General tab, you can verify the dates for which the certificate is valid. Use this information to confirm that the certificate has not expired. Click the Certification Path tab, and review the Certificate status to confirm whether the certificate is valid or has been revoked.
If you are using encryption with this partner trust, click the Encryption tab, and then click View.
Repeat step c.
Verify that the certificates have a trusted chain to their root CA
The Windows operating system performs verification of the certificate path for each certificate automatically. To determine whether a certificate is trusted or not, use the following procedure to check its status.
To verify that the certificates have a trusted chain to their root CA
Open the AD FS 2.0 Management snap-in.
Click Start, point to Administrative Tools, and then click AD FS 2.0 Management.
Under AD FS 2.0\Service, click the Certificates folder.
In the details pane, do the following for each listed certificate that you want to review:
On the Action menu, click View Certificate.
Click the Certificate Path tab.
In the Certificate path text box, verify that the status of the certificate is trusted.
For more information, see Certification Authority Trust Model (https://go.microsoft.com/fwlink/?LinkId=184945).
Confirm that private keys for certificates are accessible by the AD FS 2.0 service user account
So that the certificates that are configured for use with AD FS 2.0 can operate properly, the AD FS 2.0 service user account must be given permissions to access and manage the private keys for any certificates on the server. To confirm that permissions are configured correctly, use the following procedure.
To confirm that private keys for certificates are accessible by the AD FS 2.0 service user account
Open MMC on the federation server computer.
On the Start menu, click Run, type mmc, and then press ENTER.
Add the Certificates snap-in to the console.
On the File menu, click Add/Remove Snap-In.
In the Add or Remove Snap-in dialog box, click Certificates in the list, and then click Add.
In the Certificates snap-in dialog box, click Service user, and then click Next.
In Select Computer, confirm that Local computer is selected, and then click Next.
In the console tree, navigate to the following node in the console tree: Console Root\Certificates (Local Computer)\Personal\Certificates.
In the details pane, in the list of certificates, select the SSL certificate that is used by AD FS 2.0, configured for HTTPS bindings, and bound to the Default Web Site in Internet Information Services (IIS).
On the Action menu, point to All Tasks, and then click Manage Private Keys.
In the list of security group or user names, verify that the service user, such as (NETWORK SERVICE), has Read permissions enabled in the Allow column for the certificate.
Verify that the Federation Service can connect to the AD FS configuration database
The AD FS configuration database stores any configuration data—including policy, properties, rules, and trust relationships—that is associated with the Federation Service. If the AD FS configuration database is not configured or becomes corrupted or disconnected, the AD FS 2.0 Windows service can fail outright. At that point, no further diagnosis is possible until connectivity with the AD FS configuration database is restored. Some basic checks that you can make to ensure that you have connectivity with the AD FS configuration database include the following troubleshooting tasks:
View the AD FS 2.0 connection string to verify that it is configured correctly
Update the AD FS 2.0 database connection string as needed
Confirm that the AD FS 2.0 database is operational
Test that the AD FS 2.0 database connection string works properly
Viewing the AD FS 2.0 database connection string
Configuration data for AD FS 2.0 can be stored in either the Windows Internal Database or a remote Microsoft SQL Server® database. To view the connection string that is used to open a client connection with the AD FS configuration database, you can use the following procedure.
To view the current AD FS configuration database connection string
On the federation server computer, open a Windows PowerShell prompt.
On the Start menu, point to All Programs, expand the Windows PowerShell 1.0 folder, and then click Windows PowerShell. prompt.
At the Windows PowerShell command prompt, type the following command, and then press ENTER:
Get-WmiObject -class SecurityTokenService -namespace root/ADFS | select-object ConfigurationDatabaseConnectionStringThe following is an example of the output that you might expect to see, which indicates the current configuration database connection string:
ConfigurationDatabaseConnectionString ------------------------------------- Data Source=\\.\pipe\mssql$microsoft##ssee\sql\query;Initial Catalog=AdfsConfiguration;Integrated Security=True
Modify the connection string for the AD FS configuration database
If, for any reason, the connection string that is used to connect to the AD FS 2.0 configuration database has to be modified, you can use the following procedure to modify it.
To modify the connection string for the AD FS configuration database
On the federation server computer, open a Windows PowerShell prompt.
On the Start menu, point to All Programs, expand the Windows PowerShell 1.0 folder, and then click Windows PowerShell.
At the Windows PowerShell command prompt, type the following command, and then press ENTER.
$a = Get-WmiObject -class SecurityTokenService -namespace root/ADFS $a.ConfigurationDatabaseConnectionString = <replace with desired connection string> $a.Put()
Confirm that the AD FS configuration database is operational
The simplest way to confirm that the AD FS configuration database is operational is to open the AD FS 2.0 Management snap-in and connect to the Federation Service. If the MMC UI for AD FS 2.0 appears and it displays various configuration settings, such as claim descriptions and any rules or trust relationships that were previously configured, the configuration database is probably operating normally. Another way that you can test the AD FS configuration database is to load the AD FS 2.0 snap-in for Windows PowerShell and try running a cmdlet. AD FS 2.0 cmdlets work only if the configuration database is operating normally.
Test whether the AD FS configuration database connection string is working
If you are still experiencing issues with connecting to the AD FS configuration database, you may want to use additional support tools to test the configured connection string to isolate connectivity problems if the issue is within the connection string itself. For SQL Server installations, you can download and install the Microsoft SQL Server Native Client and SQL Server command line tools that are available in the Microsoft SQL Server 2008 Feature Pack, April 2009 (https://go.microsoft.com/fwlink/?LinkID=184954) page. To test a connection to a SQL Server database, use the SQLCMD tool in the component download packages on this page.
Verify that the AD FS 2.0 service user account has permission to access the configuration store
In some cases, network throughput to the AD FS configuration database might be intact, but connectivity fails because of account permissions. To check for this possibility, you can use SQL Server Management tools to verify permissions on the AdfsConfiguration database.
For example, if you are using the Windows Internal Database as your AD FS 2.0 configuration database, you can download and install SQL Server 2008 Management Studio Express (https://go.microsoft.com/fwlink/?LinkID=164279) to access and view Structured Query Language (SQL) permissions on this database. Assuming that you configured your AD FS 2.0 to use the default service user account of NTAUTHORITY\Network Service, you can use the following procedure and this downloadable management tool to review the required permissions.
To verify that the AD FS 2.0 service user account has permissions to access the AD FS configuration database
At the federation server computer, log on using Domain Administrator credentials.
If you have not done so yet, download and install the SQL Server 2008 Management Studio Express package.
Open SQL Server Management Studio Express as an administrator.
On the Start menu, click All Programs, expand Microsoft SQL Server, right-click SQL Server Management Studio, and then click Run as Administrator.
Update the server name information to use the correct AD FS 2.0 database connection string.
For example, where the local Windows Internal Database installation is being used with AD FS 2.0, in the Connect to Server dialog box, for Server name, enter the following, and then click Connect:
\\.\pipe\mssql$microsoft##ssee\sql\query
When the snap-in is connected to the Windows Internal Database, in the console tree, navigate to the following node: applicable WID server**\Databases\AdfsConfiguration**, right-click it, and then click Properties.
In the Database Properties - AdfsConfiguration dialog box, click Permissions.
Note that the service user account (in this example, NTAUTHORITY\Network Service) is given User role permissions.
Navigate to the AdfsConfiguration\Tables node.
Right-click one of the tables that starts with IdentityServerPolicy.tablename, and then click Properties.
In the applicable table properties, click Permissions.
Click View schema permissions to open the Schema Properties dialog box, and then click General.
Verify that Schema name is set to IdentityServerPolicy and that Schema owner is the same as the AD FS 2.0 service user account (in this example, NTAUTHORITY\NETWORK SERVICE).
Click Cancel, and then close the tool.
Verify that the IIS (Web Server) server role is configured properly for AD FS 2.0
To support a number of its Web-based features and functionality, AD FS 2.0 uses a close partnership with the Web server role technology of IIS. When you install AD FS 2.0, it uses IIS configuration in the following ways:
AD FS 2.0 uses the HTTPS and SSL transport services of IIS to secure traffic. This requires that the same certificate that is configured in SSL bindings for IIS be used by AD FS 2.0 as the certificate that is used for signing and issuing tokens and Information Cards that the Federation Service issues to its clients.
AD FS 2.0 creates a new application pool within IIS to service Web-based applications.
You can use AD FS 2.0 to create a new Web site for issuing Information Cards through IIS.
To ensure that IIS configuration is maintained for supporting these role partner dependencies, you may find it helpful to perform the following system checks on your IIS installation that is associated with your AD FS 2.0 installation:
Verify that an appropriate SSL certificate is configured and bound in the HTTPS binding to the Default Web Site.
Verify that the TCP port number that the Federation Service uses is configured correctly.
Determine whether AD FS sites are missing in IIS or whether they are enabled.
Determine whether the AD FS application pool is missing or is not running in IIS, and verify its identity
Determine whether the AD FS 2.0 subfolder (\adfs) is missing under the IIS install root (%systemdrive%\Inetpub).
The following sections describe how to accomplish these AD FS 2.0-related configuration checks in your IIS configuration.
Verify that a HTTPS binding exists with an appropriate certificate configured
For AD FS 2.0 to operate properly, IIS must be configured with a valid certificate for SSL service bindings. This certificate must be issued with a Subject name that contains a fully qualified DNS domain name. This might require some reconfiguring of your IIS installation before you can complete AD FS 2.0 configuration.
To verify that a HTTPS binding exists with an appropriate certificate configured
Open the Internet Information Services (IIS) Manager snap-in on the server where AD FS 2.0 is installed.
On the Start menu, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the Connections pane, select the local IIS server node.
In the details pane, click Server Certificates.
Review the listed certificates to verify that there is a certificate for which the Issued by column indicates a fully qualified DNS domain name. If there is no qualifying certificate, as a temporary workaround you can create a self-signed certificate for this purpose. For more information, see Create a Self-Signed Server Certificate in IIS 7 (https://go.microsoft.com/fwlink/?LinkId=184970). After you identify the certificate to use or after you create it, ensure that it is configured for SSL bindings for the Default Web Site.
In the Connections pane, expand the applicable IIS (Web) server node, expand the Sites node, and then click Default Web Site.
On the Actions menu, click Bindings.
In the Site Bindings dialog box, select https in the list, and then click Edit.
In the Edit Site Bindings dialog box, in the SSL certificate drop-down list box, select the certificate that was verified or created in step 3, and then click OK.
In addition to verifying that the certificate has a Subject name that is a valid DNS host name and that meets the AD FS 2.0 configuration requirements, verify that it has not expired or been revoked.
Verify that the TCP port number that the Federation Service uses is configured correctly in both AD FS 2.0 and IIS
In some cases, alternate TCP port numbers might be used in your network environment for Web-based services. For example, you might choose to use alternate TCP port numbers for HTTP and HTTPS traffic with your AD FS 2.0 deployment. For more information about how to view or modify the TCP port numbers that AD FS 2.0 uses, see Configure a Computer for the Federation Server Proxy Role (https://go.microsoft.com/fwlink/?LinkId=182471). If AD FS 2.0 uses alternate port numbers, the same alterations should be made to the default TCP port numbers in your supporting IIS configuration. To verify TCP port numbers in IIS bindings for HTTP and HTTPS, see the following procedure.
To verify the TCP port numbers in HTTP and HTTPS bindings
On the computer that hosts federation server, click Start, point to Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the Internet Information Services (IIS) Manager dialog box, in the Connections pane, expand your computer name, expand Sites, and then click Default Web Site.
In the Actions pane, under Edit Site, click Bindings.
In the Site Bindings dialog box, select https in the list, and then click Edit.
In the Edit Site Binding dialog box, in the Port box, verify that the TCP port number is correct for both your IIS and AD FS 2.0 installations.
Repeat steps 4 and 5 for http as needed.
Determine whether AD FS 2.0 sites are missing in IIS or whether they have been enabled
The AD FS 2.0 sites are created automatically under the Default Web Site in IIS when AD FS 2.0 is installed and configured. If you see errors indicating that AD FS 2.0 endpoints do not exist, check to see whether these sites appear in the IIS configuration.
To verify that AD FS 2.0 sites exist under the IIS Default Web Site
In the Internet Information Services (IIS) Manager dialog box, in the Connections pane, expand your computer name, expand Sites, and then expand Default Web Site.
Verify that the adfs node exists, and then expand it to verify that the card and ls nodes appear as well.
Verify the AD FS 2.0 application pool configuration
When AD FS 2.0 is installed, it creates its own application pool in the IIS configuration. Application pools make it possible to run Web applications in isolation by allowing you to group and run each application pool in its own worker process.
To ensure that AD FS 2.0 operates correctly, confirm that the AD FS 2.0 application pool has been created. Also, check that the application pool is started and running under the identity of the AD FS 2.0 service user account.
To verify the AD FS 2.0 application pool configuration
In the Internet Information Services (IIS) Manager dialog box, in the Connections pane, expand the Web server node, and then click Application Pools.
Verify that the application pool (ADFSAppPool) exists and that it is started and running under the correct AD FS 2.0 service account (such as Network Service).
Confirm that the AD FS 2.0 subfolder exists under the IIS virtual root folder
In addition to verifying that the AD FS 2.0 sites are configured in IIS, you should also confirm that the \adfs subfolder and its contents exist under the IIS virtual root directory (%SystemDrive%\inetpub). This folder should also contain the \adfs\card and \adfs\ls subfolders and their site contents.
Verify connection to the AD FS 2.0 attribute store
Attribute stores are pluggable modules that AD FS 2.0 can query to retrieve claim values. AD FS 2.0 provides built-in support for both Active Directory and SQL Server as an attribute store database. AD FS 2.0 also provides extensible support so that you can use your own custom attribute store database.
To verify connection to the AD FS 2.0 attribute store database, use diagnostic or management tools that are appropriate to the database platform that you are working with. For example, with Active Directory databases, you can use the dcdiag command-to test connectivity to your domain controllers. For more information about the dcdiag command, see Dcdiag (https://go.microsoft.com/fwlink/?LinkID=133110).
If you are using SQL Server, use a similar tool, such as sqlcmd, to test connectivity. For more information, see Tutorial: sqlcmd Utility (https://go.microsoft.com/fwlink/?LinkId=185034).
Confirm that the service user account SPN is registered in ActiveDirectory for Windows Integrated authentication
To ensure that Windows Integrated authentication works correctly for servicing AD FS 2.0 Web-based requests that use IIS, you may also have to verify that the Service Principal Name (SPN) attribute (servicePrincipalName) for the AD FS 2.0 service user account is registered correctly in Active Directory.
To verify the securityPrincipalName (SPN) settings that apply to AD FS 2.0, you can use the Setspn.exe command-line tool. This command-line tool is provided as part of Windows Server 2008. You can use Setspn.exe to read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. For more information, see Setspn (https://go.microsoft.com/fwlink/?LinkID=143939).
Note
It is not usually necessary to modify SPNs. They are set up by a computer when it joins a domain and when services are installed on the computer. Also, if the AD FS 2.0 Windows service runs as Local System or under the Network Service, you usually do not have to set an SPN explicitly for it. Most common SPN service classes automatically map to the HOST/ SPN, which is in turn automatically generated for each computer account.
If the AD FS 2.0 service user account is a user-created account and not Local System or Network Service, you can list the SPNs that are registered for this account by using the setspn -ldomain\username command option. For example, if the service user account is CONTOSO\AdfsSrvUser, you run the following command:
setspn -l contoso\adfssrvuser
If no registered SPNs appear for the AD FS 2.0 service user account, you can register the appropriate SPN by using the setspn -a command option. For more information about this issue, see Service Logons Fail Due to Incorrectly Set SPNs (https://go.microsoft.com/fwlink/?LinkId=185035).
Verify that AD FS 2.0 metadata endpoints are accessible
To establish that AD FS 2.0service operations are working correctly, you should also check that the following metadata endpoints are reachable and accessible from a Web client:
https:// hostname/adfs/services/trust/mex
https:// hostname/FederationMetadata/2007-06/FederationMetadata.xml
When these endpoint URLs are accessed from a Web browser, both URLs should return the appropriate metadata service descriptions.