Jason Crider (12/9/2011)

---

Greg, I assume are talking about this whitepaper for Sharepoint 2010?

Haven't heard of the KerbBuddy tool.

bruce.l.pettus (12/9/2011)

---

I'm in the process of implementing a solution so I'm not entirely confident I'm correct; however, I wanted to point out an issue with the SPN comment.

To my knowledge, the ability to write an SPN to the AD requires domain admin permissions and I'm fairly sure the AD admins will have a problem with this. My solution (still in progress) is to...

1. Specify a static IP port for the SQL instance(s).
2. Request creation of SPNs for servers involved in the double-hop connection.
3. Request the SQL service accounts be granted "trust for delegation" permissions.

If you change the IP port of the SQL instance you'll need to request the SPN be updated to match the new IP port.

ALZDBA (12/9/2011)

---

Nice article. And what's most important .... It will help people diagnose and solve this kind of issues !

With fixed ports, you can also register the spn yourself ( after install of the instance ) using this
DOS script

echo off
rem http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
rem To create an SPN for SQL Server, enter the following code at a command prompt:
rem setspn -A MSSQLSvc/Host:port serviceaccount
rem For example:
rem setspn -A MSSQLSvc/server1.redmond.microsoft.com sqlaccount 
echo on


rem C:\Program Files\Support Tools\setspn -A MSSQLSvc/yourservername.yourdomain.yourdomainsuffix:2388 DOMAIN\SERVICEACCOUNT

Greg Edwards-268690 (12/9/2011)

---

Any domain admin should recognize kerberos as a much more secure method than allow anonymous.
And far more secure than using basic on a web site too.
The service accounts and the machines need to be allowed to delegate.
And there is also contrained delegation, which is much more specific.
I have never had any push back in my company on using Kerberos.
And the domain admins were thankful for my help in setting up and troubleshooting.

SpringTownDBA (12/9/2011)

---

Hey Kenneth,

Thanks for your reply. I apologize if my original post seemed harsh, I've fought some extremely frustrating battles with kerberos in the past and want others to avoid my pain and anguish.

As for automatic spn registration, there is a recommendation against using automatic registration on a cluster:
http://blogs.msdn.com/b/psssql/archive/2010/03/09/what-spn-do-i-use-and-how-does-it-get-there.aspx (which I just found about 15 minutes ago, the rationale is in the comments)

My original thoughts on manual being better are due to consistency with other Microsoft products that don't auto-register themselves (SSRS, SSAS, Sharepoint 2010 components, etc), and explicit registration forcing DBA's and Sys Admins to become more familiar with kerberos configuration. Unfortunately, the easy way to get spn's registered is to run sql as a domain admin account. The second easiest is to ask a system administrator to run "setspn.exe ...". The third is to grant the specific permissions to the service account (as you mentioned).

As for constrained vs unconstrained,the current guidance from MS for Sharepoint configuration strongly pushes constrained delegation. Because constrained -> unconstrained doesn't work (and is very hard to trace as the culprit), I would only recommend configuring constrained delegation on your sql service accounts. I believe that the guidance from MS recommending unconstrained delegation for SqlServer hasn't been revisited in several years (could be wrong though)

If you wrote a follow-up article on configuring kerberos for SSRS and/or SSAS, that might be helpful as well.

I hate seeing people avoid kerberos because it's too hard to get configured or they don't know how to troubleshoot it.

thanks!

SpringTownDBA (12/9/2011)

---

Hey Kenneth,

Thanks for your reply. I apologize if my original post seemed harsh, I've fought some extremely frustrating battles with kerberos in the past and want others to avoid my pain and anguish.

As for automatic spn registration, there is a recommendation against using automatic registration on a cluster:
http://blogs.msdn.com/b/psssql/archive/2010/03/09/what-spn-do-i-use-and-how-does-it-get-there.aspx (which I just found about 15 minutes ago, the rationale is in the comments)

My original thoughts on manual being better are due to consistency with other Microsoft products that don't auto-register themselves (SSRS, SSAS, Sharepoint 2010 components, etc), and explicit registration forcing DBA's and Sys Admins to become more familiar with kerberos configuration. Unfortunately, the easy way to get spn's registered is to run sql as a domain admin account. The second easiest is to ask a system administrator to run "setspn.exe ...". The third is to grant the specific permissions to the service account (as you mentioned).

As for constrained vs unconstrained,the current guidance from MS for Sharepoint configuration strongly pushes constrained delegation. Because constrained -> unconstrained doesn't work (and is very hard to trace as the culprit), I would only recommend configuring constrained delegation on your sql service accounts. I believe that the guidance from MS recommending unconstrained delegation for SqlServer hasn't been revisited in several years (could be wrong though)

If you wrote a follow-up article on configuring kerberos for SSRS and/or SSAS, that might be helpful as well.

I hate seeing people avoid kerberos because it's too hard to get configured or they don't know how to troubleshoot it.

Greg Edwards-268690 (12/9/2011)

---

So you are a domain admin?