Re: Password Sync Oracle/Unix within Oracle proc?

Mike Dodd <doddme_at_-remove-mindspring.com> wrote in message news:<3abod.26603$NC6.18210_at_newsread1.mlpsca01.us.to.verio.net>...
> On Sat, 20 Nov 2004 12:06:30 -0600, Sybrand Bakker wrote
> (in article <tn1vp0139m8b4t0gfd3jdkl87e9jo0udp9_at_4ax.com>):
>
> > On Sat, 20 Nov 2004 09:19:06 -0600, Mike Dodd
> > <doddme_at_-remove-mindspring.com> wrote:
> >
> >> We have an application which requires that the Unix and Oracle passwords
> >> match. The application (apparently) stores the password and uses it for
> >> Unix shell scripts and running scripts from the command prompt (all behind
> >> the scenes).
> >
> >
> > Sadly, there is no need for that, as Oracle has O/S authentication. In
> > this case any user with an Oracle account 'externally identified' and
> > the same name as their Unix account will get in without password.
> > So the procedure the app enforces is crap.
> >
> > Also, apparently it is too cumbersome for you to mention version and
> > the rest of the answer is version dependent.
> >
> >
> > --
> > Sybrand Bakker, Senior Oracle DBA
>
>
> Sorry, the app in this case is Oracle Clinical. The Oracle Server release
> version is 9.0.3, and the Application release is 4.5
>
> We're aware of the 'externally identified' option (OS_AUTHENTICATION).
> The Application runs several processes outside Oracle and connects back
> using the Oracle Password, runs scripts using the same password in Unix. The
> Oracle account must have a password because of the way this particular
> application works. We're kind of stuck using this app because it's
> validated and we're in a regulated environment.
>
> We had another (crap) application (Password Manager) that we used to sync the
> two, but they don't support unix anymore. It really was a stinker of an
> application, and maybe it's time we moved off of it.
>
> It may be a moot point, I know the OC application provides a tool to sync the
> unix/oracle passwords, but there was some problem with it. We're going
> to re-visit this.
>
> I was hoping that once the user came into the 'app' they might be able to
> change their unix password through a procedure. At first I didn't see it as
> that big of a deal, I can email, ftp, open/read/write/close files, etc, I
> thought running an executable might be just another option I missed.
> Apparently, it's not such a small deal after all.
>
> I'm not the primary on this particular application, so I may have a few
> details wrong (sorry), but the primary has no usenet access, I thought I'd
> do a favor and ask the group nicely if there were any tools to allow us to
> change the password from within a procedure.

There is a program your sysadmins probably know about called sudo. You could write a shell script to run passwd, and submit it to sudo to actually run, with the procedure controlling when to run it (in a couple of ways), or just use the shell script to syncronize the passwords manually. The advantage of sudo is it keeps control of security under root, except where explicitly delegated, and the execution is logged.

How can anyone not have usenet access these days? They've got to have browser access to just about any vendor for support...

>
> Sorry if I caused a stir.

jg

--
@home.com is bogus.
On usenet, everyone has Asperger's syndrome. 
http://www.mailtown.org/geeklog/article.php?story=20040210123049113