A little clarity amongst the panic might be in order.
95% of applications which operate as services do so with SYSTEM_AUTHORITY
(System Account). This account is created when the OS is installed. It is
this account which starts things like the storage subsystem, desktop,
network components, etc... Of course, given that it has to do all of these
things with, or without, a user logging in, means it has privileged access
to the machine and all its components. This account does not have a
password, and it cannot be used as a User ID to log into the machine. This
account is not at all the same as the Administrator Account (or its
equivalents)
So having an application use the System Account is the equivalent of
loading an NLM into ring 0 on a Netware machine. It is the System Account
which is in charge of the security in NT. A wonderfully engineered .DLL
would not be able to SNARFF anything unless that .DLL replaced the log on
.DLL and completely replicated the functionality of that process (and there
is no reason it could not do that, but that would cause a number of law
suits if it was not clearly stated as such). The only other way it could
get passwords would be to replace the Service Startup subsystem, which
would mean replacing the Executive (i.e. the OS).
Now for those application which create their own account, the situation is
a little different. The objective by these companies is to provide added
security by not using the System Account, thereby letting you modify the
security and access restrictions of this new Account. Fact is, the
instructions will clearly state that you must be logged in as an
Administrator (or equivalent) in order to run the installation process, as
the application itself cannot give itself a privilege which the currently
logged on user does not have. In a environment where a proper security
policy is in place, access to the Administrator Account will be restricted,
and any need for it will be scrutinized (somehow I don't think that PC Week
Labs falls into this category!) Since non-Administrator Accounts cannot
create user accounts, any attempt by a different account would fail.
Now in the case of InocuLan, and many other services, the issue here is
that a service does not know (typically) how to change its password. So if
you do not set the password to never expire, you can run into the situation
that the service will fail to start because its password has aged. The
caching of the password is done through the service startup dialog, and is
not accessible other than by the service startup process, not the
application. If you want to avoid it, simply change the service startup
parameters so it logs in as the System Account and the cached password
problem goes away. Remember, the service doesn't log into the system, the
system logs the service in, big difference. I have no idea what password
the PC Week Labs folks saw unencrypted in InocuLan, but it wasn't the
information that was entered into the Service Startup parameters (although
it may have been the same value). As a test, I would have changed the
password in the service startup parameters and on the NT account itself,
left the password the way it was in InocuLan, and seen if the program still
started up as usual, I suspect it would. It may also have been left by the
installation program to provide the password to the Domain Administrator,
having an unknown password on an account in your system is never a good
idea.
Most programs that will allow the use of a separate account (other than
System Account) instruct you to create the account and assign it the "log
on as a service" right. This way you are forced to understand the
implications of what you are doing. It would be nice to see Microsoft add
replicant System Accounts which each could be profiled individually to a
particular service...maybe in Cairo??? Meanwhile, as it is with UNIX, if
you are going to add a service to NT you have to give it either access to
your entire system (System Account), or let NT store the password for the
account in its Service Startup "Logon as" area. At least NT encrypts the
password and stores it in an area that only the System Account can access,
and because this service is not operating as the System Account, it cannot
access its own password.
One flaw in the Microsoft Security Model that I will point out, however,
and was made glaringly apparent with the InocuLan problem, is that if you
had set an Account policy (intended to apply to all users) which stated
that you would not allow the option "Password Never Expires", you can
simply override it programmatically (through an installation routine such
as InocuLan's), or with a simply checkbox when creating a user. NT does
need to do a better job of separating service accounts from user accounts
to make some of the difference more obvious.
Fact is, the InocuLan account is no more or less secure than the
Administrator account in NT, with the sole exception that the password does
not expire. You can go in and set the user policy on it to lock out
attempts at logging in after 1 failure, since there should never be a
failure. Its use is completely logged in the Event Viewer, and you can
restrict it to only be allowed login at the local machine, not across the
network (amongst other restrictions you can put on it). The Administrator
account could not survive such stringent rules. In other words, the "left
NT open" fear is baseless and based on perception rather than knowledge.
Bottom Line:
- The System Account does not have a password
- The Service (in this case InocuLan) does not store the password
- Only the System Account can access Service Startup "Log on as" parameters
(i.e. service passwords)
- Using a separate account to start up a service is more secure than using
the System Account, if the account is set with appropriate rules
- I always recommend the use of separate accounts for service startup
- InocuLan did what it should do as a good little NT service, but they
either didn't document it properly or the PC Week Labs folks didn't read
the documentation (flip a coin)
Cheers,
Russ Cooper
If you are interested in receiving this level of support information
through a Windows NT subscription based mailing list for $20 per month,
please send me an email (Russ .
Cooper @
RC .
Toronto .
on .
ca)
Follow-Ups:
|
|
