Carlos Felipe França da Fonseca

The corporate auditing requires that all accounts' passwords expire,
including service accounts. Questions:

1. Is it really a security recommendation?
2. Is there an easy way to automate this process (as a scheduled task, for
example)?
2. If a modify the password in the service settings, will this one keep
running with no disruption?
3. If I modify passwords for clustering service accounts, will those ones
keep running with no disruption?

Thanks,

Felipe

S. Pidgorny

G'day, answerrs inline:


"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in
message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...
> The corporate auditing requires that all accounts' passwords expire,
> including service accounts. Questions:
>
> 1. Is it really a security recommendation?

No, that's an audit recommendation. It doesn't seem to take into account any
operatioonal or quantifiable risk considerations. Accounts with non-expiring
passwords can still be sufficiently secure.

> 2. Is there an easy way to automate this process (as a scheduled task, for
> example)?

Sure, you can script passsword change and service restart. Then the password
change service/task needs to be sufficiently secured, as it gives access to
all your service accounts (and therefore likely to all SQL server data and
all Exchange data among aother things).

> 2. If a modify the password in the service settings, will this one keep
> running with no disruption?

You shoudn't count on that.

> 3. If I modify passwords for clustering service accounts, will those ones
> keep running with no disruption?

You shoudn't count on that either.

Some guidance from MS:

http://www.microsoft.com/technet/sec...t/default.mspx

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

Roger Abell [MVP]

"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in
message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...
> The corporate auditing requires that all accounts' passwords expire,
> including service accounts. Questions:
>
> 1. Is it really a security recommendation?
Recommendation from whom? There are likely those saying so.
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, for
> example)?
Only with care.
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 keep
> running with no disruption?
depends; with restart the restart should be the only disruption

> 3. If I modify passwords for clustering service accounts, will those ones
> keep running with no disruption?
ditto

Roger

Special Access

On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"
<mvpnospam@asu.edu> wrote:

>"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in
>message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...
>> The corporate auditing requires that all accounts' passwords expire,
>> including service accounts. Questions:
>>
>> 1. Is it really a security recommendation?
>Recommendation from whom? There are likely those saying so.
>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, for
>> example)?
>Only with care.
>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 keep
>> running with no disruption?
>depends; with restart the restart should be the only disruption
>
>> 3. If I modify passwords for clustering service accounts, will those ones
>> keep running with no disruption?
>ditto
>
>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

Dan

True, True and then you have users who copy passwords on sticky notes and
circumvent the best safety and security procedures of the company and it is
probably because of the user's frustration instead of maybe copying the
password in an encrypted file with say 448 bit+ Blowfish encryption for a
start.

"Special Access" wrote:

> On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"
> <mvpnospam@asu.edu> wrote:
>
> >"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in
> >message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...
> >> The corporate auditing requires that all accounts' passwords expire,
> >> including service accounts. Questions:
> >>
> >> 1. Is it really a security recommendation?
> >Recommendation from whom? There are likely those saying so.
> >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, for
> >> example)?
> >Only with care.
> >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 keep
> >> running with no disruption?
> >depends; with restart the restart should be the only disruption
> >
> >> 3. If I modify passwords for clustering service accounts, will those ones
> >> keep running with no disruption?
> >ditto
> >
> >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
>

Roger Abell [MVP]

"Special Access" <nonyabidnezz@hotmail.com> wrote in message
newsm1ka4dbpj4pivf85tc5t0stje0e01985i@4ax.com...
> On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"
> <mvpnospam@asu.edu> wrote:
>
>>"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in
>>message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...
>>> The corporate auditing requires that all accounts' passwords expire,
>>> including service accounts. Questions:
>>>
>>> 1. Is it really a security recommendation?
>>Recommendation from whom? There are likely those saying so.
>>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,
>>> for
>>> example)?
>>Only with care.
>>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 keep
>>> running with no disruption?
>>depends; with restart the restart should be the only disruption
>>
>>> 3. If I modify passwords for clustering service accounts, will those
>>> ones
>>> keep running with no disruption?
>>ditto
>>
>>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

