Re: Service accounts with password expiration
- From: "Roger Abell [MVP]" <mvpnospam@xxxxxxx>
- Date: Tue, 19 Aug 2008 19:54:57 -0700
"Special Access" <nonyabidnezz@xxxxxxxxxxx> wrote in message
news:om1ka4dbpj4pivf85tc5t0stje0e01985i@xxxxxxxxxx
On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"
<mvpnospam@xxxxxxx> wrote:
"Carlos Felipe França da Fonseca" <carlosfelipefranca@xxxxxxxxx> wrote in
message news:Oz9EVXw$IHA.4760@xxxxxxxxxxxxxxxxxxxxxxx
The corporate auditing requires that all accounts' passwords expire,Recommendation from whom? There are likely those saying so.
including service accounts. Questions:
1. Is it really a security recommendation?
In point of fact, I can make the password sufficently long and complex
that I would not worry about it being uncovered by brute methods, and
getting it from the service controller mem or safe is just as unlikely.
So, in my view, your question comes down to whether there are any
really determined adversaries or foolish people-ware in your world
that leave notes on the password(s) available. That is a correctable
practice as service account passwords generally can be (re)set and
then forever forgotten.
2. Is there an easy way to automate this process (as a scheduled task,Only with care.
for
example)?
There are the two (minimum) places to set the pwds (account+service).
These must be changed in atomic fashion (full error checking so both or
neither change is guaranteed)
One must decide whether to interrupt the service by restart or to rid it
out until the service recycles (which might cause issue depending on
what the service does and how).
The automation introduces the weakest storage of the password, and also
possibly its short-term visibility on some of the network.
The schedule task introduces a weakness as it might get hijacked for abuse
(or its script just read and what's learned used).
2. If a modify the password in the service settings, will this one keepdepends; with restart the restart should be the only disruption
running with no disruption?
3. If I modify passwords for clustering service accounts, will thoseditto
ones
keep running with no disruption?
Roger
Having come from an environment that required ALL passwords to be
changed every 60-90 days, it sux. I'm with Roger in that automation
is not the best way to go with this. We scheduled downtime for
whaterver service/account that needed to be changed, changed in AD,
then changed the service logon and bounced the service. You will know
ASAP if it was typed correctly <g>
And normally, this requirement comes from security folks that probably
NEVER touched equipment in their lives, let alone try to manage
maintaining a system for ungrateful users <g> and nagging managers who
want everything to pass security AND work! man, that's a tough
requirement at times heheheh
Mike
He, he ... Sometimes it is apparent that partial knowledge gets
combined with a large does of neck-leather safeguarding that goes
into defining the security audit hurdles. PITA but it is an effort and
better than the days mgmt would not invest staff time let alone money
in the name of securing systems.
Hopefully someday the impractical and the requirements that actually
fail to address real risks (except to neck-leaather) will get weeded out.
Roger
out
.
- References:
- Service accounts with password expiration
- From: Carlos Felipe França da Fonseca
- Service accounts with password expiration
- Prev by Date: Re: Preferred RootKit detection/removal tool?
- Next by Date: Re: Giving admins Local Admin to DC's not Domain Admins
- Previous by thread: Re: Service accounts with password expiration
- Next by thread: Re: Service accounts with password expiration
- Index(es):
Relevant Pages
|
