sybrandb_at_hccnet.nl wrote:
> On Fri, 03 Aug 2007 23:58:34 -0700, DA Morgan <damorgan_at_psoug.org>
> wrote:
>
>> EdStevens wrote:
>>> On Aug 3, 3:05 pm, DA Morgan <damor..._at_psoug.org> wrote:
>>> <snip>
>>>
>>>> I am not aware of a single Oracle password that can not be changed at
>>>> will provided you haven't hard coded it into shell scripts and the like.
>>>> And if you have fix the scripts.
>>>> --
>>>> Daniel A. Morgan
>>>> University of Washington
>>>> damor..._at_x.washington.edu (replace x with u to respond)
>>>> Puget Sound Oracle Users Groupwww.psoug.org
>>> True. What I'm looking for here is where those hard-coded locations
>>> might be for *oracle created* accounts. I've found documentation on
>>> MetaLink for DBSNMP, SYSMAN, and now MGMT_VIEW that require mods to
>>> some config files in addition to the simple ALTER USER .... Just
>>> don't want to overlook any.
>>>
>>> Have already locked accounts that the "home office" says are not
>>> needed, and turned on session auditing for use of CREATE SESSION on
>>> those accounts.
>> The hard coded locations are irrelevant if you've done the basics.
>>
>> Set RESOURCE_LIMIT = TRUE in your spfile.
>> Alter the default profile to force password complexity.
>> Alter the default profile to force password expiration.
>> Change every password on an unlocked account.
>> Anything that doesn't work ... you'll know why.
>>
>> Why not look for the hard-coded locations first? Because stupid people
>> do stupid things. There is no logic ... there is no rhyme or reason. The
>> first responsibility is to protect the data not people's egos.
>
> The OP should read the article 'Project Lockdown' on
> http://otn.oracle.com written by Arup Nanda, and notice he needs to
> address way more.
Good point.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Received on Sat Aug 04 2007 - 08:45:21 CDT
