根本原因在于Oracle外部认证仅支持本地连接，远程TCP/IP连接强制密码校验，IDENTIFIED EXTERNALLY被忽略；os_authent_prefix配置、OS身份验证、用户权限及大小写敏感性均需严格匹配。
根本原因不是语法写错，而是认证路径在连接阶段就被截断了——Oracle 根本没走到“比对用户名”那一步。
SQL*Net 连接方式不支持外部认证
用 sqlplus user/pass@tns_alias 或 JDBC/ODBC 远程连接时，协议层强制走密码校验，IDENTIFIED EXTERNALLY 完全被忽略。这不是配置问题，是 Oracle 的硬性限制。
- 只允许本地 Unix 域套接字（Linux/Unix）或 Windows 集成认证（
sqlplus / as sysdba）触发外部认证 -
tnsnames.ora里哪怕 host 写的是 localhost，只要用了 TCP/IP 协议（即含HOST=和PORT=），就进不了 OS 认证流程 - Windows 下若未设
SQLNET.AUTHENTICATION_SERVICES=(NTS)，连本地sqlplus /都会报ORA-01031: insufficient privileges
os_authent_prefix 不匹配或未生效
这是 ORA-01994 最常见的直接诱因：数据库查不到你“以为存在”的用户。
- 运行
SHOW PARAMETER os_authent_prefix，如果值是ops$，你就必须建CREATE USER ops$alice IDENTIFIED EXTERNALLY，不能只建alice - 如果值是空字符串（
''），则必须建CREATE USER alice IDENTIFIED EXTERNALLY，带前缀反而报错 - 修改该参数需重启实例：
ALTER SYSTEM SET os_authent_prefix='' SCOPE=SPFILE，改完不重启 = 白改 - Windows 域用户如
MIS\alice，Oracle 实际拿到的是MISalice（反斜杠被丢弃），此时前缀必须为空，否则拼成ops$MISalice超长或含非法字符
操作系统层面验证失败
Oracle 拿到用户名后，会调用系统接口（如 getlogin()）确认当前登录会话身份。这步失败，后续全无意义。
- Linux/Unix 下 Oracle 后台进程（通常是
oracle用户）必须能读取/etc/passwd或接入的 PAM/LDAP，否则返回空用户名 - 用户必须通过交互式登录（SSH、console）进入系统，不能是
su - alice或脚本中sudo -u alice启动 sqlplus —— 这些场景下getlogin()常返回原始登录用户，不是你期望的alice - Windows 上非域环境，本地用户需属于
ORA_DBA组；域用户需确保注册表项OSAUTH_PREFIX_DOMAIN=FALSE已设，否则 Oracle 会尝试匹配带域名的全名
用户建了但没授权或权限不足
CREATE USER ... IDENTIFIED EXTERNALLY 只建账号，不给任何权限。连最基础的登录都不行。
- 必须显式执行
GRANT CREATE SESSION TO ops$alice（注意：GRANT CONNECT TO ...在 12c+ 默认不含CREATE SESSION） - 如果想执行 DML，还得
GRANT SELECT ANY TABLE等，外部认证不自动赋予 DBA 或 RESOURCE 角色 - 检查是否误用双引号：建用户时用了
"ops$alice"，后续授权也得用GRANT ... TO "ops$alice"，大小写和符号必须完全一致
最容易被忽略的是：外部认证不是“免密登录的快捷方式”，它是把整个认证责任移交操作系统。一旦连接走网络协议、用户名拼错、系统调用失败或权限缺失，错误表现都一样——ORA-01017 或 ORA-01994，但背后原因天差地别。排查必须从连接方式开始，一层层往下压，不能只盯着 SQL 语句。
