The End Result
After all the effort of authenticating both the client and the SQL Server service, SQL Server receives the same information about the client that it gets for Win2K/NT logins that don't use Kerberos. No matter how the user authenticates, the OS creates an access token that contains the user's SID and the SIDs for all the local and domain groups the user belongs to. SQL Server then checks the list of SIDs to see whether one of them matches an entry in the master database's sysxlogins table. If a match exists, SQL Server permits access to its databases.
Permissions within the databases also operate independently of the authentication protocol the client uses to log in. For Win2K domain accounts, you still assign permissions and role memberships based on the account's SID, so once a user is logged in, nothing changes in SQL Server 2000's internal authorization structure.
The only change from SQL Server 7.0 is that in all cases, an XP/Win2K client connecting to an XP/Win2K server attempts to authenticate by using Kerberos. If that authentication fails, XP/Win2K reverts to the NTLM protocol that NT and Windows Me/9x use. Because SQL Server 2000, 7.0, and 6.5 all leave authenticating domain accounts to the OS, you can gain some of the benefits of using Kerberos just by running SQL Server on Win2K. Remember that by default, all trusted connections will authenticate with the OS before SQL Server sees the login request. Although SQL Server 7.0 and 6.5 users can't use an SPN to authenticate their identities or use delegation to connect to remote servers, they can benefit from the increased security of the Kerberos protocol over NTLM and from the better management tools that Win2K offers. IPSec is also easier to set up with Win2K than NT, so even if you don't move to SQL Server 2000, consider upgrading from NT to Win2K.
Running SQL Server 2000 on Win2K offers great flexibility in how you manage logins, how you secure both the authentication process and the channel between the client and server, and how you limit access to services enterprisewide. Much of what I discussed in this article happens automatically when you have an AD domain and Win2K on both the client and the servers, so SQL Server DBAs will find using Kerberos very straightforward. And you'll breathe a little easier when you know Kerberos is guarding the gates to your data.