这问题我之前帮同事排查过类似的，结合你的场景（普通运行触发ORA-01017，多次尝试锁账户，管理员权限正常），核心原因大概率和Windows权限导致的Oracle认证/配置加载异常有关，具体可以从这几个方向入手：

• Oracle客户端配置文件的权限限制
  VB6默认以当前用户权限运行时，可能无法正常读取Oracle客户端的核心配置文件（tnsnames.ora、sqlnet.ora）——这些文件通常存放在C:\Oracle\product\11.2.0\client_1\network\admin目录下。如果普通用户没有该目录的读取&执行权限，应用会 fallback 到错误的连接参数（比如默认本地库、缓存的旧密码），多次错误尝试直接触发账户锁定。而管理员权限能绕过这个限制，正常读取配置完成连接。
  👉 建议：给当前用户添加admin目录的读取权限；或者把tnsnames.ora复制到用户专属目录%APPDATA%\Oracle，VB6会优先读取这个位置的配置。

• Windows集成认证（OS Authentication）的身份传递异常
  如果你的Oracle用户配置了OS认证（比如用户名为OPS$DOMAIN\YOUR_USER格式），普通权限下VB6可能无法正确传递当前用户的Windows身份，导致应用尝试用无效的凭证（甚至空用户名/密码）连接，触发ORA-01017。管理员权限下OS身份传递正常，能匹配到正确的Oracle用户。
  👉 建议：检查sqlnet.ora中的SQLNET.AUTHENTICATION_SERVICES参数（如果是(NTS)则开启了OS认证）；可以在应用连接字符串中明确指定用户名密码，不依赖OS认证；或者确认Oracle中已正确映射当前Windows用户的OS认证账户。

• ODBC数据源的权限隔离问题
  如果应用通过ODBC连接Oracle，要注意ODBC数据源分「用户DSN」和「系统DSN」。普通用户可能无法访问系统DSN的配置，导致应用自动使用了配置错误的用户DSN（比如旧密码）去连接，多次失败后锁账户。管理员权限下能正常读取系统DSN的正确配置，所以连接正常。
  👉 建议：检查ODBC数据源管理器，给系统DSN添加当前用户的访问权限；或者重新创建一个用户DSN，配置正确的TNS信息、用户名和密码。

• UAC虚拟化导致的配置重定向
  Windows的UAC虚拟化机制会把对系统目录的写入/读取操作重定向到用户的虚拟存储目录（%LOCALAPPDATA%\VirtualStore）。如果VB6应用之前在管理员权限下修改过Oracle配置，普通权限读取时会拿到虚拟目录里的旧配置（比如过期的密码），导致连接失败。管理员权限下不会触发虚拟化，直接读取真实的配置文件。
  👉 建议：检查%LOCALAPPDATA%\VirtualStore\Oracle目录，删除里面的旧配置文件；或者把Oracle客户端安装到非系统盘目录（比如D:\Oracle），避免UAC虚拟化干扰。

内容的提问来源于stack exchange，提问作者Paul S