oracle12.2灵异的ORA-01017: invalid username/password; logon denied

今天研发一台数据库，我需要做个物理备份，出现一个灵异的错

oracle@kungpeng-sk-db01[/oracle/product/122/dbs]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Fri Oct 12 19:11:18 2018

ERROR:
ORA-01017: invalid username/password; logon denied

Enter user-name:
ERROR:
ORA-01017: invalid username/password; logon denied

在使用oracle用户的情况下，怎么都无法直接操作系统认证登陆进去。

看到这种本能的是想到禁用了操作系统验证，看了下$ORACLE_HOME/network/admin/sqlnet.ora文件，发现果然配置了禁用操作系统登陆：

cat $ORACLE_HOME/network/admin/sqlnet.ora
#SQLNET.ALLOWED_LOGON_SERVER=10
#SQLNET.ALLOWED_LOGON_CLIENT=10
SQLNET.ALLOWED_LOGON_VERSION=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=10
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=10
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11
SQLNET.AUTHENTICATION_SERVICES=(NONE)

果断先注释再说：

注释以后，还是涛声依旧。。

oracle@kungpeng-sk-db01[/oracle/product/122/dbs]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Fri Oct 12 19:11:18 2018

ERROR:
ORA-01017: invalid username/password; logon denied

Enter user-name:
ERROR:
ORA-01017: invalid username/password; logon denied

Enter user-name:
ERROR:
ORA-01017: invalid username/password; logon denied
大惊。

正常情况下，sqlnet.ora文件改了就是立即生效的，不是需要重启数据库啥的。

但是现在我也进不了库，也没办法重启数据库，但是觉得重启说不定就好了，没办法，直接重启了操作系统（生产慎重！）。

结果重启以后还是不行，现在到好，没办法进数据库，也起不了数据库了！

有问题解决之，后来看了下oracle文件：

oracle@kungpeng-sk-db01[/oracle]$ ll $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle dba 408419016 Sep 2 22:25 /oracle/product/122/bin/oracle

权限没啥问题。

又看了$ORACLE_BASE下面的得宿主：

用户是oracle，组是dba。

在检查下oracle用户的宿主：

是dba，也没啥问题。

又看了oracle用户的profile文件：

export ORACLE_BASE=/oracle
export ORACLE_HOME=$ORACLE_BASE/product/122
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
export PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$ORACLE_BASE/product/122/bin
export ORACLE_SID=dbepdb

alias gobase='cd $ORACLE_BASE'
alias gohome='cd $ORACLE_HOME'

也没啥问题。

最后没辙了，去metlink上碰碰运气，结果还真是找到了。

最好找到了解决办法：

https://support.oracle.com/epmos/faces/BugDisplay?_afrLoop=511527359437722&id=25578307&_afrWindowMode=0&_adf.ctrl-state=svb01mjj6_715

问题根源：

cat $ORACLE_HOME/rdbms/lib/config.c

该文件中建库的时候选了oinstall，但是该操作系统又没有建oinstall组，这种情况只会产生在使用模板建立的库中。因为用图形界面安装的时候，如果没有该组，oracle是不会给你选到的。

解决这个问题两个办法：

1、简单起见直接建一个oinstall组，然后用usermod把这个组加入到oracle的附加组中去。

groupadd oinstall

usermod -G oinstall oracle

然后就可以直接连上了：

2、另一种比较彻底，就是无需新建一个没用到的组oinstall，直接把$ORACLE_HOME/rdbms/lib/config.c文件里面对应的组都改成现有oracle实际对应的主组dba。

mv $ORACLE_HOME/rdbms/lib/config.c $ORACLE_HOME/rdbms/lib/config.c_bak

vi $ORACLE_HOME/rdbms/lib/config.c

这样，然后保存。

停库。

重新编译config.c文件和重新relink。

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk config.o
relink all

解决！

Applies to:

Oracle Server - Enterprise Edition - Version: 8.0.5.0 to 11.2.0.1 - Release: 8.0.5 to 11.2
Information in this document applies to any platform.
checked for relevance on 30-Aug-2011

Purpose

