scolev@attc.UUCP (Scott Levin) (12/05/90)
----- News saved at 4 Dec 90 22:05:57 GMT
I am trying to use the auto-login feature of Oracle in
combination with SQL*NET. Without SQL*NET the following
connect command works fine.
CONNECT /
However, as soon as I add the syntax to access Oracle across
a Sun network, I am unable get the auto-login feature to work.
Following are the two commands I used when trying to connect across
the network.
CONNECT /@T:oracle_server:TEST_DB
ERROR: ORA-01017: invalid username/password; logon denied
CONNECT / @T:oracle_server:TEST_DB
ERROR: ORA-01005: null password given; logon denied
Has anyone had any success in using the auto-login feature
of Oracle in conjunction with SQL*NET. The versions of Oracle
RDBMS, SQL*Plus, and SQL*NET I am using are V6.0.26.8.1,
Version 3.0.6.1.1, and Version 1.1.4 respectively.
I would appreciate any response to this newsgroup or reply
directly to me by E-mail at scolev@auto-trol.COM. Thanks.
--
SCOTT LEVIN
scolev@auto-trol.COM Auto-trol Technology Corporation
{...}ncar!ico!auto-trol!scolev 12500 North Washington Street
(303) 252-2865 Denver, CO 80241-2404
--
SCOTT LEVIN
scolev@auto-trol.COM Auto-trol Technology Corporation
{...}ncar!ico!auto-trol!scolev 12500 North Washington Street
(303) 252-2865 Denver, CO 80241-2404toncha@attc.UUCP (Tony Chang) (12/06/90)
In article <911@attc.UUCP> Scott Levin writes: |> ----- News saved at 4 Dec 90 22:05:57 GMT |> I am trying to use the auto-login feature of Oracle in |> combination with SQL*NET. Without SQL*NET the following |> connect command works fine. |> |> CONNECT / |> |> However, as soon as I add the syntax to access Oracle across |> a Sun network, I am unable get the auto-login feature to work. |> |> Following are the two commands I used when trying to connect across |> the network. |> |> CONNECT /@T:oracle_server:TEST_DB |> |> ERROR: ORA-01017: invalid username/password; logon denied |> |> CONNECT / @T:oracle_server:TEST_DB |> |> ERROR: ORA-01005: null password given; logon denied |> |> |> |> Has anyone had any success in using the auto-login feature |> of Oracle in conjunction with SQL*NET. The versions of Oracle |> RDBMS, SQL*Plus, and SQL*NET I am using are V6.0.26.8.1, |> Version 3.0.6.1.1, and Version 1.1.4 respectively. |> |> This is to follow up the problem Scott is having with the auto-login feature of ORACLE. Our environment is as the following: SUN Sparc station 1 SUN OS 4.1 Ethernet - TCP/IP ORACLE RDBMS 6.0.26.8.1 ORACLE SQL*Plus 3.0.6.1.1 ORACLE SQL*Net TCP/IP 1.1.4 Our ORACLE setup is as the following: oracle_server is the host name of the ORACLE server. oracle_client1 is the host name of the ORACLE client. TEST_DB is the ORACLE system id. user1 is a SUN OS user account. OPS$user1 is created by ORACLE DBA with the password user1password for automatic login purposes. The problem was that when connecting TEST_DB on oracle_server as auto-login account OPS$user1, it worked fine. However, while connecting from a client node as the same account, it did NOT. I've logged on "oracle_server" as user1, SQL> CONNECT / SQL> CONNECT OPS$user1/user1password Both of the above commands worked fine. I've logged on "oracle_client" as user1, SQL> CONNECT /@T:oracle_server:TEST_DB SQL> CONNECT OPS$user1/user1password@T:oracle_server:TEST_DB The first command did not work while the second one did. I was wondering if anyone who has a similar setup could try the same commands and find out if this is an ORACLE bug. I have heard that they work on VAX/VMS and DEC/ULTRIX platforms. I would like to thank Dale Cook who replied to Scott's original request. Dale's response has inspired some thoughts that lead to a clearer picture of thie problem. Thanks a lot! I would like to use this feature in PRO*C applications eventually. If anyone has information about this problem and potential traps on PRO*C development, I would appreciate you send them to either me or Scott through E-mail.
srm@occrsh.ATT.COM (12/09/90)
On Dec 4, 1990, scolev@attc.UUCP writes: >I am trying to use the auto-login feature of Oracle in >combination with SQL*NET. Without SQL*NET the following >connect command works fine. > CONNECT / >However, as soon as I add the syntax to access Oracle across >a Sun network, I am unable get the auto-login feature to work. >-- >SCOTT LEVIN >scolev@auto-trol.COM Auto-trol Technology Corporation >{...}ncar!ico!auto-trol!scolev 12500 North Washington Street >(303) 252-2865 Denver, CO 80241-2404 Yes, this is a problem that I have to deal with constantly. The problem turns out that "CONNECT /" causes the background oracle process to go to the operating system for info on your user id. No problem yet. When you attempt to connect through the network, the background oracle process must do the same thing (as before) __ONLY__ on the remote machine. Apparently, either the TCP driver "orasrv" spawns off your background process to run as "someone else" (probably root if orasrv runs under root user id) or it looks for an entry in /etc/utmp both of which are failing. The only work-around to this problem (that I and Oracle have found) is to connect via the following: CONNECT OPS$USERNAME/PASSWORD@T:machine_name:SID This will work although PASSWORD will have to be in source code. This creates a security problem! But it does work. -- Steven R. McMaster UNIX(R) mail: ...!uunet!att!occrsh!srm AT&T Network Systems Oklahoma City Works Any opinions expressed in the message above are srm@occrsh.att.com mine, and not necessarily AT&T's.
heimir@rhi.hi.is (Heimir Thor Sverrisson) (12/11/90)
In <143900010@occrsh.ATT.COM> srm@occrsh.ATT.COM writes: [deleted stuff abt. "CONNECT /" failing over network] >turns out that "CONNECT /" causes the background oracle process to go to >the operating system for info on your user id. No problem yet. When >you attempt to connect through the network, the background oracle process >must do the same thing (as before) __ONLY__ on the remote machine. It does not do that properly and that can only be regarded as a BUG! [deleted bug speculation] >only work-around to this problem (that I and Oracle have found) is to >connect via the following: > CONNECT OPS$USERNAME/PASSWORD@T:machine_name:SID >This will work although PASSWORD will have to be in source code. >This creates a security problem! But it does work. This is one more addition to the "Oracle security joke under Unix". The first part I came across was that user could run a utility from the command line with his/hers username/password as an argument! Not only can a person looking over his shoulder see it as it is typed, but everyone taking a long list of the processes ('ps axu'/'ps -ef') can get easy access to Oracle. With this workaround, somebody with read-access to the program sources can get some passwords with 'grep -i connect *.c'!!! The worst part of this big security joke is that you cannot even turn this useless system off, and it's getting in the way of users all the time! >-- >Steven R. McMaster UNIX(R) mail: ...!uunet!att!occrsh!srm >AT&T Network Systems >Oklahoma City Works Any opinions expressed in the message above are >srm@occrsh.att.com mine, and not necessarily AT&T's. -- Heimir Thor Sverrisson heimir@rhi.hi.is
lwk@june.engin.umich.edu (Lewis W Kellum) (12/12/90)
In article <2524@krafla.rhi.hi.is>, heimir@rhi.hi.is (Heimir Thor Sverrisson) writes: |> This is one more addition to the "Oracle security joke under Unix". The |> first part I came across was that user could run a utility from |> the command line with his/hers username/password as an argument! |> Not only can a person looking over his shoulder see it as it is typed, |> but everyone taking a long list of the processes ('ps axu'/'ps -ef') can |> get easy access to Oracle. |> With this workaround, somebody with read-access to the program sources |> can get some passwords with 'grep -i connect *.c'!!! |> The worst part of this big security joke is that you cannot even turn this |> useless system off, and it's getting in the way of users all the time! |> >-- I agree. In one of the earlier versions, Any machine in the Internet could do a 'connect internal' to our Oracle server. No password, no nuthin. All they had to be was a dba at their local site. I suspect the lack of auto login through the net is to prevent a similar problem. If there were two users with the same login-id on two different machines (or the same uid - I'm not sure which Oracle uses), how is oracle to decide which to authenticate? |> >Steven R. McMaster UNIX(R) mail: ...!uunet!att!occrsh!srm |> >AT&T Network Systems |> >Oklahoma City Works Any opinions expressed in the message above are |> >srm@occrsh.att.com mine, and not necessarily AT&T's. |> -- |> Heimir Thor Sverrisson heimir@rhi.hi.is -- Woody Kellum Internet: lwk@caen.engin.umich.edu
IAN@SLACVM.SLAC.STANFORD.EDU (12/13/90)
How to log on to an ops$ account on a remote machine? The following requires
an interactive session, but only one program is needed and passwords are not
embedded in the source. The user is required to know their ops$userid
password on the remote machine. What follows is a program fragment of a
Pro*C program which logs on to a remote database.
#include <stdio.h>
#include <ctype.h>
#include <stdlib.h>
#include <string.h>
#define IBMC
EXEC SQL BEGIN DECLARE SECTION;
VARCHAR uid??(20??);
/* username */
VARCHAR pwd??(20??);
/* password */
VARCHAR constr??(20??); /* connect string */
long tcode; /* temp error code holder */
EXEC SQL END DECLARE SECTION;
EXEC SQL INCLUDE SQLCA;
main()
{
/* set up arrays to hold strings */
char usernm[20],usernm2[20] ,pword[20];
/* place ops$ in usernm
strcpy(usernm,"OPS$");
/* get the system login user id of the person, prompt for their
ops$password on the remote machine, do not echo the keystrokes
to the console place the user id and the password on the stack
*/
system("EXEC COVPASS");
/*read the stack into the values */
gets(usernm2);
gets(pword);
/* concatenate the userid to ops$ */
strcat(usernm,usernm2);
/* load CONNECT USERID AND USING VALUES
strcpy(uid.arr,usernm);
uid.len = strlen(uid.arr);
strcpy(pwd.arr,pword);
pwd.len = strlen(pwd.arr);
strcpy(constr.arr,"T:xxx.xx.xx.xx:");
constr.len = strlen(constr.arr);
/* CONNECT TO THE DATABASE */
EXEC SQL WHENEVER SQLERROR GOTO errexit;
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd USING :constr;
the above fragment will not run on its own but can me merged into a Pro*C
program.
My local machine is a 3090 runnig VM/CMS and the remote is a Microvax
running VMS. The program is written in c370, and takes advantage of some
CMS features through a system call to a rexx exec.
for those with rexx the exec is
/* hiding passwords in 3gl */
/*get system userid */
logon = xname(userid)
/* place on stack */
push logon
/* get ops$ password on remote machine */
hidepass = "DOCONS"('INHIBIT','PASSWORD')
/* place on stack */
queue hidepass
/* return to C program
exit
NB DOCONS is a Rexx library function, I'm not sure if its available
everywhere, we got it from CERN. It prompts for input and does not echo
the response.
Although, this example is VM based the same strategy can be used on other
systems. The strategy being
get the system login id
concatenate that with ops$
prompt for the ops$username password on the foreign machine
turn off keyboard echoing
place in appropriate strings, and use them to perform the login
Ian MacGregor [Stanford Linear Accelerator Center]
The above opinions are mine, and are not necessarily
those of the United States Department of Energy
nor Stanford University. They are not to be used for
promotional nor advertising purposesIAN@SLACVM.SLAC.STANFORD.EDU (12/13/90)
In article 90246.15077 I showed away of of logging on to oracle on a
remote database from a C program. The user will not know that they
are in Oracle. What I forgot to mention is that explicit logins
are only required if you want to change information on the remote
database. Granting of "select" can be done through database links
and synonyms. Then when I'm logged on to my local ops$ account
I can access data on the remote machine. The database link does
the connection to the remote database, the user need not know what
is happening
Ian MacGregor [Stanford Lnear Accelerator Center
These opinions are mine, and are not necessarily
those of The United States Department Of Energy
nor Stanford University. They shall not be used
for promotional nor advertising purposes]srm@occrsh.ATT.COM (12/15/90)
>How to log on to an ops$ account on a remote machine? The following requires ^^^^^^^^ >an interactive session, but only one program is needed and passwords are not ^^^^^^^^^^^^^^^^^^^^^^ I have used similar type process in certain applications. For those applications that run "unattended" are the types that I was referring to. I don't want to have to hard-code the password for applications that connect to a remote machine where the local machine has no "DATABASE" physically residing on it (only a few executables such as "orasrv/tcptlisrv", "sqlplus" and "$ORACLE_HOME/bin/oracle"). Any suggestions here? -- Steven R. McMaster UNIX(R) mail: ...!uunet!att!occrsh!srm AT&T Network Systems Oklahoma City Works Any opinions expressed in the message above are srm@occrsh.att.com mine, and not necessarily AT&T's.
IAN@SLACVM.SLAC.STANFORD.EDU (12/17/90)
<I want to log on to a remote database where I do not have a local database
just a few utilities>
To the best of my knowledge this is not possible on the system you describe.
What you are requesting is to log on to the database with no password veri-
fication whats-so-ever. If your database server is connected to internet
you are allowing anyone (well actually any system manager to access your
data). In the near future this may be possible under VMS. Note I say may!
That's if I understand how proxy logins work!? But you will at least be able
to control the nodes which have access.
Ian MacGregor [Stanford Linear Accelerator Center
These opinions are mine and do not necessarily
reflect those of the United States Department of
Energy nor Stanford University. They are not to
be used for promotional nor advertising purposes]anderson@well.sf.ca.us (David E. Anderson) (12/18/90)
In article <90350.090721IAN@SLACVM.SLAC.STANFORD.EDU> IAN@SLACVM.SLAC.STANFORD.EDU writes: ><I want to log on to a remote database where I do not have a local database >What you are requesting is to log on to the database with no password veri- >fication whats-so-ever. If your database server is connected to internet >you are allowing anyone (well actually any system manager to access your >data). In the near future this may be possible under VMS. Note I say may! >That's if I understand how proxy logins work!? But you will at least be able You are correct. SQL*Net version 1.2 provides "proxy login" security control. This mechanism allows control over which nodes and which users can access the database over the net. The idea is that the server sysadmin can control remote users' access. Currently the server OS account which runs the shadow task (the user task on the server machine) determines the OPS$<userid>. If you create such an account any network user can invoke it because this is the account which /@t:node refers to, no matter which client node or account makes the request. This single-mindedness is replaced in 1.2 by a control file and a control language for access security. Thanks to Cyril Scott... ******************************************************************************** David E. Anderson, Redwood City, CA (415) 592-1101 Independent Database Consultant (formerly with Oracle kernel Support Group) anderson@well.sf.ca.us ******************************************************************************** First learn your horn and all the theory. Next develop a style. Then forget all that and just play. Charlie Parker [?]
toncha@attc.UUCP (Tony Chang) (12/19/90)
Hi everyone,
This letter is writen to thank anyone who had responded to the
question which Scott Levin and I posted to the "usenet" a few
weeks ago. The question is about using automatic login feature
of ORACLE.
The problem specifically was that when we tried to run sqlplus
using an automatic login account (OPS$ account) over a SUN
network featuring Ethernet and TCP/IP, an ORACLE error occured
indicating invalid username or password. The command and its
corresponding error messages are as the following:
SQL> CONNECT /@T:oracle_server:TEST_DB
ERROR: ORA-01017: invalid username/password; logon denied
The following command, however, worked.
SQL> CONNECT OPS$user1/user1_password@T:oracle_server:TEST_DB
After we received responses from you guys, we were very excited
and were very confident that this problem is definitely
solvable even though there is some indications from a couple of
responses showing that this can not be done.
We eventually found out what our problems were and had corrected
them. The problems were
1. the file permission and ownership of 'orasrv' under
$ORACLE_HOME/bin subdirectory is not set correctly.
According to the ORACLE SQL*Net TCP/IP Manual, 'orasrv'
should be owned by "root" and should have the permission
"4555". We had our 'orasrv' owned by "oracle_dba" and
have permissoin "555".
2. /etc/hosts on the client node did not have the server's
Internet address listed.
We are not sure about if the second item is a factor since we
have "Yellow Page" running on the network which has all addresses
of the nodes connected. But we added the server address to the
file anyway.
Thank all of you for your generousity on sharing valuable
knowledge on this matter. We have been puzzled by this problem
for quite a long time, and are very pleased to have it resolved.
If any of you has similiar problems, please check the above two
things first. They might be helpful. If you need any more
information regarding this matter, please feel free to contact
Scott or me. Scott's e-mail address is
scolev@auto-trol.com
-----------------------------------------------------------------
Tun-Lian (Tony) Chang Phone : (303) 252-2029
Marketing & Applications Fax : (303) 252-2249
Auto-trol Technology Corporation email : toncha@auto-trol.com