If you are working within a mostly Windows environment (i.e. Windows Server 2k3, a domain controller, Active Directory, etc.) one in particular is that you can use impersonation through .NET with a split web server and database server. Using the older NTLM method, you cannot do a "double-hop".
Let's look at an example:
- You have a web server (WEB1)
- You have a database server on a separate machine (DB1)
- You have a user access your website (USER1)
USER1 hits a page that displays a list of orders. Your WEB1 server has to query DB1 for this info to display on the page. You want to constrain what orders are seen based on the user's credentials and access rights. Thus, you set up active directory groups and assign users accordingly. On your database you give the different groups different security (GROUP1 might have select only and GROUP2 might get select, insert, and update, for example).
NTLM doesn't support the double-hop necessary to do this. WEB1 has to send USER1's credentials to DB1 (otherwise WEB1 must log into DB1 with a known dedicated user id and password hardcoded into the web.config for example that usually has to have full access to support all possible user roles). You can imagine this could be a security hazard should WEB1 be compromised, so you can't do it, otherwise anyone who gains control of WEB1 (via sql injection perhaps) could do anything the dedicated user account could or impersonate whomever they want. Kerberos, through delegation on Windows Server, supports doing this second hop by keeping the encrypted credential key from your domain server intact and passed along, as well as verified that this is allowed (on both ends, see below for setting this up on your servers because it MUST be EXPLICITLY allowed).
It's very useful to do this when developing intranet web apps that have a database back-end (which is 99% of the time the case, right?) and you want to control authorization and authentication through Windows Integrated Security. Kerberos is really your only choice unless your web server and database server are on the same machine, which means there is no transferring of credentials and no impersonation necessary.
See also: