Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


I am trying to configure Kerberos in the domain for double-hop authentication. So here are the machines and their respective roles:

  • client01: Windows 7 as client
  • dc01: Windows Server 2008 R2 as domain controller and dns
  • server01: Windows Server 2008 R2 as reporting server (native mode)
  • server02: Windows Server 2008 R2 as SQL Server database engine

I want my client01 to connect to server01 and configure a data source that is located on server02 using Intergrated Security. So as NTLM cannot push credentials that far, I need to setup Kerberos to enable double-hop authentication. The reporting service is runned by the Network Service service account and is configured only with the RSWindowsNegotiate options for authentication.


I cannot get to pass my client01 credential to server02 when configuring the data source on server01. Therefore I get the error:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

So I went on dc01 and delegated full trust for any service to server01 but it not fixed the problem. I want to notice that I did not configured any SPNs for server01 because Reporting Service is runned by Network Service and from what I read on the Internet, when Reporting Services is going up with Network Service, SPNs are automatically registered. My problem is that even if that I want to configure SPNs manually, I do not know where I have to set them up. On dc01 or on server01?

So I went a bit further on the issue and tried to trace this problem. From my understanding of Kerberos, this is what should happen on the network when I try to connect the data source:

client01 ---- AS_REQ ---> dc01
         <--- AS_REP ---- 

client01 ---- TGS_REQ ---> dc01
         <--- TGS_REP ----

client01 ---- AP_REQ ---> server01
         <--- AP_REP ----

server01 ---- TGS_REQ ---> dc01
         <--- TGS_REP ----

server01 ---- AP_REQ ---> server02
         <--- AP_REP ----

So captured my local network with Wireshark, but whenever I try to configure my data source from client01 on server01 to pass my credentials to server02, my client never sends a AS_REQ or TGS_REQ to the KDC on dc01.


So does anyone can tell me if I should configure the SPNs and on which machine does it have to be configured?

Also why client01 never request for a TGT or a TGS to my KDC. Do you think there is something going wrong with the DC role of dc01?

share|improve this question
up vote 1 down vote accepted

SPNs should be configured on the computer or user object representing the identity of the service. if the service in question on server01 is running under network service, then you would ensure there are correct SPNs configured on the computer account representing server01. You can check it by running "setspn -l server01". The command itself can be run from anywhere as it will talk to a DC and examine the serviceprincipalname LDAP attribute of the object. So you can run it from dc01 or server01 or anywhere else, provided you have the setspn.exe binary. You can see all syntax by running "setspn /?"

If they aren't configured (as verified by above command) you would add them using the same binary but with different syntax. Example syntax for the "-A" switch which adds the values by running "setspn -A http/server01 server01". The example assumes the port the service is running under is 80 or 443.

You have to be careful in ensuring the SPN isnt registered anywhere else in the AD forest as the SPN has to be unique. the "-Q" switch can check for the presence of the SPN anywhere when you do something like "setspn -F -Q http/server01".

In Wireshark or any other network tracing tool, you will only see the kerberos traffic provided that the client does not already have a cached ticket for the resource and provided that it doesnt have a negative cache indicating the SPN as unavailable. If you tried this several times and then launched Wireshark to see whats happening, its likely a negative cache is involved if the SPN is completely missing. Else if you already have a ticket cached, this will be reused and no further tickets will be requested.

Always fush dns cache on client "ipconfig /flushdns" and kerberos cache "klist purge" before doing network traces to troubleshoot. This will show name resolution traffic for KDC location and attempts to obtain a ticket if not locally cached. looks like a good resource on the SSRS side of things. For kerberos help in troubleshooting, please see the askds blog posts targetted kerberos starting with Then review and other articles as you see fit.

DC01 will issue tickets provided that the KDC service is running and it can find the relevant SPn registered in its database and provided that it is not duplicated elsewhere in the forest. The value must be unique. "setspn -x -f" can be reviewed to check if the value of interest is a duplicate in the forest.

share|improve this answer
Thank you for all these clarifications. It looks much more clearer now. Also I was not aware of the klist command, it will surely help in observing a regular Kerberos network traffic. Of course setting the SPN for server01 solved the issue and now I am able to connect to the data source on server02. The fact is that I wanted to first make it work with SQL Server, now the real challenge is to make it work with Oracle! Thanks a lot for your help ;) – Ucodia Apr 14 '12 at 13:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.