ORA-01994报错主因是os_authent_prefix未配置或不匹配：若该参数为空可直用系统用户名（如alice），否则须加前缀（如ops$alice）；修改需重启且不支持ALTER USER切换认证模式。
查 os_authent_prefix 当前值再动手
create user identified externally 失败，八成卡在 os_authent_prefix 配置上。它不是“可选开关”，而是用户名拼接规则的硬编码逻辑：oracle 拿到系统登录名（比如 alice）后，会自动在前面加这个前缀，再去数据库里找匹配的用户名。
先确认当前设置：
SHOW PARAMETER os_authent_prefix
返回结果只有两种关键情况：
- 如果 VALUE 是
ops$（默认）或其它非空字符串（如xx$），你必须用带前缀的用户名建库用户，例如CREATE USER ops$alice IDENTIFIED EXTERNALLY; - 如果 VALUE 是空字符串（
''），说明前缀已禁用，可直接用系统账户名：CREATE USER alice IDENTIFIED EXTERNALLY;
注意：ALTER SYSTEM SET os_authent_prefix='' 修改后必须重启实例才生效，SCOPE=SPFILE 是必须的，别信“改完立刻能用”这种说法。
Linux/Unix 下建用户必须带前缀或清空前缀
在 Linux 上，CREATE USER IDENTIFIED EXTERNALLY 不是“让任意系统用户免密登录”，而是严格按 os_authent_prefix + getlogin() 返回值做精确匹配。比如你的系统用户是 alice，但 os_authent_prefix 是 ops$，那数据库里就必须存在 ops$alice 这个用户——alice 本身无效。
常见翻车点：
- 误以为
CREATE USER alice IDENTIFIED EXTERNALLY能成功 —— 实际报ORA-01994，因为 Oracle 查的是ops$alice，而你建的是alice - 改了
os_authent_prefix却没重启，SQL*Plus 仍按旧规则校验，连connect /都拒绝 - Oracle 进程启动用户（通常是
oracle）没权限读/etc/passwd或 PAM 配置，导致根本拿不到系统用户名，验证流程在第一步就断了
Windows 域用户必须用 DOMAINuser 格式且前缀通常得清空
Windows 环境下，系统返回的登录名是 MISdragon 这种格式。如果 os_authent_prefix 是默认的 ops$，Oracle 会试图匹配 ops$MISdragon —— 这根本不是合法用户名（含反斜杠+长度超限），必然失败。
正确做法是把前缀设为空：
ALTER SYSTEM SET os_authent_prefix='' SCOPE=SPFILE;
然后创建用户时显式带上域信息：
CREATE USER "MIS\dragon" IDENTIFIED EXTERNALLY;
注意双反斜杠转义；连接时用 sqlplus /，前提是当前 Windows 登录就是 MISdragon。别用 SQL Developer 远程连 —— 它走 TCP/IP，默认绕过 OS 认证路径，报 ORA-01017 不是密码错，是压根没走这条链路。
GRANT CREATE SESSION 是必须步骤，不是可选项
CREATE USER ... IDENTIFIED EXTERNALLY 只是注册一个账号，不附带任何权限。用户能执行 connect / 成功，不代表能干任何事 —— 很可能一查表就报 ORA-01031: insufficient privileges。
最简可用组合只有两个动作：
CREATE USER ops$alice IDENTIFIED EXTERNALLY;GRANT CREATE SESSION TO ops$alice;
漏掉第二步，登录后连 SELECT 1 FROM DUAL 都会被拒。别指望 CONNECT 角色自动包含它 —— 在外部认证场景下，CONNECT 不自带 CREATE SESSION，必须显式授予。
最后提醒一句：这个机制只在本地 Unix 域套接字或 Windows 集成认证下有效，远程连接默认关闭，强行开 REMOTE_OS_AUTHENT=TRUE 属于高危操作，2026 年的生产环境没人这么干。
