Kerberous Authentication

Question

Hi All

I have a SQL Server 2008 R2 ENT SSRS setup. All reports and everything works when we try accessing the URLS inside server. But when we try from outside(client machines) it keeps on prompting for credentials.

There is no firewall between the client and the SSRS server and no proxy is there. The reporting databases,SSAS are also present inside the same SSRS server.

The same service account is used for SQL Database engine and Reporting services also.

MSSQLSVC/Hostname:port# setspn is done for hostname and for FQDN.This is done for SQL Server services.

but when we try to do HTTP/hostname for the service account it says it's already present. while checking this spn is set against hostname already not against service account.

The same displays when we list setspn -l hostname.

Doing setspn against hostname and service account are same?

We are getting 401 unauthorised error while browsing it from another client machine and this events are not logged while doing fiddler in SSRS server.

Thanks,
ACDBA

Answer 1

Hi @ACDBA ，

We are getting 401 unauthorised error while browsing it from another client machine and this events are not logged while doing fiddler in SSRS server.

Report servers all require the client to authenticate the user or process requesting the connection. Clients pass information to the report server through HTTP authentication requests. The report server in turn passes this information to the Windows Authentication Extension (which is the default) or to a custom security extension. If authentication fails, the report server sends an HTTP 401 Access Denied error to the client application.

If you initially set the Windows service account for the report server to NetworkService or LocalSystem in Reporting Services Configuration Manager, RSWindowsNegotiate is added to the RSReportServer.config file as the default setting. With this setting, the report server can accept requests from client applications requesting Kerberos or NTLM authentication. If Kerberos is requested and the authentication fails, the report server switches to NTLM authentication and prompts the user for credentials unless the network is configured to manage authentication transparently.

On a report server that is configured for Negotiate or Kerberos authentication, a client connection to the report server will fail if there is a Kerberos authentication error. Kerberos authentication errors are known to occur when:

• The Report Server service runs as a Windows domain user account and you did not register a Service Principal Name (SPN) for the account.
• The report server is configured with the RSWindowsNegotiate setting.
• The browser chooses Kerberos over NTLM in the authentication header in the request it sends to the report server.

You can detect the error if you enabled Kerberos logging. Another symptom of the error is that you are prompted for credentials multiple times and then see an empty browser window.

You can confirm that you are encountering a Kerberos authentication error by removing < RSWindowsNegotiate /> from your configuration file and reattempting the connection.

After you confirm the problem, you can address it in the following ways:

• Register an SPN for the Report Server service under the domain user account. For more information, see Register a Service Principal Name (SPN) for a Report Server.
• Change the service account to run under a built-in account such as Network Service. Built-in accounts map HTTP SPN to the Host SPN, which is defined when you join a computer to your network. For more information, see Configure a Service Account (Report Server Configuration Manager).
• Use NTLM. NTLM will generally work in cases where Kerberos authentication fails. To use NTLM, remove RSWindowsNegotiate from the RSReportServer.config file and verify that only RSWindowsNTLM is specified. If you choose this approach, you can continue to use a domain user account for the Report Server service even if you do not define an SPN for it.

Even if Kerberos authentication is correctly configured, any of the following conditions in your environment can cause the client to bypass Kerberos and use NTLM authentication instead:

• The Report Server service account is a domain account, but the domain administrator hasn't registered a service principal name (SPN) for the service account.
• The connection request is sent to a local report server or an IP address rather than a host header or server name.
• The firewall blocks the Kerberos authentication port (88/TCP).
• Kerberos isn't enabled in the report server's OS.
• The client is Microsoft Internet Explorer (IE) and the connection request uses a Fully Qualified Domain Name (FQDN) or localhost rather than the report server's network name.

Best Regards,
Joy

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thanks you so much Joyzhao-MSFT.. This is a lot of information.I shall got though it.

just now I see the issue disappears when we run fiddler in the same client machine.. if we stop capturing fiddler SSRS stops working.