password expiration policy for admin and system accounts ?

[JJ]

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.

 

[Herb Martin]

Our auditors are objecting to our having Domain Administrator and domain
system accounts with passwords that never expire.

A generally legitimate objection.

Yes, we change some of these passwords from time to time, but they're
normally set to never expire.

And why should Admins with far more privileged and therefore
DANGEROUS accounts be allowed practices less safe and more
lazy than ordinary users?

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.

No, they are being reasonable.

Perhaps you issue is that you are using the same Admin
account for many admins?

Each admin should have a separate account for admin
purposes (so that auditing is specific.)

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.

Do it correctly and safely, and thank the auditors for encouraging
safe practices.

 

[Roger Abell [MVP]]

Privileged accounts should be the most, not the least, well guarded.
If your domain policy makes users change passwords each 60 days,
your admins and domain admins accounts should get their passwords
changed weekly (which means a human, not a machine enforced
practice). Changing the passwords is not so much a limiter on the
time available for cracking as it is a limiter on the length that a password
that has travelled beyond appropriate hands can be usable there.

You say changing service account passwords can cause critical services
to stop working. That is not really the case, with planning and doing the
right things at the right times. But, it can cause short-term
interruptions.
I feel most shops do not alter service account passwords on a regular
basis, but I could be a good practice to implement. If you look you will
notice that most services are not using custom accounts, which means
that it is not all that many that are impacted by the auditor's request.
For
some of these the accounts are domain, but the scope of the others, the
machine local service accounts (other than the built-in accounts local
system, local service, network service) are limited to that one box.
Perhaps you can arbitrate with the auditors on the frequence of change
based on the scope of the exposure, the difficulty of gettings to the boxes
to coordinate this, and, (this is the big one) your practice of using pass
phrases for those accounts that have a minimum length that is some
outrageously large size like 40 characters.

 

[JJ]

Thank you for your reply.

I would agree about the admin account, but what about system/service
accounts used by different systems ?

Our auditors are objecting to our having Domain Administrator and domain
system accounts with passwords that never expire.

A generally legitimate objection.

Yes, we change some of these passwords from time to time, but they're
normally set to never expire.

And why should Admins with far more privileged and therefore
DANGEROUS accounts be allowed practices less safe and more
lazy than ordinary users?

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.

No, they are being reasonable.

Perhaps you issue is that you are using the same Admin
account for many admins?

Each admin should have a separate account for admin
purposes (so that auditing is specific.)

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.

Do it correctly and safely, and thank the auditors for encouraging
safe practices.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

 

[Wolf Kirchmeir]

Thank you for your reply.

I would agree about the admin account, but what about system/service
accounts used by different systems ?

[...]

Aren't these actually just another variety of administrative accounts?
IMO, you should consdier the advice given to you carefully, especially
the rule that more power an account has, the more it should be secured,
which of course implies both complex/long passowrds, and more frequent
changing thereof.

One of the things I find it difficult to get across to people is that
even their single home computers need constant vigilance -- until
something goes thoroughly wrong because of malware, after which some
people develop severe paranoia.

There is no simple easy solution to the problems of security, and
certainly no cheap one.

And that's my perspective from the p.o.v of a home user with three
machines that aren't even networked (although I plan to do it Real Soon
Now. )

 

[JJ]

No argument here about password complexity.

The question is merely about forcing password expiration.

Thanks for your input. We're taking all these suggestions seriously.

Thank you for your reply.

I would agree about the admin account, but what about system/service
accounts used by different systems ?

[...]

Aren't these actually just another variety of administrative accounts?
IMO, you should consdier the advice given to you carefully, especially
the rule that more power an account has, the more it should be secured,
which of course implies both complex/long passowrds, and more frequent
changing thereof.

One of the things I find it difficult to get across to people is that
even their single home computers need constant vigilance -- until
something goes thoroughly wrong because of malware, after which some
people develop severe paranoia.

There is no simple easy solution to the problems of security, and
certainly no cheap one.

And that's my perspective from the p.o.v of a home user with three
machines that aren't even networked (although I plan to do it Real Soon
Now. )

 

[Herb Martin]

Thank you for your reply.

I would agree about the admin account, but what about system/service
accounts used by different systems ?

System/service accounts SHOULD be marked as
never expiring BUT they should also have passwords
that "no one can remember".

My rule: If I can remember the service password for
longer than a couple of minutes it is WAY too easy.

These should be upwards of 16-20 characters and follow
multiple rules for complexity/randomness.

It is one of the cases where I actually build them in a
notepad and then paste them into the several places they
are required (define the password, tell the service about it,
etc.)

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Our auditors are objecting to our having Domain Administrator and
domain
system accounts with passwords that never expire.

A generally legitimate objection.

Yes, we change some of these passwords from time to time, but they're
normally set to never expire.

And why should Admins with far more privileged and therefore
DANGEROUS accounts be allowed practices less safe and more
lazy than ordinary users?

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.

No, they are being reasonable.

Perhaps you issue is that you are using the same Admin
account for many admins?

Each admin should have a separate account for admin
purposes (so that auditing is specific.)

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.

Do it correctly and safely, and thank the auditors for encouraging
safe practices.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

 

[Joe Richards [MVP]]

Hell I would and do object as well.

http://blog.joeware.net/2005/05/08/10/

 

[Brad Baker]

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)

 

[Herb Martin]

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.

Then you need to find all of those services.

Turn on Account Auditing and track them down.

Services and such should use SERVICE specific accounts
with (incredibly) difficult passwords that never expire.

Admin accounts should NEVER be used for such services.

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.

That can be overcome by finding each sub-service or by re-installing.

Don't propagate the mistake because solving it is hard work.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

 

[Roger Abell [MVP]]

Poorly written apps (I guess I cannot say third-party apps in light of
your experiences with the older version of Exchange) are one, but
not the only pain point. Changing the creds used for scheduled tasks
when done is either a painful visit each machine affair, or an unsafe
let the new creds fly on the wire affair. Neither is really workable as
a frequent activity.

However, I believe both should occassionally be done, not just as
preventative, but as insurance that it is can be done (as in, when
re-acting to a compromise of such account). Any shop really does
need to know exactly where and totally all such exposures in a doc
kept as carefully as the other goodies for the kingdom.

Moving most services to running as Network Service or Local Service
where this can be done helps reduce the number of custom accounts
used as service accounts. And finally, using long, strong strings as
the passcodes helps pad the cushion.

 

[Guest]

If you are worried about forced expirations, then I would implement a company
policy that Admins manually reset these important account passwords every
month (or whatever). You can still have the passwords set to never expire,
but that does not mean that they should not be changed often. This may give
you a little more control over when exactly is the best time to change
passwords.

 

[Joe Richards [MVP]]

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.