Windows Authentication

You can use Windows authentication only where Windows Active Directory is used for network and user authentication. SQL Server permits or denies access to a user after its network logon credentials have been validated by a Windows Domain Controller, without requiring a separate login name and password. This authentication type is often referred to as Windows Integrated Mode and is considered a Trusted Authentication because SQL Server trusts the credentials provided by Windows.

In Windows authentication, all logins are created, stored, and managed by Active Directory. Active Directory enables central management and enforcement of strong and complex password policies, lockout, and expiration.

When an instance is configured for Windows Authentication mode, SQL authentication is disabled. The default sa (system administrator) account is still created but is disabled.

Windows authentication has several advantages:

• Central account management and account policy enforcement through Active Directory.
• Support for Active Directory groups.
• Single sign-on experience by Windows authenticated users. You do not need to enter login name and password to connect to SQL Server.
• Less surface area, making it more secure against additional vulnerabilities and exploits.

Windows authentication has several disadvantages as well:

• Non-Windows domain account authentication is not supported.
• No support exists for legacy applications that require a SQL authentication.

SQL Authentication

SQL Server authentication enables users to specify a login name and password to connect to a SQL Server database. The login name and password are created, stored, and managed in SQL Server.

When an instance is configured for SQL Authentication mode, SQL authentication is enabled alongside with Windows authentication. Both Windows and SQL logins are supported.

SQL Authentication mode enables the default sa account. It is important to assign a strong password to the sa account.

SQL authentication has several advantages:

• Backward compatibility for applications that require SQL logins and passwords
• Support for environments with mixed operating systems, where not all users are authenticated by a Windows domain
• Ability to deploy SQL Server databases as part of applications that require preset SQL Server logins

SQL authentication has several disadvantages:

• Increased surface area, making it more vulnerable to attacks and exploits
• Additional login name and password required for users to remember
• Limited amount of available password policies
• Additional overhead maintaining and synchronizing SQL logins and passwords across multiple SQL Servers

Differences Between SQL and Windows Authentication

Windows authentication is the recommended authentication method for SQL Server because it is superior to Mixed mode because the user does not need to learn yet another password, and because it leverages the security design of the network.

Using Windows authentication means that users must exist as Windows users to be recognized by SQL Server. The Windows security identifier (SID) is passed from Windows to SQL Server.

Windows authentication is robust in that it authenticates not only Windows users, but also users within Windows user groups.

When a Windows group is accepted as a SQL Server login, any Windows user who is a member of the group can be authenticated by SQL Server. Access, roles, and permissions can be assigned for the Windows group, and they apply to any Windows user in the group.

SQL authentication is available only for backward compatibility and should be used only if legacy applications require it or when deploying SQL Server in non-Windows domain environments.

Kerberos and Windows Authentication Delegation

In an enterprise network with multiple servers and IIS, logins can become a problem because a user may be logged in to one server that is accessing another server. This problem arises because each server must have a trust relationship with the others. For internal company servers, this may not be a problem, but when one of those servers sits in an internal network exposed to untrusted networks such as the case of a perimeter network or DMZ (de-militarized network zone) on the Internet for example, you may not want to establish that trust because it presents a security hole.

Security delegation is a Windows feature that uses Kerberos to pass security information among trusted servers.

For example, a user can access IIS, which can access a SQL Server, and the SQL Server sees the user as the username even though the connection came from IIS.

A few conditions must be met for Kerberos to work:

• All servers must run Windows 2000 or later and run Active Directory in the same domain or within the same trust tree.
• Do not select the Account Is Sensitive and Cannot Be Delegated option for the user account.
• Select the Account Is Trusted for Delegation option for the SQL Server service account.
• Select the Computer Is Trusted for Delegation option for the server running SQL Server.
• SQL Server must have a Service Principal Name (SPN), created by setspn.exe, available in the Windows 2000 Resource Kit.

Security delegation is somewhat difficult to set up and may require the assistance of your network-domain administrator. However, the capability to recognize users going through IIS is a powerful security feature. Executing SETSPN to add or delete an SPN does require domain admin rights.

SPN is a powerful security feature, but it does weaken security because the user is impersonated. Therefore, the general warning of its use should be restricted to those cases in which it's absolutely necessary.