Warning: iconv_mime_decode() [function.iconv-mime-decode]: Malformed string in /home/secureg/public_html/lib/standard.lib.php on line 2251
Service accounts with password expiration
Service accounts with password expiration

Service accounts with password expiration
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Service accounts with password expiration Carlos Felipe França da Fonsec 08-15-2008
Posted by Carlos Felipe França da Fonsec on August 15, 2008, 2:36 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


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



Posted by S. Pidgorny on August 15, 2008, 9:12 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


G'day, answerrs inline:


> 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/security/guidance/serversecurity/serviceaccount/default.mspx

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

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



Posted by Special Access on August 18, 2008, 7:36 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


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

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

Posted by =?Utf-8?B?RGFu?= on August 19, 2008, 6:41 am
If you were  Registered and logged in, you could reply and use other advanced thread options


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

Posted by Roger Abell [MVP] on August 19, 2008, 10:54 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


> On Fri, 15 Aug 2008 23:37:46 -0700, "Roger Abell [MVP]"
>
>>> 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



Similar ThreadsPosted
password expiration policy for admin and system accounts ? October 19, 2005, 6:29 pm
On password expiration March 31, 2006, 1:51 am
network service accounts HKCU access December 21, 2005, 4:22 pm
Server or Service Accounts complete lockdown? February 13, 2006, 3:41 pm
Service Accounts & Account Lock out Policy February 15, 2007, 3:41 am
Password Expiration for Remote Users March 16, 2006, 1:07 pm
Remote users and Password expiration October 10, 2006, 11:30 am
No password expiration alert when smart card logon is required December 27, 2005, 1:14 pm
NETWORK and NETWORK SERVICE accounts April 21, 2006, 10:05 am
change service password December 13, 2006, 3:17 am

The site map in XML format XML site map

Contact Us | Privacy Policy