This article describes the different ways you can connect to Oracle as an administrative user. It describes the options available to connect as SYSDBA and SYSOPER. A checklist to troubleshoot SYSDBA/SYSOPER connections is documented separately :

Note 69642.1 - UNIX: Checklist for Resolving Connect AS SYSDBA Issues

Oracle 8.1 was the last release to support the 'CONNECT INTERNAL' syntax; therefore you must use SYSDBA or SYSOPER privileges in current releases.

SYSDBA and SYSOPER Privileges in Oracle

1) Administrative Users

There are two main administrative privileges in Oracle: SYSOPER and SYSDBA. In version 11g the SYSASM privilege has been added. This basically works in the same manner but will not be addressed here. See Note 429098.1 -11g ASM New Feature for more information.

SYSDBA and SYSOPER are special privileges as they allow access to a database instance even when it is not running and so control of these privileges is totally outside of the database itself.

SYSOPER privilege allows operations such as:

Instance startup, mount & database open ;

Instance shutdown, dismount & database close ;

Alter database BACKUP, ARCHIVE LOG, and RECOVER.

This privilege allows the user to perform basic operational tasks without the ability to look at user data.

SYSDBA privilege includes all SYSOPER privileges plus full system privileges (with the ADMIN option), plus 'CREATE DATABASE' etc.. This is effectively the same set of privileges available when previously connected INTERNAL.

2) Password or Operating System Authentication

Password Authentication

Unless a connection to the instance is considered 'secure' then you MUST use a password to connect with SYSDBA or SYSOPER privilege.

When the passwordfile is initially created with the uility orapwd it holds the password for user SYS, other users can be added to the password file with the 'GRANT SYSDBA to &USER;' command.

Such a user can then connect to the instance for administrative purposes using the syntax:

CONNECT username/password AS SYSDBA

CONNECT username/password AS SYSOPER

This is described in more detail in section (5) below.

Operating System Authentication

If the connection to the instance is local or 'secure' then it is possible touse the operating system to determine if a user is allowed SYSDBA or SYSOPER access. In this case no password is required.
The syntax to connect using operating system authentication is:

CONNECT / AS SYSDBA

CONNECT / AS SYSOPER

Oracle determines if you can connect thus:

On Unix/Linux:

On UNIX the Oracle executable has two group names compiled into it,one for SYSOPER and one for SYSDBA.These are known as the OSOPER and OSDBA groups.Typically these can be set when the Oracle software is installed.

When you issue the command 'CONNECT / AS SYSOPER' Oracle checks ifyour Unix logon is a member of the 'OSOPER' group and if so allows youto connect. Similarly to connect as SYSDBA your Unix logon should be a member ofthe Unix 'OSDBA' group.The OSDBA groups is the same group as has been historically used toallow CONNECT INTERNAL.

On MS Windows NT/2000/2003/XP:

On MS Windows the OSOPER and OSDBA groups are hard coded groups thus:

Group Name Oracle uses this as...
~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
ORA_OPER OSOPER group for all instances
ORA_DBA OSDBA group for all instances

or

ORA_sid_OPER OSOPER group for a specific Oracle SID
ORA_sid_DBA OSDBA group for a specific Oracle SID

When you issue a 'CONNECT / AS SYSDBA' , Oracle checks if your MS Windows logon is a member of the 'ORA_sid_DBA' or 'ORA_DBA' group.

3) OSDBA & OSOPER Groups on Unix/Linux

The 'OSDBA' and 'OSOPER' groups are chosen at installation time and usually both default to the group 'dba'. These groups are compiled into the 'oracle' executable and so are the same for all databases running from a given ORACLE_HOME directory. The actual groups being used for OSDBA and OSOPER can be checked thus:

cd $ORACLE_HOME/rdbms/lib cat config.[cs]

The line '#define SS_DBA_GRP "group"' should name the chosen OSDBA group.
The line '#define SS_OPER_GRP "group"' should name the chosen OSOPER group.

If you wish to change the OSDBA or OSOPER groups this file needs to be modifiedeither directly or using the installer.

Eg: For an OSDBA group of 'mygroup'

If your platform has config.c (this is the case for HP-UX, Compaq Tru64 Unixware and Linux):

