In SQL Developer, you would create a connection of Connection Type: Local/Bequeath. However, since a Connection Name may contain only alphanumeric characters, the at sign (@), the underscore (_) and the hyphen ( - ), you may have trouble creating the connection. That depends on whether the OS user belongs to a group domain (which mean the name would require a backslash ( \ ) as a separator character between the domain and user names), and whether your Oracle DB's os_authent_prefix contains any unsupported characters (the default value is ops$).
The mechanics of creating the user is best found in Oracle documentation...
Looking at all_users, my schema name does not have a prefix. This site uses Active Directory as its credentials master, if that
makes a difference.
Also, a question: when I choose Local/Bequeath, there is no place to identify the instance to which I want to connect. Clearly
I'm still missing something.
when I choose Local/Bequeath, there is no place to identify the instance to which I want to connect.
This is not my area, but the intent with a Local/Bequeath connection is to permit connection to a database running on the same server as your client, where the specific database is identified by environment variables (ORACLE_HOME, ORACLE_SID). I should have known better than to suggest Local/Bequeath when I saw the "@dbname" in your "sqlplus /@dbname" example.
Since you mention MS Active Directory, which uses LDAP, you may want to investigate whether using Connection Type: LDAP will work for you. LDAP support in SQL Developer was initiaily added for our Oracle Internet Directory product (now part of ODS), and occasionally reports appear in this forum that the LDAP connection type is not working with some other flavor LDAP product.
The problem was a lack of understanding on my part. As noted, I was able to connect to a
database with the command sqlplus /@dbname.
I interpreted this to mean that I would not need to provide a userId and password to SQL*Developer
and spent a lot of time trying to figure out how to do this.
As it turned out, the key is to provide the network login and network password in the appropriate
connection controls and to set the Kerberos checkbox to true. Once I did that, everything worked
as I expected.
Gary, thanks for your help and time on this.