Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Hitachi ID Systems Blogs

Archive for August, 2009

Windows domain controllers – buggy by design?

Tuesday, August 18th, 2009

We’ve been working on our Privileged Password Manager lately, and have
been thinking about how to secure and reliably manage the passwords for
service accounts on Windows.

Some background information may be in order at this point. Unlike on
many other operating systems, services on Windows are executed using
both their login ID and password. That is, services either run in the
context of a built-in OS user called SYSTEM, which has an extremely
broad range of privileges, or they run in the context of a named user,
who may be assigned more restricted security rights. Windows Service
Control Manager, which is responsible for starting and stopping service
programs, needs to know the login ID **and password** for every such
user in order to launch processes as that users — called service
accounts — when a service is first installed.

We start running into problems when we try to change passwords for
service accounts. Clearly, if a service account password is changed,
SCM has to be notified of the change. If we forget to do that, next time
SCM tries to start the service, it will fail – because it will try
to use the wrong password.

This problem extends beyond just services. Scheduled Tasks and IIS
web sites have the same problem. IIS actually knows how to change
the password for its “anonymous user” accounts. The Windows Scheduler
does not. Third party programs often have the same requirement –
they need to know the password for certain accounts that are part of
their software.

Starting with Windows 2008 R2, there is a formal concept called a
service account and SCM can change the password for these accounts.
So long as SCM is the *only* thing that needs the password for a given
service account, this works great. Unfortunately, if a third party
application also needs that password, the SCM service account construct
is not helpful.

The situation gets more complicated when we consider services that
execute on domain controllers.

On a Windows 2000, 2003 or 2008 domain controller, there is no concept
of a local user. All users are AD domain users. That means that any
service that runs as a user other than SYSTEM does so with the login ID
and password of an Active Directory user. If you change the AD user’s
account, you also have to tell SCM on the DC the new password.

That’s fine … but what if services on a thousand different DCs run with
the same AD service account? Suddenly, changing a service account’s
password becomes a project — you have to have a comprehensive list of
DCs and you have to check every DC to see if it has services running
as that user. If so, you have to tell SCM on that DC the new password.
If you fail to connect to a DC — for example, if the network connection
to the site where the DC lives is temporarily down or if the DC has
a hardware problem — you must retry connecting to that DC until you
succeed.

In other words, running services on multiple DCs with the same AD user
creates serious problems and makes it very difficult to change passwords
for that user.

This problem only arises because AD DCs don’t have a notion of a
“local user” as distinct from a “domain user.” That’s weird, because
even Windows workstations differentiate between domain and local login
accounts.

In other words – not having local users separate from domain users on
DCs is BROKEN BY DESIGN.

To avoid this problem, organizations should ensure that if they run
services on a Windows DC with a non-SYSTEM service account, they should
create an account for just that one service, on just that one DC.
If they run the same service on a different DC — they should create a
separate service account for that DC, and so on.

This may sound like a pain, but it’s better than the problems that arise
when trying to coordinate password changes to shared service accounts.