RE: Oracle lockdown, agents, and EM Jobs

From: Herring, David <HerringD_at_DNB.com>
Date: Wed, 18 Jun 2014 21:35:31 -0500
Message-ID: <AD8FE6616C097545A4C9A8B0792909AC38383FE01A_at_DNBEXCH01.dnbint.net>

Tony, good idea and it's relatively similar to another suggestion from Jackie.

The credentials issue is a tough one that I currently don't see a way around. The good news is changing credentials wholesale is pretty easy with "emcli" and for the most part I have that scripted for nearly all credential sets. We had a few UDMs on our first EM that was converted, so I've got that one-off covered now. I'm not only dealing with various target releases but even with EM releases.

Dave Herring
Database Administrator
OracleSysDBA Group

Cel:    630.441.4404
Office:973.605.6619
Eml:    HerringD_at_dnb.com

-----Original Message-----
From: De DBA [mailto:dedba_at_tpg.com.au] Sent: Wednesday, June 18, 2014 7:59 PM
To: Herring, David
Cc: oracle-l_at_freelists.org
Subject: Re: Oracle lockdown, agents, and EM Jobs

This is becoming a very interesting story indeed. How about putting the common oracle environment in a file in a common location, e.g. /var/opt/oracle/oraenv.sh, and having each script and perhaps .bashrc/.bash_profile source that as appropriate? Access to this directory should already be allowed. We tend to do this, even where security is not as overzealous as what you're facing. It just makes managing environments more easy when everything is in one common location, whilst allowing DBAs to choose whether to use the common environment or not.

I wonder how you are going to set up EM jobs that need os logon credentials. If you use a DBA's credentials, then those jobs will start to fail when the DBA in question leaves the organisation and his account gets disabled or removed from the directory.. Could be an administrative nightmare waiting to happen?

Cheers,
Tony

On 19/06/14 08:18, Herring, David wrote:
> Options:
>
> 1) Every DBA has their own .bash_profile created as a copy of Oracle's. This is what I started with thinking it was simple but after one week I've found 2 examples where DBAs didn't bother to follow this rule. I can't control them and have no authority to force them to do anything other than the bare minimum of their job.
>
> 2) Open permissions on /user/oracle (710) and /user/oracle/.bash_profile (750) so that each EM Job could issue at the start: ". ~oracle/.bash_profile". So whether daveh or markb or timg have their credentials set for the target, all can execute Oracle's .bash_profile and we're fine.
>
> Everything else I've come up with is a variation on the above 2 options, either modifying DBA .bash_profiles in some way or something within Oracle's home directory that requires permissions to be relaxed a bit.
>
> Does this make sense?
>
> Am I making this overly complex?
>
> Anyone else in a similar situation and have a better solution?
>
> Dave Herring
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Jun 19 2014 - 04:35:31 CEST