Oracle远程报表连接必须使用Kerberos或Wallet凭证管理，禁用明文密码；Kerberos需完整配置KDC链路与票据缓存，Wallet需严格权限控制与自动加载设置。
不能直接用操作系统身份验证对接外部报表工具，必须走 Kerberos 或 Oracle Wallet 封装凭证。Oracle 的“无密码”不等于“无凭证”，而是把密码换成了受控的密钥材料。直接在 Power BI、Tableau 或 Excel 中填空用户名密码，哪怕只填用户名（如 CONNECT /@db_alias），在远程连接场景下默认会失败——因为操作系统身份验证仅限本地登录，且依赖客户端 OS 用户与数据库服务器 OS 用户的严格对齐，报表工具根本无法复现该上下文。
Kerberos 是远程报表工具最可行的无密码方案
Power BI Desktop、Tableau Desktop、SQL Developer 等主流工具支持 Kerberos（需客户端启用 SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)），但前提是整个链路闭环：
- 数据库端已配置
krb5.conf、v5srvtab和sqlnet.ora中的SQLNET.KERBEROS5_CONF/SQLNET.KERBEROS5_KEYTAB - 报表工具运行所在的操作系统用户必须已通过
kinit获取有效票据（SQLNET.KERBEROS5_CC_NAME指向的缓存文件存在且未过期） - TNS 别名中不能带密码，连接字符串必须形如
CONNECT /@EAST，否则 Oracle 会跳过 Kerberos 自动协商 - 数据库用户必须是外部认证用户（
CREATE USER scott IDENTIFIED EXTERNALLY;），且该用户名需与 Kerberos 主体名（如scott@REALM）前缀一致
Oracle Wallet 更适合服务端批量报表作业
当报表由后台调度（如 Power BI Gateway、Linux cron + sqlplus 脚本）触发时，Wallet 是更稳定的选择：
- 用
mkstore -wrl /path/to/wallet -create创建自动打开的 wallet，再用mkstore -wrl /path/to/wallet -createCredential db_alias username password存入凭证 - 在
sqlnet.ora中设置WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /path/to/wallet)))和SQLNET.WALLET_OVERRIDE = TRUE - 连接时只需
CONNECT /@db_alias，Oracle 自动从 wallet 提取对应db_alias的用户名和密码 - 注意：wallet 文件权限必须为
600，且仅限属主可读；若用在 Windows 服务账户下，需确保该账户对 wallet 目录有读取权
千万别踩的三个坑
这些错误会导致“明明配了却仍提示 ORA-01017：invalid username/password”：
- 在
sqlnet.ora中同时启用SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5, NTSS)—— 多个认证方式并存时 Oracle 可能随机选择一个失败路径，应只留(KERBEROS5) - 用
ALTER SYSTEM SET remote_login_passwordfile=EXCLUSIVE后又试图走外部认证 —— 口令文件模式会干扰外部验证流程，保持默认NONE或显式设为NONE - Power BI Desktop 使用 “Windows” 身份验证类型时，误以为它等价于 Kerberos —— 实际上它走的是 NTLM 或协商协议，仅适用于 Windows 域内直连，跨平台或非域环境必然失败
真正安全的“无密码”，本质是把密码移出应用层、交由可信基础设施托管。Kerberos 依赖 KDC 信任链，Wallet 依赖文件系统权限隔离——两者都要求你放弃“在连接字符串里写明文密码”的惯性操作。一旦 wallet 权限放错，或 klist 显示票据已过期，报表就会静默中断，这类问题往往在凌晨调度时才暴露。
