A Security Roadmap - Kerberos and Active Directory Authentication
(Page 4 of 7 )
SQL Server 2000 adds its own additions to the list of authentication methods for handling Windows 2000 clients. For Windows 95/98 and Windows NT clients, and for Windows 2000 clients connecting to SQL Server 2000 running on Windows NT, authentication in SQL Server 2000 is the same as it is in SQL Server 7.0. For SQL Server 2000 running on Windows 2000, however, you will have the option of authenticating through Active Directory and/or using the Kerberos authentication protocol.
Chapter 5 covers the details, but the main difference is that Windows 2000 uses Kerberos security through the Active Directory service. For the most part, login validation through Active Directory is just a variation on the theme used in Windows NT. Clients present credentials, Windows 2000 validates the credentials, and SQL Server uses the information returned by Active Directory to match aWindows account to an entry in SQL Server 2000’s list of valid logins. Once validated, all the security mechanisms built into SQL Server 7.0/2000 take over, just as they do when you have a Windows NT authenticated login. The main difference between the authentication protocol used by Windows NT and Kerberos is that the Kerberos protocol authenticates both the client’s identity and the server’s identity. The client is assured that it is communicating with the correct server, and the server is assured that the domain controller has authenticated the client’s identity. Kerberos also verifies that the data has not been modified in transit by a third party, which can be useful in situations in which the data needs to travel over the Internet.
Options for Authorization Once the authentication process finishes, SQL Server takes control of authorizing users’ access to objects and data in the system. SQL Server 6.5, 7.0, and 2000 all have similar sets of permissions, but 7.0 and 2000 differ greatly from 6.5 in the way you can assign them. SQL Server 6.5 can assign permissions to individual users and database groups, whereas SQL Server 7.0 and 2000 can grant permissions to Windows authenticated logins based on their individual account or the groups of which they are members. SQL Server authenticated logins in SQL Server 7.0 and 2000 can be granted permissions based on the login ID or on membership in database roles, which function like Windows groups. Chapter 3 covers all the ways you can assign permissions and the list of available permissions for SQL Server 6.5, and Chapter 4 covers the same topics for SQL Server 7.0 and 2000.
Besides handling login authentication, all administrators need to create databases, make changes to the server configuration, perform basic maintenance on databases (such as making backups and restoring corrupted databases), and manage user access to databases. In SQL Server 6.5, the only account that really had the permissions to perform all these tasks was the sa account, which is why so many administrators use that account as their sole server login. SQL Server 7.0 and 2000 have the concept that administrators should be able to divide responsibilities among several people, and also, therefore, logins. The sa account still exists, but administrators can now gain the same rights and privileges through their own accounts instead of sharing one account and password.
 This chapter is from SQL Server Security Distilled, by Morris Lewis (Apress, 2004, ISBN: 1590592190). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Server Roles in 7.0 and 2000 >>
More Windows Security Articles
More By Apress Publishing
/ 2 
