This process (of identifying service accounts) and of changing their passwords (and of generating random passwords for that) is very well documented and simple to do.
I cover all part of this on my blog, I believe that the Scripting Guys do as well, and so does cwashington on his website. (And we all have slightly different solutions. Pick your favorite!) -----Original Message----- From: Scott Kaufman at HQ [mailto:[email protected]] Sent: Wednesday, March 04, 2009 5:36 PM To: NT System Admin Issues Subject: RE: Password Policy Change I agree in principal with Michael, but the reality of changing service accounts that often can incur a very high management overhead, unless you have a well documented/scripted/automated solution in place that can change the password on the accounts, bounce the services & verify everything is hunky-dory. I've not looked for this solution, and have skimmed marketing material that this is possible. I also would assume the same as Kurt, rainbow tables & pass-the-hash if the previous employee had access to the password hash. Far more serious IMO, is where the employee might have made a copy of the service account username/password, and the system is exposed to the internet. When I make a service account, I set the password to at least 16 characters, which should force AD to not store the NTLM hash, & make the password a complete jumble of random ASCII characters. Then I deny TS logon & dial-in access. On occasion I've even gone so far as to specify which computers that account can logon to. Scott Kaufman Lead Network Analyst ITT ESI, Inc. -----Original Message----- From: Kurt Buff [mailto:[email protected]] Sent: Wednesday, March 04, 2009 4:10 PM To: NT System Admin Issues Subject: Re: Password Policy Change I was only thinking about the standard user base, but I think I agree. Elucidate your thoughts? *Every* employee termination, or only upon termination where the employee/manager had access to privileged accounts? I assume that you're thinking about rainbow tables and pass-the-hash attacks. On Wed, Mar 4, 2009 at 12:29, Michael B. Smith <[email protected]> wrote: > I think that's fine as long as you change the passwords on any > higher-privilege accounts upon every employee termination, managerial change, > or every two weeks and review the need-to-know of those passwords on a > regular basis. > > I am one of a relatively small (but growing) contingent who believes that any > higher-privilege account (including service account) should be changed far > more frequently than a low-privilege/normal-user account. > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Wednesday, March 04, 2009 2:49 PM > To: NT System Admin Issues > Subject: Re: Password Policy Change > > If the account was created more than 60 days ago, setting this policy > will force a password change at next logon. > > If the account was created less than 60 days ago, setting this policy > will force a password change when the account reaches 60 days. > > FWIW, I don't like a 60 day period. If I had my druthers, I'd enforce > a very long password (greater than 16 characters) and force the > password change at 180 or 365 days. This is spite of rainbow tables > and pass-the-hash attacks. > > Kurt > > On Wed, Mar 4, 2009 at 07:51, John Hornbuckle > <[email protected]> wrote: >> Right now, our users' passwords don't expire. We're looking at changing that. >> >> My question is this... If I decide to enable password expiration, how is the >> expiration date calculated for my users? >> >> Let's say that today I set passwords to expire every 60 days. Will all >> current users' passwords expire 60 days from today? Or will all current >> users' passwords expire today, if those passwords are 60 days or older? >> >> >> >> John Hornbuckle >> MIS Department >> Taylor County School District >> 318 North Clark Street >> Perry, FL 32347 >> >> www.taylor.k12.fl.us >> >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>���~ >> >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>���~ > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/�� ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
