ORA-01994报错主因是os_authent_prefix未配置或不匹配：若该参数为空可直用系统用户名（如alice），否则须加前缀（如ops$alice）；修改需重启且不支持ALTER USER切换认证模式。
ORA-01994：CREATE USER IDENTIFIED EXTERNALLY 报错时先查 os\_authent\_prefix
oracle 外部认证用户创建失败，最常见的原因是数据库没开 os 认证开关，或者用户名前缀不匹配。os_authent_prefix 参数默认是 ops$，但你的系统账户名（比如 alice）不会自动变成 ops$alice —— 除非你显式配了这个前缀，或关掉它。
实操建议：
- 查当前值：
SHOW PARAMETER os_authent_prefix
- 如果返回空或
''，说明已禁用前缀，可直接用系统用户名（如alice）建外部用户；否则必须带前缀，例如CREATE USER ops$alice IDENTIFIED EXTERNALLY; - 修改需重启（
ALTER SYSTEM SET os_authent_prefix='' SCOPE=SPFILE;），别在生产库临时改完就以为生效了 - Linux/Unix 下注意：Oracle 进程启动用户（通常是
oracle）必须有权限读取/etc/passwd或接入的 LDAP/PAM，否则连验证环节都进不去
CREATE USER IDENTIFIED EXTERNALLY 的实际使用场景和限制
这不是用来替代密码登录的“快捷方式”，而是让 Oracle 完全跳过自己的密码校验，把身份交由操作系统或外部服务决定。所以它天然不支持远程连接（SQL*Net 默认禁用），只适用于本地 Unix 域套接字或 Windows 集成认证。
常见错误现象：
- 用 SQL Developer 或 JDBC 远程连，报
ORA-01017: invalid username/password—— 不是密码错，是协议层根本不走外部认证路径 - 用户能登录但查不到数据：因为
CREATE USER只建账号，没赋权，GRANT CREATE SESSION TO ops$alice;必须手动加 - Windows 上用域账户时，用户名格式必须是
DOMAIN\user，且数据库参数os_authent_prefix通常设为空，否则会拼成ops$DOMAIN\user，这显然非法
OS 认证 vs 其他外部认证（如 Kerberos、LDAP）的区别在哪
IDENTIFIED EXTERNALLY 这个语法本身只表示“不由 Oracle 校验密码”，背后真正的认证机制可以是 OS、Kerberos 或目录服务，但 Oracle 不管细节 —— 它只认一个结果：操作系统调用 getlogin() 或等效接口返回的用户名是否匹配你声明的用户名。
关键差异点：
- OS 认证：依赖 Oracle 进程与客户端在同一台机器，且用户 UID/GID 可被识别；不加密，不跨网络
- Kerberos/LDAP：需要额外配置
sqlnet.ora中的SQLNET.AUTHENTICATION_SERVICES和SQLNET.KERBEROS5_CONF等，认证发生在网络层，支持远程 - 同一个用户名（如
bob）在 OS 认证下是bob，在 Kerberos 下可能是bob@REALM.COM，Oracle 把它们当两个完全独立的用户处理
为什么 ALTER USER ... IDENTIFIED EXTERNALLY 不起作用
不能对已有用户执行这个操作。Oracle 明确禁止：一旦用户用密码创建（IDENTIFIED BY），就无法再切到外部认证模式。这是硬限制，不是权限或配置问题。
正确做法只有两个：
- 删掉旧用户重建：
DROP USER alice CASCADE;<br>CREATE USER alice IDENTIFIED EXTERNALLY;
- 或者保留原用户名，但换用新前缀（比如从
ops$alice改为os$alice），前提是os_authent_prefix已设为os$ - 别试图绕过：
ALTER USER ... IDENTIFIED BY VALUES 'EXTERNAL'是无效语法，会报ORA-00922
最易被忽略的一点：外部用户没有密码字段存储位置，所以 DBA_USERS.PASSWORD 列是空的，但这不代表它“没密码”——它根本不需要密码，也拒绝任何密码登录尝试。这点在审计日志里常被误读。
