oracle全局用户本身不导致sqlplus / as sysdba认证失败，真正原因是os_authent_prefix非空或nts与域策略冲突；全局用户仅在eus启用时通过ldap/kerberos认证，与本地os认证完全隔离。
oracle 11g 及以上版本中，全局用户（global user）不会导致本地 sqlplus / as sysdba 认证失败 —— 真正出问题的，是误启用了 os_authent_prefix 或混淆了全局用户与操作系统认证机制。
为什么全局用户本身不触发 ORA-01031 或 ORA-12638
全局用户（如 cn=user,ou=users,dc=example,dc=com）只在启用企业用户安全（Enterprise User Security, EUS）且配置了目录服务（如 OID、AD）时才生效。它和本地操作系统认证完全隔离：前者走 LDAP/Kerberos，后者依赖 Windows 本地组（ORA_DBA）或 Unix dba 组。如果你看到 ORA-01031: insufficient privileges 或 ORA-12638: credential retrieval failed，基本可以排除“全局用户配置错误”这个原因 —— 它压根没参与这次认证流程。
真正踩坑点：OS_AUTHENT_PREFIX 被设为非空值
当 OS_AUTHENT_PREFIX 参数被显式设为非空字符串（比如 'OPS$' 或 'G$'），Oracle 会强制要求操作系统用户名必须带该前缀才能通过 OS 认证。但 Windows 默认不加前缀，于是 sqlplus / as sysdba 直接报 ORA-01031。
- 检查当前值：
show parameter os_authent_prefix - 临时绕过（会话级）：
alter system set os_authent_prefix='' scope=memory;（仅对当前实例有效） - 永久修复（推荐）：在
init.ora或spfile中设为os_authent_prefix = ''，然后重启实例 - 注意：设为空字符串
''是合法值；设为NULL会导致参数不可用，反而更糟
域账户登录失败：不是全局用户问题，而是 NTS 认证冲突
Windows 域账户（如 DOMAIN\user）在默认 sqlnet.ora 配置下会触发 Kerberos 流程，而 Oracle 11g/12c 对域环境支持脆弱，极易出现 ORA-12638。这不是全局用户惹的祸，是 sqlnet.ora 里 SQLNET.AUTHENTICATION_SERVICES=(NTS) 和域策略打架。
- 最简解法：把
SQLNET.AUTHENTICATION_SERVICES改成(NONE)，强制走密码文件认证 - 验证是否生效：改完后重启监听器（
lsnrctl reload），再试sqlplus / as sysdba - 副作用：禁用 NTS 后，所有 OS 认证失效，只能靠
orapwd创建的密码文件（orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxx entries=10） - 若必须保留 NTS，请确保当前用户是本地管理员，并已加入
ORA_DBA组（不是域组）
误以为“全局用户”导致连接失败，实际是 SID 或服务未就绪
很多用户在配置 EUS 后尝试 sqlplus global_user@db_alias 失败，第一反应是“全局用户认证错了”，但更大概率是基础连接不通 —— ORA-12560 或 ORA-12154 才是真凶。
- 先确认实例是否运行：
sqlplus /nolog→connect / as sysdba（本地直连） - 检查
tnsnames.ora中的服务名是否匹配数据库实际 service_name（不是db_name） - 全局用户登录命令格式必须是：
sqlplus global_user@service_name，不能写成@tns_alias除非 alias 显式指向该 service - EUS 要求客户端也配置
sqlnet.ora：含WALLET_LOCATION和SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)等，缺一不可
真正麻烦的从来不是全局用户本身，而是把它和操作系统认证、监听器配置、域策略混在一起排查。一旦看到认证失败，先问自己：我这次连的是哪条路？OS？密码文件？还是 LDAP？路径选错，再调全局用户参数也没用。
