I finally found the problem.I ran strace as several of you suggested. It didn't show anything obvious failing, but it did show that sqlplus was reading sqlnet.ora as part of the authentication process. The contents of that file were:
NAMES.DEFAULT_DOMAIN = localdomain NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)which looked ok to me, but this is not an area I'm expert in. So I tried moving that file to a new name, to see what would happen if it wasn't found.
I found that sqlplus was now reading a file called .sqlnet.ora (that starts with a dot) that lives in the oracle user's home directory. That file looked like this:
SQLNET.AUTHENTICATION_SERVICES= (NTS) NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)Hmm... this looks like a leftover from another time, when the system was used as a client for Oracle running on another server. So I moved this file to another name, and presto - sqlplus '/ as sysdba' started working. So I put the regular sqlnet.ora file back in place, and it still works.
Here's the thing I don't get: the dot-sqlnet.ora file was not being opened every time the thing failed. I have grepped for it in my various trace output files and it was opened whenever sqlnet.ora could not be found or if the listener was down. But it was not opened if the listener was up and sqlnet.ora was in place, and yet it's presence was still causing authentication to fail.
The only thing I can gather is that the presence of that file influenced the starting up of the listener too, and therefore how or where sqlplus was looking to authenticate.
Thanks for all the helpful suggestions! janine -- http://www.freelists.org/webpage/oracle-l