Re: password expiration policy for admin and system accounts ?
From: Joe Richards [MVP] (humorexpress_at_hotmail.com)
Date: 10/25/05
- Next message: Steven L Umbach: "Re: Bypass Domain GPO when not connected to network?"
- Previous message: Eddy - MCSE: "Re: password expiration policy for admin and system accounts ?"
- In reply to: Brad Baker: "Re: password expiration policy for admin and system accounts ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 25 Oct 2005 13:24:07 -0400
My main experience with this area was global 5. Thousands of servers, hundreds
of thousands of clients, uncounted apps, etc.
You have to take the hardline or else it never gets fixed. When I was ops I
would force passwords over a year to be expired if the IDs were set up to be
non-expiring. Up to the app folks to get it straightened out. Possibly we might
give an extension but that always ended up instead being a reprieve from doing
work and they would get expired later when their extension expired anyway.
When someone comes forth and asks for an application ID (you do require
application reviews right and you don't just let people create new app IDs in a
unmonitored fashion) one of the first questions I have is how are you going to
handle not being able to have a non-expiring ID. If they said they couldn't run
that way, it had to be non-expiring they got to fill out all sorts of paperwork
and deviation documentation so we could chase them later when that password
wasn't changed. Don't ever let someone think that getting a non-expiring ID
means that it doesn't get changed. If you allow that, you might as well just
shut off password expiration in general, it is child's play to locate those IDs
and start hacking against them. In all of the audits I have done the passwords
on shared accounts (generic or application IDs they may be called) were either
documented, self-documenting, or easy to figure out. Often I have seen these
non-expiring IDs that people don't want to change broadcast in the clear in
network traces when people use them for telnet or ftp or simple LDAP binds or
other clear text protocols. If a service ID is used for clear text broadcasting
like that I actually want people changing the password after every transaction,
not just every 90 days or something like that.
The idea is when developing an application or system to figure this problem out
up front. If you are a system integrator, make sure this problem is figured out
by the application builder, if it isn't, it is YOUR job to figure it out. It is
not operations or the admins that have to work this out, that isn't their job.
The best services have some sort of mechanism to avoid using accounts altogether
to communicate between instances on different servers (look at DNS or WINS or
other systems that share info but don't use IDs) or automatically and frequently
change the password and no person ever knows it.
-- Joe Richards Microsoft MVP Windows Server Directory Services www.joeware.net Brad Baker wrote: > We face a similar problem. We would like to change several of our > administrative passwords but are concerned about the problems that will be > created as a result. We have legacy applications as well as services and > scheduled tasks that use various administrative accounts. Changing the > passwords on the accounts that run those applications/services/tasks would > likely result in dozens of services, tasks and programs not working. > > > > Even if we managed to go through and find every place to update the password > throughout our infrastructure there is some concern that some of the updates > may not take effect. For instance, during the installation of our old > exchange server, the wrong password was specified for an administrative > account which starts several key exchange services. Updating the password in > the services applet did not fix this problem. Thus every time the exchange > server was rebooted several exchange services would not automatically start > until an admin re-entered the password and manually startup the services. If > this happened to other applications because of a password change, it would > be a nightmare. > > > > Thankfully our admin passwords are quite complex but it is disconcerting > that we do not feel confident that changing them would not cause major > disruption. I'd also welcome feedback from anyone who has done this in an > enterprise environment (I.E. 30+ servers running many different server > applications such as SQL, IIS, Exchange, backup software, legacy apps etc) > > > > > > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message > news:uvO65Wd1FHA.1564@tk2msftngp13.phx.gbl... > >>Hell I would and do object as well. >> >>http://blog.joeware.net/2005/05/08/10/ >> >>-- >>Joe Richards Microsoft MVP Windows Server Directory Services >>www.joeware.net >> >> >>JJ wrote: >> >>>Our auditors are objecting to our having Domain Administrator and domain >>>system accounts with passwords that never expire. >>> >>>Yes, we change some of these passwords from time to time, but they're >>>normally set to never expire. >>> >>> >>>We are wondering about how other companies do it, since we've never heard >>>of >>>any IT Dept. that had such a policy, and we think the auditors are being >>>unreasonable -- forcing password expiration on such accounts could be a >>>logistical nightmare as it would cause critical services to stop running. >>> >>>We're not that big, but we do have about 30 servers and 200 users to >>>support. There's only 1 Win2K domain, with Exchange 2K, SQL and other >>>resource servers. >>> >>>Please post your experiences and opinions. >>> >>>Thanks. >>> > >
- Next message: Steven L Umbach: "Re: Bypass Domain GPO when not connected to network?"
- Previous message: Eddy - MCSE: "Re: password expiration policy for admin and system accounts ?"
- In reply to: Brad Baker: "Re: password expiration policy for admin and system accounts ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