Alun Jones

"Special Access" <nonyabidnezz@hotmail.com> wrote in message
newsm1ka4dbpj4pivf85tc5t0stje0e01985i@4ax.com...
> 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

How about I offer a different opinion?

Requiring service passwords to change on a regular basis is an operational,
reliability _and_ security requirement.

I'll relate an incident, if I may, that actually occurred.

A photocopied sheet of paper was found, with a list of account names and
passwords. It had obviously fallen out of someone's pocket or wallet without
them noticing.

The account names were all service accounts, and because of requirements of
the services being run, these accounts were very highly-privileged accounts.
The passwords were all somewhat strong (they certainly weren't twenty
characters of random gibberish, but they weren't dictionary words with
obvious numerical substitutions either), which is why they had to be written
down.

Obviously, the first step here was to immediately change the passwords
(followed by some 'education' for the team who had access to those
passwords).

How quickly were those passwords changed, do you think? Inside of 24 hours?
A week?

No, try sixty days later.

The reasoning was this - those passwords had to be synchronised across
several applications, and the teams involved didn't have any process or plan
or even a set of instructions to work from as to how to synchronise these
passwords.

Why?

Because they hadn't changed the passwords in four years. They didn't know
what was going to be affected if they screwed up the change, or how many
systems they had to look into changing.

Requiring regular changes to account passwords ensures that you have the
processes in place to ensure that those password changes can be made in a
smooth and ordered fashion when you actually do have to make a change.

It's almost like a disaster recovery exercise - "suppose we had a security
exposure on this account, and had to change the password in a hurry, how
quickly could we do it, and would we wind up accidentally bringing anything
down as a result?"

So, whereas we require users to change their passwords every quarter because
they tend to share passwords even when told not to, we require services to
change their passwords every quarter so that when a security incident comes
along (and one will), we can swiftly and smoothly bring ourselves back into
a secure state without having to panic, or having to delay the resumption of
security while we reassure ourselves that changing the password isn't going
to kill service.

Now, as for actually changing the passwords on a service account - in a
simple case, all you have to do is change the password in AD, change it in
the Service Control Manager's database, and then bounce the service.

In a more complex case, you may have these issues:
1. Kerberos Tickets assigned to the service's process for accessing remote
resources will be valid for up to ten hours, increasing the time available
to bounce the service, if Kerberos is the authentication in use.
2. The old password is accepted for network access to remote resources for
an hour after the password is changed, again giving you some time in which
to apply password changes and bounce the service.
3. You need to find all instances of the service running under a particular
domain account - this can take time if not automated.
4. The account used to start the service may also be used in other contexts
than simply the SCM logon, so you will have to track down and synchronise
those password changes, too.
5. If you have enabled account lockout on the account, and you forgot to
change passwords on one of the synchronisation points, you've just created a
nice denial of service condition on your important services. [Another great
reason to change them regularly, so you can avoid this]

If you don't change passwords regularly, how can you believe that you have a
process that will let you do it in a hurry should you need to do so?

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

Anteaus

"Alun Jones" wrote:

> A photocopied sheet of paper was found, with a list of account names and
> passwords. It had obviously fallen out of someone's pocket or wallet without
> them noticing.

If that happens, expiring the passwords every x days is about as much use as
putting the pin back in the grenade after it's exploded. The important thing
is to change the passwords NOW, and then take steps to ensure this doesn't
happen again. Using a 'password-safe' program is one option.

A key issue with expiring system-account passwords is the risk of backups
being blocked by the changes. This could lead to a catastrophic data-loss
situation, and is potentially a far greater risk than that of passwords being
misappropriated.

Password-expiry is a soapboxer's favorite rant, yet an application of the
Mk1 Brain to the situation discloses that it adds very little to security. If
a password is compromised, chances are that any malicious damage will be done
long before the password expires. Probably within minutes of the intrusion.
Also, changing the password (to another of equal strength) during a
brute-force attempt makes NO difference to the odds of the attack succeeding
or failing.

