Is checking the source IP in a trigger reliable? I do not recall the source, but I had the impression that that information is provided (directly) by the client, not by the TNS listener, and can (relatively) easily be spoofed. Also, the method would break down -- or be tricked -- when using "proxied" connections, e.g., port-forwarding through SSH, or possibly Oracle Connection Manager. (Never used the latter myself.) It would also be problematic if there are NAT-enabled firewalls anywhere along your network route. Every case needs to be judged on its own merits, but basically it is my practice to award REMOTE_OS_AUTHENTICATION=TRUE an *automatic* "Fail" on any security review, even (or especially) where there are no EXTERNALLY IDENTIFIED accounts present in the database. While I have never actually attempted to "hack" or "spoof" it, my understanding is that it is all too easy. For those who can afford it, though, the Advanced Security Option and/or Database Vault offer secure alternatives, I believe. I have stumbled across these options myself while answering similar questions, but it has been so many years since I've been at a site with pockets deep enough (or business needs serious enough) to actually consider these expensive options, I have never really investigated them in any real depth. *sigh* Working for regulated utilities *did* have its advantages... :-) Of course, the O.P. only asked "is this possible?", and the answer is "yes, it certainly is". What a shame he did not ask instead "is this wise?". :-) On Tue, Mar 4, 2008 at 12:02 PM, Powell, Mark D <mark.powell@xxxxxxx> wrote: > > I have always preferred to set the os_authent_prefix='' rather than > OPS$. > > I am not sure if trying to limit the node access is practical since I do > not think the node checking can be associated to usernames in the sqlnet > layer. You might need to resort to checking the IP for any OS > authenticated accounts in an after logon database event trigger. > > > -- Mark D Powell -- > Phone (313) 592-5148 > > > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of QuijadaReina, Julio > C > Sent: Tuesday, March 04, 2008 9:52 AM > To: 'mdemenko@xxxxxxxxx'; joe_dba@xxxxxxxxxxx > Cc: oracle-l@xxxxxxxxxxxxx > Subject: RE: os authenticated accounts > > Yes, it is possible. > The following parameters on your database init.ora relating to this are > (if my memory serves me correctly): > remote_os_authent=true > os_authent_prefix=ops$ > > Create the account you will use on your Linux box. Then create the > externally identified account on your database. From your Linux client > you should be able to connect by issuing 'sqlplus /' after setting the > client environment. > > A word of caution: anyone knowing your database tnsnames and the name of > the account could potentially connect to your database. That sounds > pretty bad! You might want to look into tcp.validnode_checking and > tcp.invited_nodes pars on your server's sqlnet.ora and/or have the OS > firewall setting that opens the listener port only to your linux client. > > Julio > > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Maxim Demenko > Sent: Tuesday, March 04, 2008 1:05 AM > To: joe_dba@xxxxxxxxxxx > Cc: oracle-l@xxxxxxxxxxxxx > Subject: Re: os authenticated accounts > > Joe Smith schrieb: > > Is it possible to use OS authenticated accounts ( i.e. identified > > externally ) between two servers? > > > > I have a linux box with with an oracle client install and an aix > > server with EE installed. > > > > The external account was originally on the aix server. We want to > > move the 3rd party app and the account to a linux box. > > > > thanks. > > > > > > ---------------------------------------------------------------------- > > -- Shed those extra pounds with MSN and The Biggest Loser! Learn more. > > <http://biggestloser.msn.com/> > You may look on the external users identified by ssl certificates (if > you are on 10g onwards). > Not sure about additional licensing costs (i.e. whether it is part of > ASO or not). > > Best regards > > Maxim > -- > //www.freelists.org/webpage/oracle-l > > > -- > //www.freelists.org/webpage/oracle-l > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Cheers, -- Mark Brinsmead Senior DBA, The Pythian Group http://www.pythian.com/blogs