Change: #define SS_DBA_GRP "dba"
to: #define SS_DBA_GRP "mygroup"

If your platform has config.s:

Due to the way different compilers under different architectures generate assembler code, it's not possible to give a universal rule. '

Here are some examples:

Sun SPARC Solaris:
------------------
Change both ocurrences of
.ascii "dba\0"
to
.ascii "mygroup\0"

IBM AIX/Intel Solaris:
----------------------
Change both ocurrences of
.string "dba"
to
.string "mygroup"

To effect any changes to the groups and to be sure you are using the groups defined in this file relink the Oracle executable. Be sure to shutdown all databases before relinking:

cd $ORACLE_HOME/rdbms/lib mv config.o config.o.orig make -f ins_rdbms.mk ioracle

(Note config.o will be re-created by make because of dependencies automatically)

For a group to be accepted by Oracle as the OSDBA or OSOPER group it must:

- Be compiled into the Oracle executable
- The group name must exist in /etc/group (or in 'ypcat group' if NIS is beingused)
- It CANNOT be the group called 'daemon'

Note: The commands above are examples and may vary between platforms.

Note: Some Oracle documentation refers to the ability to define OSDBA and OSOPER roles using group names of the form 'ORA_sid_OSDBA'. This functionality has not been implemented on Unix (See bug 224071)

Disabling Operating System Authentication

Given the above information about the technical implementation details of OS authenication it is possible to disable OS authentication by putting non-existant OS group names in the config.c (or config.s) file, then (re)move the config.o and relink oracle, however this is not supported for the following reasons:

- Many tools like RMAN rely on the OS authentication to work, in any documentation and references this behaviour is expected to work.
- If you disable OS authentication like this the administrative connections AS SYSDBA/SYSOPER can only make use of the passwordfile, if there is something wrong with it no one can login, if you consider in a broader sense that availability is also part of security then this means it negatively impacts the security of your system.
- Moreover it only provides a false sense of security since a DBA with access to the oracle software
owner can rebuild the password file or relink oracle to restore it.

Important notes about 'CONNECT / AS SYSDBA'

On Unix systems a user may be a member of more than one group. To connect as an administrative user without supplying a password:

- One of the groups of which the user is a member should be either the OSDBA or OSOPER groups as defined in config.c (config.s on some platforms) and as linked into the 'oracle' executable.
- The group must be a valid group as defined in /etc/group (or as defined in NIS by 'ypcat group')
- The users PRIMARY group (Ie: the one shown by the 'id' command) cannot be the special group 'daemon'.

It is quite common for the 'root' user to be required to have SYSDBA or SYSOPER privilege. Unfortunately it is also common for the root users' primary group to be the group 'daemon' which may prevent it from being allowed to connect without a password. There are two ways to tackle this problem:

a) Make the root users PRIMARY group the OSDBA group

OR

b) Where available use the 'newgrp' command to change the users primary group to the DBA group:

$ newgrp dbagroup $ sqlplus /nolog SQL> connect / as sysdba

This can also be used in shell scripts thus:

newgrp dbagroup <# Commands requiring connect internal privilege # Eg: dbstart !

OR

c) For systems where 'newgrp' is not available or does not work from scripts you can use 'su' instead:

su - oracle <# Commands requiring administrative connect privilege !

Note: The user you 'su' to should be able to 'connect / as sysdba' without a password, for example by having their primary group as the OSDBA group.

Some Oracle releases have problems with identifying the OSDBA group when it is not the users primary group. If you encounter problems with connecting and the OSDBA group is set correctly try making the users primary group the OSDBA group, or use 'newgrp' as in (b) above.

4) OSDBA & OSOPER Groups on MS Windows

The 'OSDBA' and 'OSOPER' groups on NT are simply groups with the name "ORA_DBA", "ORA_OPER", "ORA_sid_DBA" or "ORA_sid_OPER", where 'sid' is the instance name.

Eg: To make a user an administrative user simply:

a) Ensure there is a line in the SQLNET.ORA file which reads:

SQLNET.AUTHENTICATION_SERVICES = (NTS)

