ORA-28547报错最常因SQLNET.AUTHENTICATION_SERVICES=(NTS)导致，该配置强制启用Windows NTLM认证，但Navicat、Toad等多数客户端不支持，应改为(NONE)；此举仅影响sqlplus / as sysdba免密登录，其他连接不受影响。
ORA-28547报错时，SQLNET.AUTHENTICATION_SERVICES配置最常踩的坑
这个错误八成不是网络不通，而是客户端在握手阶段被“拦下来”了——尤其当sqlnet.authentication_services设为(nts)时，oracle会强制走windows本地安全认证（ntlm），但多数工具（如navicat、toad、甚至某些sql*plus调用方式）根本不支持或没正确集成该流程，直接断连。
常见表现：
- PL/SQL Developer能连，Navicat死活报
ORA-28547 -
sqlplus / as sysdba失败，但sqlplus username/password@tns_alias成功 - 重启监听器、改
TNSNAMES.ORA都无效，唯独改这一行就通了
实操建议：
- 打开客户端机器上的
sqlnet.ora（路径通常是$ORACLE_HOME/network/admin/sqlnet.ora或%ORACLE_HOME%\network\admin\sqlnet.ora） - 找到
SQLNET.AUTHENTICATION_SERVICES这一行，把它改成：SQLNET.AUTHENTICATION_SERVICES = (NONE) - 如果该行被注释（如
#SQLNET.AUTHENTICATION_SERVICES = (NTS)），先取消注释再修改 - 改完不用重启任何服务，立刻重试连接
为什么SQLNET.AUTHENTICATION_SERVICES = (NTS)在非DBA本地连接时大概率失效
NTS本质是让Oracle复用Windows登录凭证做身份传递，它只在满足全部下述条件时才可靠工作：
- 客户端与数据库在同一台Windows机器上
- 使用
sqlplus / as sysdba这类操作系统认证方式 - 当前Windows用户属于
ORA_DBA组 - 数据库启用了
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE且密码文件存在
只要其中任一条件不满足（比如你用Navicat远程连Linux上的Oracle，或用普通域账号连本机Oracle），NTS就会导致协议协商失败，触发ORA-28547。这不是bug，是设计使然。
改SQLNET.AUTHENTICATION_SERVICES = (NONE)会影响哪些功能
影响非常有限，基本只涉及“免密登录本机数据库”的便利性：
-
sqlplus / as sysdba会失效，必须显式提供sys/password as sysdba - 其他所有基于用户名/密码或TNS别名的连接完全不受影响（包括JDBC、ODBC、OCI应用）
- 数据库自身的远程认证（如密码文件、LDAP、Oracle Internet Directory）照常工作
- 不会降低安全性——只是关掉了那个容易出问题的Windows集成通道
如果你确实需要/ as sysdba，又不能改配置，可临时用sqlplus /nolog + connect / as sysdba绕过初始化阶段的认证协商，但这只是权宜之计。
改完SQLNET.AUTHENTICATION_SERVICES还连不上？重点盯这三个地方
这个配置只是高频诱因，不是万能解药。如果改完仍报ORA-28547，立刻检查：
-
TNSNAMES.ORA里对应别名的(HOST = ...)是否写成了主机名但DNS解析失败？换成IP更稳 - 客户端用的OCI库版本是否和数据库主版本匹配？例如连11g数据库却配了10g的
oci.dll（Navicat尤需注意） - 数据库端
listener.ora中监听地址是否绑定了localhost或127.0.0.1？远程连接时必须监听实际网卡IP
真正麻烦的从来不是改哪一行配置，而是改完之后误以为“已经修好”，结果卡在OCI版本或监听绑定这种更隐蔽的地方。
