There were two hops here. From the user -> IIS server and from IIS Server -> SQL Server, but the application in IIS would [...]]]> 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:

   <location path="SitePath">
        <system.webServer>
            <security>
                <authentication>
                    <windowsAuthentication>
                        <providers>
                            <add value="Negotiate" />
                            <remove value="NTLM" />
                        </providers>
                    </windowsAuthentication>
                </authentication>
            </security>
        </system.webServer>
    </location>

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.

A developer was using AJAXControlToolkit in an application. Not a big deal. Except that it kept throwing that damn exception. You know the one:

Server Error in ” Application. Security Exception Description: The application attempted to perform an operation not allowed by the security policy. To grant this application [...]]]> Here’s a quick one…

A developer was using AJAXControlToolkit in an application. Not a big deal. Except that it kept throwing that damn exception. You know the one:


Server Error in ” Application.
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application’s trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type ‘System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.


I know what you’re going to say, but I prefer to not use caspol.exe to set the trust.

There were several other sites on the server using the toolkit that worked fine, without using caspol to set full trust.

The difference? Those other applications were compiling the AJAX DLL when the apps themselves were compiled. The developer in this case had just copied the DLL from the toolkit download and added the reference to her code.

I copied the DLL from one of the sites that I knew worked, and it magically started working. Copy her version of the DLL back, and it failed again (after IISReset).

I don’t really know how this happened, but if the DLL was referenced in the VS project, it should have been built with the rest of the app and then deployed with full trust…

So, if you’re running into this and you’re building the code yourself, make sure that the AjaxControlToolkit.dll is building with the rest of your application (the timestamp should be the same) as the other DLLs that were modified. Don’t just drop it in afterwards…it won’t work…

In Active Directory, we set the “Managed By” field on all of the servers we manage to our primary, non-admin account. This makes it easy for people to find out who manages what [...]]]> I should have posted this a long, long time ago…but forgot. Until I got a comment from dvdor about it.

In Active Directory, we set the “Managed By” field on all of the servers we manage to our primary, non-admin account. This makes it easy for people to find out who manages what servers. It also makes it easy to do batch upgrades/file copies/whatever to your own servers.

This script, get-servernames.ps1, has a single parameter. -username. It just returns a text list of your servers…no objects or anything. I didn’t see the need, since all I wanted was the names.

Syntax: .\get-servernames.ps1 -username tmoser

Summary: Will take in your username (samaccountname) and first search AD for it. If found, it will search AD for all computer objects that have your account in the “Managed By” field. Those are returned in a list.

Uses: Things like: .\get-servernames.ps1 -username tmoser | foreach { copy-item C:\temp\somefile.txt \\$_\c$\temp\somefile.txt }

You can use it for error log checking, copying files, running remote psexec commands…anything, really.

param($username)

$root = new-object DirectoryServices.DirectoryEntry 'LDAP://dc=yourdomain,dc=com'
$searcher = new-object DirectoryServices.DirectorySearcher
$searcher.SearchRoot = $root
$searcher.Filter = "(samaccountname=$username)"

$results = $searcher.findOne()

if ($results -eq $null) {
	write-host -fore 'blue' -back 'white' "`"$($username)`" 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)" }
	}
}

 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 [...]]]> 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>

$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)" }
 }
}

As I mentioned, this is pretty handy for copying files to groups of servers, checking error logs via psloglist, doing inventory, and more.