為什麼有時 `SYSTEM` 可直接以 `SYSDBA` 登入，有時卻報 `ORA-01031: insufficient privileges`？關鍵在於 **驗證模式** 設定：OS 驗證 允許作業系統群組成員以任意帳號/密碼以 `SYSDBA` 身分登入 (實際映射為 `SYS`)，而 密碼文件驗證 則嚴格核對密碼文件中的授權使用者。本文深度解析兩種驗證機制、`sqlnet.ora` 切換方式、`SYS`/`SYSTEM` 實際權限差異，並還原現場排查過程。
| 維度 | OS 驗證 | 密碼文件驗證 |
|---|---|---|
| 原理 | 作業系統群組 (Windows: ORA_DBA, Linux: dba) 成員身分驗證 | Oracle 密碼文件 ($ORACLE_HOME/dbs/orapwSID) 記錄授權使用者 |
| 登入行為 | 輸入任意 user/pass，以 SYSDBA 登入 → 實際成為 SYS | 需密碼文件中有該使用者且密碼正確 |
| SHOW USER 結果 | SYS | 輸入的使用者名 (如 SYSTEM) |
| 適用場景 | 本地維護、單機、DBA 團隊共用 OS 帳號 | 遠端管理、多實例、審計要求明確身分 |
| 安全性 | 較低 (OS 群組成員皆可) | 較高 (需知密碼文件密碼) |
# 位置：$ORACLE_HOME/network/admin/sqlnet.ora
# OS 驗證 (Windows NTS)
SQLNET.AUTHENTICATION_SERVICES = (NTS)
# 密碼文件驗證 (NONE 表不使用 OS 驗證)
SQLNET.AUTHENTICATION_SERVICES = (NONE)
修改後需重啟 Listener 或重新建立連線生效。
| 項目 | SYS | SYSTEM |
|---|---|---|
| 內建角色/權限 | DBA, SYSDBA, SYSOPER | DBA (僅角色)，無 SYSDBA/SYSOPER |
| 資料字典基表擁有者 | 是 (所有基表在 SYS 下) | 否 |
| 允許登入身分 | 僅 SYSDBA, SYSOPER (不可 NORMAL) | NORMAL (預設)，授予後可 SYSDBA/SYSOPER |
| 密碼文件 | 永遠存在於密碼文件中 | 需手動授予 SYSDBA 才寫入密碼文件 |
現象： 新建資料庫，用 PL/SQL Developer 以 `SYSTEM` / `SYSDBA` 登入 → `ORA-01031`。
因為舊環境 `sqlnet.ora` 設為 `NTS` (OS 驗證)。OS 群組 `ORA_DBA` 成員以任何帳號以 `SYSDBA` 登入皆映射為 `SYS`，看似 `SYSTEM` 成功，實際是 `SYS`。修改為 `NONE` 後，嚴格驗證密碼文件，`SYSTEM` 無授權即失敗。
$ORACLE_HOME/dbs/orapwSID`。
-- 目前驗證模式
SELECT value FROM v$parameter WHERE name = 'os_authent_prefix';
-- 或檢查 sqlnet.ora 實際生效值
-- 密碼文件中授權使用者
SELECT * FROM v$pwfile_users;
-- 當前登入身分
SHOW USER;
SELECT SYS_CONTEXT('USERENV','SESSION_USER') FROM DUAL;
SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_TYPE') FROM DUAL; -- OS / PASSWORDFILE
搞清 OS 驗證與密碼文件驗證的本質差異，即可預防「以為有權限實際無權限」的生產事故，並建立可審計、可控制的特權存取體系。
