Enterprise User Security依赖Oracle Internet Directory或Oracle Unified Directory、GLOBAL_NAMES=TRUE配置、SSL连接及单独许可。
不能直接在普通Oracle数据库实例上启用Enterprise User Security（EUS），它依赖Oracle Internet Directory（OID）或Oracle Unified Directory（OUD）作为中央LDAP目录服务，且仅在企业版+额外许可下可用。
Enterprise User Security 依赖哪些组件？
EUS不是独立功能，而是Oracle身份联合架构中的一环。它要求：
- 后端必须部署
Oracle Internet Directory或Oracle Unified Directory（OUD），不能用OpenLDAP或AD直接替代（虽OUD可桥接AD，但EUS客户端仍连OUD） - 数据库需配置为
GLOBAL_NAMES=TRUE，且数据库全局名（GLOBAL_NAME）必须与OID/OUD中注册的服务名严格一致 - 必须启用数据库的
SSL连接（sqlnet.ora中需配置SSL_SERVER_DN_MATCH=ON和有效证书） - 需要单独购买
Oracle Enterprise User Security选项许可——未许可时执行CREATE ENTERPRISE USER会报ORA-00942: table or view does not exist
创建 enterprise user 的典型流程和易错点
即使环境就绪，常见失败不是语法问题，而是上下文不匹配：
- 执行
CREATE ENTERPRISE USER前，该用户必须已在OID/OUD中存在，且其orclCommonName属性值需与SQL语句中指定的用户名完全一致（区分大小写） - 数据库用户不能有密码：语句中不能带
IDENTIFIED BY，否则报ORA-28030: server host name does not match certificate或ORA-28033: authentication failed - 必须用具备
ADMINISTER DATABASE TRIGGER权限的用户（通常是DBA）执行，普通CREATE USER权限不够 - 连接字符串必须显式指定SSL：例如
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=dbhost)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=orcl)))，用普通TCP端口会静默降级为本地认证
为什么 connect / as sysdba 不走 EUS？
这是最常被误解的行为：
-
CONNECT / AS SYSDBA绕过所有数据库层认证机制，包括EUS、Profile、甚至密码文件校验，直连实例后台进程 - EUS只对普通用户连接生效（即通过监听器建立的、非SYSDBA/SYSOPER的连接）
- 即使已配置EUS，
SELECT USERNAME, AUTHENTICATION_TYPE FROM DBA_USERS中 enterprise user 的AUTHENTICATION_TYPE仍显示为PASSWORD—— 这是视图设计缺陷，不代表实际认证方式；真实认证路径需查V$SESSION_CONNECT_INFO的NETWORK_SERVICE_BANNER字段是否含TCPS
替代方案比硬上EUS更现实
多数团队卡在OID/OUD部署成本和许可费用上。更可行的集中认证路径是：
- 用
Oracle Wallet管理数据库凭据，配合应用层统一认证（如Spring Security + OAuth2），数据库侧只做最小权限用户映射 - 在12c及以上版本，启用
COMMON USER+CDB$ROOT统一管理，虽非LDAP集中，但能收敛用户创建入口 - 若已有Microsoft Entra ID，通过
Datawiza或Oracle Cloud Infrastructure Identity Domains做反向代理，数据库保持本地用户，认证交由外部IDP完成
真正难的从来不是命令怎么写，而是确认你是否真的需要EUS——它解决的是大型多数据库、多应用、强合规审计场景下的身份统一问题，不是单库权限管理的银弹。
