Home page logo

educause logo Educause Security Discussion mailing list archives

Re: Service Account Security and Handling
From: Larry Brennan <larrybrennan () GMAIL COM>
Date: Wed, 8 Aug 2007 17:37:47 -0500

One suggestion would be to have the automated processes be authorized
(and performed) under a non-interactive ID. The non-interactive is an
ID is only to be used by individual processes and not for routine
logon by individual users. Additionally, these IDs would have their
passwords set to never expire so you don't have to worry about the 90
day expiration issue.. To help mitigate risks from the password
expiration issue, you can restrict what this ID can acess, and log the
living daylights of all activity related to that ID.

If you are not willing to rework all of those existing processes for
the new ID(s), you could start to change how you deploy these
processes in the future - so you don't get any further into the hole,
so to speak.

Best regards,
Larry Brennan

On 8/8/07, Wade, Russ <Russ.Wade () wichita edu> wrote:
Dear Colleagues,

I am interested in accepted practices for maintaining passwords and access
to service accounts.

We have several Oracle accounts with broad access to the database that are
used by automated processes.  The passwords for these are known by the DBA
and a small number of lead programmers who developed and provide technical
support for these processes.

We presently are using a profile which requires the passwords for these
accounts to change every 90 days.  Most of the time, the DBA and involved
developer successfully coordinate the password change in Oracle and in the
application process before the 90 day limit.

However, this sometimes is missed and the automated processes fail.  We have
also experienced issues with automated processes which must have embedded
passwords being missed when the change is made.  This can result in getting
the service account locked after they retry with the old password beyond our
6 try limit.  Then, the other processes fail as well until someone notices
and fixes it.

Does anyone have a better idea for how to achieve proper security for these
privileged access service accounts and operational reliability as well?
Also, please describe the roles of the individuals involved with this

Thank you,


Russ Wade,

Banner Security Specialist

Wichita State University

University Computing and Telecommunications Services

1845 Fairmount

Wichita, KS  67260-0098


Russ.Wade () Wichita edu<mailto:Russ.Wade () wichita edu>


(316) 978-3859


(316) 312-0185


(316) 978-3894

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]