Service accounts with password expiration

[Guest 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

[Guest 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...<span style="color:blue">

> The corporate auditing requires that all accounts' passwords expire,

> including service accounts. Questions:

>

> 1. Is it really a security recommendation?</span>

 

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.

<span style="color:blue">

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

> example)?</span>

 

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).

<span style="color:blue">

> 2. If a modify the password in the service settings, will this one keep

> running with no disruption?</span>

 

You shoudn't count on that.

<span style="color:blue">

> 3. If I modify passwords for clustering service accounts, will those ones

> keep running with no disruption?</span>

 

You shoudn't count on that either.

 

Some guidance from MS:

 

http://www.microsoft.com/technet/security/...nt/default.mspx

 

--

Svyatoslav Pidgorny, MS MVP - Security, MCSE

-= F1 is the key =-

 

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

[Guest Roger Abell [MVP]]

"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in

message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...<span style="color:blue">

> The corporate auditing requires that all accounts' passwords expire,

> including service accounts. Questions:

>

> 1. Is it really a security recommendation?</span>

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.

<span style="color:blue">

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

> example)?</span>

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).

<span style="color:blue">

> 2. If a modify the password in the service settings, will this one keep

> running with no disruption?</span>

depends; with restart the restart should be the only disruption

<span style="color:blue">

> 3. If I modify passwords for clustering service accounts, will those ones

> keep running with no disruption?</span>

ditto

 

Roger

[Guest Special Access]

On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"

<mvpnospam@asu.edu> wrote:

<span style="color:blue">

>"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in

>message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...<span style="color:green">

>> The corporate auditing requires that all accounts' passwords expire,

>> including service accounts. Questions:

>>

>> 1. Is it really a security recommendation?</span>

>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.

><span style="color:green">

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

>> example)?</span>

>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).

><span style="color:green">

>> 2. If a modify the password in the service settings, will this one keep

>> running with no disruption?</span>

>depends; with restart the restart should be the only disruption

><span style="color:green">

>> 3. If I modify passwords for clustering service accounts, will those ones

>> keep running with no disruption?</span>

>ditto

>

>Roger

></span>

 

 

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

[Guest 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:

<span style="color:blue">

> On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"

> <mvpnospam@asu.edu> wrote:

> <span style="color:green">

> >"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in

> >message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...<span style="color:darkred">

> >> The corporate auditing requires that all accounts' passwords expire,

> >> including service accounts. Questions:

> >>

> >> 1. Is it really a security recommendation?</span>

> >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.

> ><span style="color:darkred">

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

> >> example)?</span>

> >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).

> ><span style="color:darkred">

> >> 2. If a modify the password in the service settings, will this one keep

> >> running with no disruption?</span>

> >depends; with restart the restart should be the only disruption

> ><span style="color:darkred">

> >> 3. If I modify passwords for clustering service accounts, will those ones

> >> keep running with no disruption?</span>

> >ditto

> >

> >Roger

> ></span>

>

>

> 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

> </span>

[Guest Roger Abell [MVP]]

"Special Access" <nonyabidnezz@hotmail.com> wrote in message

news:om1ka4dbpj4pivf85tc5t0stje0e01985i@4ax.com...<span style="color:blue">

> On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"

> <mvpnospam@asu.edu> wrote:

><span style="color:green">

>>"Carlos Felipe França da Fonseca" <carlosfelipefranca@gmail.com> wrote in

>>message news:Oz9EVXw$IHA.4760@TK2MSFTNGP03.phx.gbl...<span style="color:darkred">

>>> The corporate auditing requires that all accounts' passwords expire,

>>> including service accounts. Questions:

>>>

>>> 1. Is it really a security recommendation?</span>

>>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.

>><span style="color:darkred">

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

>>> for

>>> example)?</span>

>>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).

>><span style="color:darkred">

>>> 2. If a modify the password in the service settings, will this one keep

>>> running with no disruption?</span>

>>depends; with restart the restart should be the only disruption

>><span style="color:darkred">

>>> 3. If I modify passwords for clustering service accounts, will those

>>> ones

>>> keep running with no disruption?</span>

>>ditto

>>

>>Roger

>></span>

>

>

> 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</span>

 

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

[Guest Alun Jones]

"Special Access" <nonyabidnezz@hotmail.com> wrote in message

news:om1ka4dbpj4pivf85tc5t0stje0e01985i@4ax.com...<span style="color:blue">

> 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</span>

 

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.

[Guest Anteaus]

"Alun Jones" wrote:

<span style="color:blue">

> 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.</span>

 

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.

[Guest Alun Jones]

"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message

news:7C2610AD-9FA5-49EE-A981-C052D9B25C5E@microsoft.com...<span style="color:blue">

>

> "Alun Jones" wrote:

><span style="color:green">

>> 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.</span>

>

> 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.</span>

 

<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".

<span style="color:blue">

> 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.</span>

 

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.

<span style="color:blue">

> 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.</span>

 

I didn't say that this was my argument.

<span style="color:blue">

> 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.</span>

 

Disused accounts should be disabled. Password expiry isn't a good metric of

whether the account is disused and needs to be disabled.

<span style="color:blue">

> 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.</span>

 

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.

<span style="color:blue">

> 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.</span>

 

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)

style_emoticons/ 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.