SQL Server will register its own [...]]]> I recently had a SQL server where the SQL instance had a different name than the hostname. Not having rights to connect to SQL, I wasn’t aware of that. So, I registered the SPNs as they should have been registered, and it was still falling back to NTLM (see: failing).

SQL Server will register its own SPNs at startup – assuming the service account has rights to set its own SPN. To give the service account rights to self-register SPN (assuming you’re using a domain service account and not Network Service/Local System), you need to grant the service account rights to “Write Public Information” on itself in Active Directory.

1) Launch Active Directory Users and Computers
2) Find your service account and hit the Security tab
3) Select “SELF” in the “Groups or user names” listbox
4) Find “Write public information” in the “Permissions for SELF” listbox and check “Allow”
5) Click OK

After, you’ll need to restart SQL Server for the SPN to register. Use setspn -l domain\account to verify that the account has properly registered.

If you do happen to be using Network Service or Local System, shame on you. That said you’ll just need to verify on the computer account in AD that SELF has “Validated write to service principal name” set to Allow. But, seriously, stop using Network Service or Local System (ESPECIALLY THAT!) and start using a domain account…or at the very least a local account.

There were two hops here. From the user -> IIS server and from IIS Server -> SQL Server, but the application in IIS would impersonate the user [...]]]> Recently, some of our developers were writing an app that required impersonation from the web service, as the user, to the database. Admittedly, Kerberos isn’t one of my strong points.

There were two hops here. From the user -> IIS server and from IIS Server -> SQL Server, but the application in IIS would impersonate the user when authenticating with the SQL server.

So, the idea here is that from the user to the IIS server, we know Kerberos will work. The user passes its ticket to the web service. Nothing unusual. From there, the web app, running as a custom app pool ID, needs to pretend (delegate) to be the user when it authenticates to the SQL server.

There are a few requirements.
1) Your application in IIS should be running under a custom identity – domain\MyAppService
2) SQL Server needs to be running under a domain service account – domain\MySQLService
3) IIS needs to use Negotiate instead of NTLM for that application. It should do this by default, then fall back to NTLM. For whatever reason, my app was using NTLM. IIS should also have Windows Authentication enabled.
4) Change your connection string to impersonate the site user

Step 1 – Set the SPN on your app pool ID for the site, for the hostname and FQDN.
setspn -a http/mysite domain\MyAppService
setspn -a http/mysite.domain.com domain\MyAppService

Step 2 – Set the SPN for the SQL service on your SQL service account – assuming you use the default SQL port
setspn -a MSSQLSvc/hostname domain\MySQLService
setspn -a MSSQLSvc/hostname.domain.com domain/MySQLService
setspn -a MSSQLSvc/hostname:1433 domain\MySQLService
setspn -a MSSQLSvc/hostname.domain.com:1433 domain/MySQLService
Restart SQL

Step 3 – In Active Directory Users and Computers, find the service account, click the delegation tab, and trust it for delegation. You can set it for delegation to anywhere, or constrained delegation to the SPNs you’ll set for the SQL service account.

Step 4 – Force your site or application to use Negotiate. This won’t work with NTLM, so we’ll remove it. (Note: This is for IIS7/7.5)
- Find and open your applicationHost.config. It’s probably under c:\windows\system32\inetsrv\config. You can also set this in the system.webServer section of the web.config for the application.

- Scroll to the bottom and above /configuration copy this in:
[xml]

If you get a 500 error after adding the above XML, it’s probably because Negotiate is already added elsewhere. Just remove the line that says add value=”Negotiate” and leave the remove NTLM line.

Reference: This post was extremely helpful in solving my problem – http://blogs.technet.com/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx – in the end, I did pretty much everything in that post, and still had the IIS server passing anonymous to SQL, which is what tipped me off that it was using NTLM and not Negotiate.

 Anyway, if you’ve got a bunch of servers that you need to perform a common task on (copy files, check event logs, etc), this is handy…however, it only works if you’ve got the Managed By field set in AD. [...]]]> Here’s the script I metioned a few days ago. I wrote this a while back (Pre-RC0, I think).

 Anyway, if you’ve got a bunch of servers that you need to perform a common task on (copy files, check event logs, etc), this is handy…however, it only works if you’ve got the Managed By field set in AD. Otherwise, you’re SOL. First, it makes sure the account name given exists in AD, then searches AD for and computer objects managed by that account. It uses write-output to return the list of servers. It outputs strings, not objects, since that’s all I needed out of it.

Syntax is: .\get-servernames.ps1 <samaccountname>
[powershell]
$root = new-object DirectoryServices.DirectoryEntry ‘LDAP://dc=foo,dc=bar,dc=com’
$searcher = new-object DirectoryServices.DirectorySearcher
$searcher.SearchRoot = $root
$searcher.Filter = “(samaccountname=$($args[0]))”
$results = $searcher.findOne()
if ($results -eq $null) {
 write-host -fore ‘blue’ -back ‘white’ “`”$($args[0])`” not found”
 exit(1)
}
else {
 $dn = $results.GetDirectoryEntry().distinguishedname
 $searcher.Filter = “(&(samaccounttype=805306369)(managedby=$($dn)))”
 $servers = $searcher.FindAll()
  if ($($servers.count) -gt 0) {
   foreach ($server in $servers) { write-output “$($server.GetDirectoryEntry().cn)” }
 }
}
[/powershell]
As I mentioned, this is pretty handy for copying files to groups of servers, checking error logs via psloglist, doing inventory, and more.