此文章主要和大家讲述的是SQL Server 连接字符串与身份验证的实际操作流程， 我们大家都知道SQL Server .NET Data Provider 连接字符串主要包含的是一个由一些属性名/值对组成的集合。每一个属性/值对都由分号隔开。
- PropertyName1=Value1;PropertyName2=Value2;PropertyName3=Value3;.....
同样，SQL Server 连接字符串必须包含SQL Server实例名称:
- Data Source=ServerName;
使用本地的SQL Server(localhost)，如果想要使用远程服务器运行，应该在示例对象中把正确的服务器赋给Data Source 属性。此外，还必须指定所支持的两种身份验证方法(即Windows身份验证和SQL Server身份验证)中的其中一种。
Windows身份验证使用Windows登录用户身份连接数据库，而SQL身份验证要求显式地指定SQL Server用户ID和密码。要想使用Windows身份验证，必须在连接字符串中包括 Integrated Security 属性:
- Data Source=ServerName;Integrated Security=True;
默认情况下，Integrated Security 属性为 False ，这意味着将禁用Windows身份验证。如果没有显式地把这个属性的值设置为True，连接将使用SQL Server身份验证，因此，必须提供SQL Server用户ID和密码。Integrated Security属性还能识别的其他值只有SSPI(Security Support Provider Interface，安全性支持提供者接口).在所有的Windows NT操作系统上，其中包括Windows NT 4.0、2000、XP，都支持值SSPI。
它是使用Windows身份验证时可以使用的惟一接口，相当于把Integrated Security 属性值设置为True。
在Windows身份验证模式中，SQL Server使用Windows的安全子系统对用户连接进行有效性验证。即使显示地指定用户ID和密码，SQL Server也不检查连接字符串中的用户ID和密码。因为只有Windows NT、2000、XP支持SSPI，因此如果正使用的是这些操作系统，则只能使用Windows集成的安全策略去连接SQL Server。不论使用哪一个操作系统，当使用SQL Server身份验证时，必须在SQL Server 连接字符串中指定用户ID和密码：
- Data Source=ServerName;User ID=donaldx;Password=unbreakable
默认情况下，SQL Server .NET Data Provider连接指定用户的默认数据库，当在数据库中创建用户时，可以设置用户的默认数据库。此外，也可以在任意时间更改用户的默认数据库。例如，系统管理员的默认数据库是master。如果想要连接不同的数据库，应该指定数据库的名称：
- Data Source=ServerName;Integrated Security=SSPI;Initial Catalog=Northwind
每一种身份验证都有它的优点和缺点。Windows身份验证使用单一的用户信息库源，因此，不需要为数据库访问去分别配置用户。SQL Server 连接字符串不包含用户ID和密码，因此消除了把用户ID和密码暴露给未授权的用户的危险。可以在Active Directory中管理用户和他们的角色，而不必在SQL Server中显式地配置他们的属性。
Windows身份验证的缺点是，它要求客户通过Windows的安全子系统支持的安全通道去连接SQL Server。如果应用种序需要通过不安全的网络(例如Internet)连接SQL Server，Windows身份验证将不工作。此外，这种身份验证方法也部分地把管理数据库访问控制的责任从DBA身上转移到了系统管理员身上，这在确定的环境中也许是一个问题。
一般而言，在设计通用的应用程序时，为了使用Windows身份验证，将会对一些方面进行加强。大多数公司的数据库都驻留在比较健壮的Windows服务器操作系统上，那些操作系统都支持Windows身份验证。
数据访问层和数据表示层的分离也促进了把数据访问代码封装在中间层组件思想的应用，中间层组件通常运行在具有数据库服务器的内部网络中。当这样设计时，就不需要通过不安全通道建立数据库连接。除此之外，Web服务也使直接连接不同域中数据库的需要大减少。
【编辑推荐】