b) Create a LOCAL user
c) Create a local NT group ORA_DBA or ORA_sid_DBA where 'sid' is in upper case
d) Add the user to the ORA_DBA or ORA_sid_DBA group
e) That user should now be able to "connect / as sysdba"

If these requirements are not met, you get an ORA-01031 error.

Domain prefixed usernames

It is possible to set up usernames which include the domain as a prefix to the username.

Eg: "OPS$<domain>\<user>".

To do this you need to use the registry entry OSAUTH_PREFIX_DOMAIN and creating users with USERNAMEs of the form "OPS$<domain>\<user>". This is described in detail in Note 60634.1.

5) Password Authentication

Remote connections require the database to be configured to allow remote DBA operations. The remote user will have to supply a password in order to connect as either SYSDBA or SYSOPER. The only real exception to this is on MS Windows where remote connections may be secure.

Ie: To perform a remote connect as SYSDBA or SYSOPER you must use the syntax 'CONNECT username/password AS SYSDBA'

To allow remote administrative connections you must:

- Set up a password file for the database on the server
- Set up any relevant init.ora parameters

5.1) Setting up a Password File

The SYSDBA/SYSOPER password protection is controlled by an Oracle 'Password' file. The basic concept is that a special file is created to hold the 'SYSDBA' and 'SYSOPER' passwords. Users with SYSDBA or SYSOPER privilege granted in the password file can be seen in the view V$PWFILE_USERS.

To create a password file log in as the Oracle software owner and issue the command:

orapwd file=<filename> password=<pwd> entries=<greater than 0> force=y/n

using the required password.

On Unix/Linux the passwordfile name convention is :

$ORACLE_HOME/dbs/orapw$ORACLE_SID

On MS Windows the passwordfile name convention is :

%ORACLE_HOME%\database\PWD%ORACLE_SID%.ORA

The exceptions to this rule are the Database Vault installations for which the location on Windows 32-bit is %ORACLE_HOME%\dbs\orapw%ORACLE_SID%. See Note 429818.1 for more information.

Note:
The file name is important and should be specified as above.
You should create this file when the database is shut down.

To change a password you can use the syntax "ALTER USER DBAUSER identified by newpassword". The changes will be synchronized in the passwordfile. In case this does not work you can recreate the passwordfile as follows:

- Check v$pwfile_users and note the SYSDBA and SYSOPER privileges being granted.
- Shut down the database.
- Rename the password file.
- Issue a new ORAPWD command with a new password to set the SYS password
- Grant SYSDBA and/or SYSOPER to the other users from the first step.

5.2) Setting up the Init.Ora file

To enable remote administrative connections set the init.ora parameters thus:

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

EXCLUSIVE forces the password file to be tied exclusively to a single instance. To disable remote administrative connections set REMOTE_LOGIN_PASSWORDFILE=NONE

Note: The setting of REMOTE_OS_AUTHENT does NOT affect the ability to connect as SYSDBA or SYSOPER from a remote machine. This parameter was deprecated in 11g and should not be used, it is for 'normal' users that use OS authentication and therefore it is not relevant to this discussion.

Note: Some (old) documentation may indicate SQL*Net needs configuring to connect from remote machines. In particular the following parameters are irrelevant:

SQL*Net V2: The REMOTE_DBA_OPS_ALLOWED / REMOTE_DBA_OPS_DENIED

6) Special Notes

Common Errors

ORA-01031: insufficient privileges

Connect Internal has been issued with no password.
For local connections the user is NOT in the DBA group as compiled into the 'oracle' executable.
For remote connections you must always supply a password.

This error can also occur after a successful connect internal/password if there REMOTE_LOGIN_PASSWORDFILE is either unset or set to NONE in the init.ora file.

ORA-01017: invalid username/password; logon denied

This is a fairly general error that indicates one of the following:

- REMOTE_LOGIN_PASSWORDFILE is set to NONE
- The password file does not exist
- The password supplied does not match the one in the password file
- The password file been changed since the instance was started

Deleting/Changing the Password File

If you delete the Oracle password file while the instance is running you will NOT be able to connect AS SYSDBA from remote machines, even if you re-create the file. You must:

- Shutdown the instance (using a local connection)
- Create the new password file
- You can now connect remotely and restart the instance