When configuring a daemon's identity (WhatIsADaemon), you'll need to either use one of the built-in logon sessions (WhatIsALogonSession) or create a custom account. I've summarized the differences between the built-in logons in Figure 28.1.

Figure 28.1 Choosing a built-in logon for a daemon

SYSTEM is like root on UNIX. It's all powerful and is considered to be part of the trusted computing base (TCB). You should configure as little code as possible (preferably none) to run under this logon, as compromise of it immediately compromises the entire machine. (When you're part of the TCB, you're trusted to enforce security policy as opposed to being subject to it!) The other two accounts have low privilege, just like a normal user account, although they’re granted SeAuditPrivilege and SeAssignPrimaryTokenPrivilege, allowing them to generate security audits and start processes in alternate logon sessions.

The two logons with network credentials can be authenticated on the network using the computer’s domain account. So, for example, code running as Network Service on a machine named MAC26 in a domain called FOO is seen as FOO\MAC26 when making authenticated requests to other machines on the network, whereas Local Service is unable to authenticate and therefore is represented by a null session (just like J. Random Hacker) on remote machines (see WhatIsANullSession for more on null sessions). An important point: If the machine isn't in a domain or is in a legacy Windows NT 4 domain, then none of these built-in logons will have network credentials.

Here's how to decide on an identity for your server process. If you need to be part of the TCB—that is to say, if you call functions that require the "Act as part of the operating system" privilege, as LogonUser used to require in Windows 2000—then run as SYSTEM or, even better, consider factoring your program into two parts, as I sketch out later. If you don't need high privilege, shoot for running as Local Service unless you need network credentials, in which case you should choose Network Service. Any privilege or network credential that you have but don't really need is one you're giving for free to any attacker that successfully compromises your process. Just say no!

If you find that you need a bit more privilege than what the low-privilege logons provide, don't break down and run as SYSTEM! And don't go changing security policy to elevate the privileges of the built-in logons either. Instead, create a custom account and assign to it exactly the privileges your daemon needs and nothing more. If you need network credentials, use a domain account. If you don't need network credentials, use a local account. Creating a custom account means more work at deployment time, but it's so much safer than running with too much privilege or raising the privilege level of a built-in logon used by many operating system services. Be sure to give your custom account a very long (20 characters at least) and randomly generated password. A human doesn't need to type in this password every morning to log on, so there's no reason not to do this! And change the password from time to time just as you would with a normal user account. (I postulated a couple of possible attacks against weak server passwords at the end of WhatIsAGroup). There are loads of tools to help manage passwords, (including Password Minder, a tool I maintain that you can download for free from this book's Web site). Find one from an author you trust and use it!

If you use a custom account to run a daemon, make sure that it's granted the appropriate logon right. COM servers and IIS 6 worker processes use batch logon sessions and thus require the "Log on as a batch job" right, but services use service logon sessions and require the "Log on as a service" right. I remember the first time I tried to run an ASP.NET application pool under a custom account and was frustrated by the "Service Unavailable" error in my browser after I made the change. The problem was that the account I was using didn’t have the batch logon right. Your best bet on IIS 6 is to simply add the account to the IIS_WPG group, which has the rights and permissions necessary to run most Web applications. If you run into this problem yourself, be sure to restart your application pool (just right-click it and choose Start) after fixing the problem.

Even when you do need high privilege, chances are that the most of your process doesn't need high-privilege, so consider factoring out the high privileged code into another process. Figure 28.2 shows what this might look like. Use a secure form of interprocess communication (COM is a good choice here) and lock down the interface to the highly trusted code so not just anybody can call it, using role-based security (HowToImplementRoleBasedSecurityForAManagedCOMApp). Preferably only your low-privileged server process should be able to use the interface.

Figure 28.2 Factoring out high privileged code

If you ever try to type in the name of one of these built in logon sessions and the system acts as if it's not a valid name, try using the fully qualified name, including the authority (case doesn't matter):

• NT AUTHORITY\SYSTEM
• NT AUTHORITY\Local Service
• NT AUTHORITY\Network Service

Configuring the process identity for SQL Server 2000 is an example of where you'll need to type in the fully qualified name for Network Service. And if you're prompted for a password, just leave it blank for these guys.

PortedBy ChrisTavares