While I was setting up one of my demos for SQL PASS, I starting hitting 401.1 errors. I was setting up a SharePoint Intergrated setup with Reporting Services.
I knew I had a distributed environment, so I accounted for my Kerberos configuration. I lined up my SPNs and made sure my accounts were trusted for delegation. So, I was a little surprised when I was hitting a 401.1 error when trying to run a report or create a new Datasource through the SharePoint RS Library.
I was using a Domain user account for my RS Service. The key was that I configured the Service account to use the Domain user before it had started up at all. Out of the gate, I was using the Domain user account and never touched the Network Service account. This was done by way of specifying the Domain user account within the SQL 2008 Setup wizard.
An interested side affect to doing this is that we don't add RSWindowsNegotiate to the rsreportserver.config file. All that was listed was RSWindowsNTLM. Well, that explained the 401.1 error. After manually adding in RSWindowsNegotiate, everything worked like a champ.
I found that we will add RSWindowsNegotiate when we use the Network Service account. Because I hadn't used that account, the setting was never populated to the config file.
The report server accepts either Kerberos or NTLM security tokens. This is the default setting when the report server is running in native mode and the service account is Network Service. This setting is omitted when the report server is running in native mode and the service account is configured as a domain user account.
If a domain account is configured for the Report Server Service account and a Service Principle Name (SPN) is not configured for the report server, this setting might prevent users from logging on to the server.
Of note, once the setting is there, we will not remove it if you change from the Network Service account to a Domain User account.
Adam W. Saxton | Microsoft SQL Server Escalation Services