【问题标题】:SQL Server 2008 Server-Side "Invalid userid" (Error 18456, Severity: 14, State: 5)SQL Server 2008 服务器端“无效用户 ID”(错误 18456,严重性:14,状态:5)
【发布时间】:2010-12-04 01:04:00
【问题描述】:

错误

数据库管理员报告 Microsoft SQL Server 2008 服务器端错误“无效登录”(错误 18456,严重性:14,状态:5)。

来自服务器日志的错误示例:

Dec 1 2010 10:12AM - Login failed for user '{Active Directory Name #1}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #1}]
Dec 1 2010 10:44AM - Login failed for user '{Active Directory Name #2}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #2}]
Dec 1 2010 2:03PM - Login failed for user '{Active Directory Name #3}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #3}]
Dec 1 2010 4:18PM - Login failed for user 'Admin'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #1}]

{Active Directory 名称} 与其登录名相同,但没有域。例如,全名是 {domain}\{Active Directory Name}。

用户“Admin”的错误来自与 {Active Directory Name #1} 相同的 IP 地址,该用户正在开发 Microsoft Access Visual Basic for Applications (VBA) 代码;我怀疑这源于需要使用适当的 Windows 身份验证连接字符串配置他对 VBA 的最小使用,即使他仅通过 ODBC DSN 链接访问数据。

环境

包含 ODBC 文件 DSN 的 Microsoft Access 2003(前端)数据库链接到只读 Microsoft SQL Server 2008(后端)数据库中的表。

我拥有前端数据库的管理员权限。我拥有后端数据库的只读安全权限,该数据库位于外部数据中心的托管服务器上。 DBA 已为 Windows 身份验证配置后端数据库。

最终用户使用 Active Directory 帐户登录其 PC,打开前端数据库,然后使用 Microsoft Access 查询设计器使用指向后端数据库的表链接生成报告。前端数据库不使用 Microsoft Access Jet Security(据我所知——没有登录提示)。

前端数据库不报告(可见)错误并产生预期结果。

ODBC 文件 DSN 内容

[ODBC]
DRIVER=SQL Server
Trusted_Connection=Yes
StatsLogFile={path}
StatsLog_On=Yes
DATABASE={dbname}
APP=Microsoft Data Access Components
Description={general description}
SERVER={server name}

为什么文件 DSN 链接可以正常工作,但会生成服务器端无效登录错误?谢谢。

【问题讨论】:

  • 附加说明:表格链接在开发、测试和最终用户使用期间不会出现客户端错误。用户 1、2 和 3 是 Active Directory 组的成员,该组作为后端数据库上的用户创建并被授予角色 db_datareader。相同的 Active Directory 组已创建为服务器本身的登录名,并授予角色 db_datareader 和 public;登录名已正确映射到后端数据库上的用户。
  • 注:改为反映2008年而不是2005年;我们的生产实例是2005,但开发环境是2008。

标签: sql-server-2008 odbc ms-access-2003


【解决方案1】:

最终用户是否有可能看到缓存的数据? SQL Server 是否设置为允许远程连接? AD 帐户是否设置为登录名以及相应数据库上的授权用户?当您通过 ODBC 管理器测试 ODBC 连接时,您是否获得了成功的连接?成功的连接测试是否会产生错误?后端数据库和前端应用程序在同一个域上吗?如果没有,是否有域信任设置? (如果不是,您可能需要使用 SQL 登录而不是 AD)

这些都是我通常会尝试解决此类问题的所有类型。

【讨论】:

  • 通过 ODBC 管理器的 ODBC 连接报告连接成功。未知成功的连接测试是否会产生错误;很好的洞察力。后端和前端数据库存在于同一个域中。缓存和远程连接问题似乎不太可能(对我而言),但我会牢记这一点。 AD 帐户设置为登录名以及适当数据库上的授权用户——这似乎是另一种极好的可能性,我认为这是一种极好的可能性。谢谢。
  • 我在上面的数据库中的登录/用户的 AD 设置中添加了一些额外的 cmets。
  • Access 数据库如何配置来验证用户的权限?尝试访问 SQL Server 数据库时,查询设计器可能依赖于不正确的信息
  • 您好 blueberryfields,Access 数据库使用 Windows 身份验证; SQL Server 2008 实例处理授权。
  • 在运行分析器时尝试连接时会发生什么(重新创建错误)?探查器说谁在尝试连接?
【解决方案2】:

问题的根源似乎是未记录的 (?) Microsoft Access 对 ODBC 连接字符串的 255 个字符限制。

每个 Microsoft Access ODBC 链接表都是使用包含“Trusted_Connection=Yes”行的 DSN 文件创建的。

据推测,这会告诉 Microsoft Access 使用 Windows 身份验证。

但是,在仔细检查其中一个 ODBC 链接表时,我注意到文本“Trusted_Connection=Yes”超出了文本的前 255 个字符。我可以通过使用 VBA 即时窗口和运行命令看到它存在

打印 CurrentDb.TableDefs("{table}").Connect

但这只会打印 271 个字符,而不是完整的字符串。然而,最后 10 个字符是:

Trusted_Co

使用前 255 个字符中包含 Trusted_Connection=Yes 行的 DSN 文件重新链接表解决了该问题。

谢谢。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-03-09
    • 1970-01-01
    相关资源
    最近更新 更多