A further point, often misunderstood, is that password-expiry does NOT
prevent disused accounts from being resurrected for malicious purposes. This
is particularly a concern where the user had remote-access to the system.
Strangely, despite its faddist password rules, Windows 2003 still possesses
no mechanism for closing/suspending disused accounts, so there is a need for
diligence here.

The key to good security is to use strong, nondictionary passwords, and make
sure that staff take password-security seriously, and do not allow passwords
to be leaked through carelessness.

Alun Jones

"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
news:7C2610AD-9FA5-49EE-A981-C052D9B25C5E@microsoft.com...
>
> "Alun Jones" wrote:
>
>> A photocopied sheet of paper was found, with a list of account names and
>> passwords. It had obviously fallen out of someone's pocket or wallet
>> without
>> them noticing.
>
> If that happens, expiring the passwords every x days is about as much use
> as
> putting the pin back in the grenade after it's exploded. The important
> thing
> is to change the passwords NOW, and then take steps to ensure this doesn't
> happen again. Using a 'password-safe' program is one option.

<sigh> You're looking at the wrong end of the story.

The point was that "change the passwords NOW" was not an option, because
they'd _never_ changed the passwords _ever_, and so they'd gotten into a
situation where they were certain that they would bring down large portions
of the business by changing passwords on service accounts that were in use
in several locations.

[This was one of "those" services, where it's not just a service to start
and/or stop, it's also an account that's used to access an application, and
the application's authors hard-coded the account details to be the same for
the service account as for the application account, etc].

Because there had been no practice in changing the password, there were no
processes for changing the password.

Because there were no processes for changing the password, they had to build
that process before they could change the password.

So "change the passwords NOW" became "spend a few weeks defining the
process, testing it in a sample installation, and then finally get the
passwords changed".

> A key issue with expiring system-account passwords is the risk of backups
> being blocked by the changes. This could lead to a catastrophic data-loss
> situation, and is potentially a far greater risk than that of passwords
> being
> misappropriated.

If you have a process to change the passwords, along with a tool to follow
the process quickly and automatically, this should not be a problem.

If passwords expire without being noticed, you have a problem that is not
caused by password expiration.

> Password-expiry is a soapboxer's favorite rant, yet an application of the
> Mk1 Brain to the situation discloses that it adds very little to security.
> If
> a password is compromised, chances are that any malicious damage will be
> done
> long before the password expires. Probably within minutes of the
> intrusion.
> Also, changing the password (to another of equal strength) during a
> brute-force attempt makes NO difference to the odds of the attack
> succeeding
> or failing.

I didn't say that this was my argument.

> A further point, often misunderstood, is that password-expiry does NOT
> prevent disused accounts from being resurrected for malicious purposes.
> This
> is particularly a concern where the user had remote-access to the system.

Disused accounts should be disabled. Password expiry isn't a good metric of
whether the account is disused and needs to be disabled.

> Strangely, despite its faddist password rules, Windows 2003 still
> possesses
> no mechanism for closing/suspending disused accounts, so there is a need
> for
> diligence here.

The mechanism is simple - disable the account. The account can be re-enabled
by an administrator only. Are you saying that your administrator accounts
are compromised? If so, then you have a bigger problem than unused accounts.

> The key to good security is to use strong, nondictionary passwords, and
> make
> sure that staff take password-security seriously, and do not allow
> passwords
> to be leaked through carelessness.

And when they are discovered to be exposed, to have a process that allows
you to mitigate the exposure, by changing the password and issuing some
education to the team involved.

Without password expiry, how do you enforce the creation and testing of
password change processes?

Without password expiry, how do you enforce a changed password strength
policy?

Now, I will grant you that password expiry combined with account lockout
_tends_ to lead to accounts being locked out by services that haven't been
updated, but to my mind, that's:
a) yet another reason not to use account lockout (brute force guessing
should trigger alarms in other ways, rather than providing your more puerile
users the ability to deny one another's access to the system with a few
bashes of the keyboard)
b) another indication that you don't have a good process for password change
in your systems

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.