Windows 2000 Service Pack 4 (SP4) introduces two new rights that tighten Win2K’s security model and make it compatible with Windows Server 2003. To avoid problems with installed programs, you need to understand how these new rights restrict previously allowed activity. In nondeveloper terms, the "Impersonate a client after authentication" (SeImpersonatePrivilege) right lets programs and services that run after you log on perform activities on your behalf. To do so, the program or service must impersonate you by using your account credentials instead of the credentials the program or service logged on with. Many Win2K services log on with a local system account. When you request a network connection, the service responsible for the connection uses your account credentials to make the request for the resource. A similar process happens with terminal server clients. In Win2K SP3 and earlier, programs and services don't require explicit permission for impersonation activities; in SP4, they do.
The impetus behind the "Impersonate a client after authentication" right is similar, in some respects, to the impetus behind the Restrict Anonymous security setting. Without this control, code with user or client access credentials can use a remote procedure call (RPC) or named pipe to anonymously connect to another system at any time. In fact, many worms and Trojan horses use RPC and named pipe connections to propagate their evil ways across a network. When you upgrade a system to SP4, setup automatically assigns "Impersonate a client after authentication" right to members of the local Administrators group, the System account, all services that the Service Control Manager (svchost.exe) starts, and all COM components.
The "Impersonate a client after authentication" requires that you be educated about the circumstances in which standard applications need to impersonate the logged-on user; the information will serve you well as a security deterrent in the future. After you determine which applications use the impersonation technique, you must allow, rather than deny, the program’s ability to perform actions on behalf of the logged-on user.
One end result is that some programs, plus services not under control of svchost.exe, might not behave as expected when they logon with an account that does not have the “Impersonate a client after authentication” right. If you know the account that the program or service logs on with and you're comfortable with the impersonation, use a Group Policy Object (GPO) or Local Security Policy to assign the “Impersonate a client after authentication” right to the account. If this step doesn't solve the problem, you might need to investigate further. For quick troubleshooting, Microsoft suggests that you assign this right to the Everyone group (or the slightly more restricted Authenticated Users group). If the program runs successfully, you know that the account associated with the program needs the “Impersonate a client after authentication” right. Then, grant this right to the account that runs the program or service and remove the right from the Everyone group. If you don't remove this right from the Everyone group, you'll permanently disable this new security feature.
The second new right, "Create global objects" (SeCreateGlobalPrivilege) improves security for Windows 2000 Server Terminal Services clients. Identifying when you need to assign this right to Terminal Services client accounts is more difficult because this right isn't required for session objects, only for programs that create global objects. I couldn’t find a good description of when a Terminal Services client needs to create global objects because this activity depends to a great extent on the type of program a Terminal Services client runs.
After you identify the accounts that need the “Impersonate a client after authentication” or “Create global objects” rights, you can assign the rights to individual accounts by using Local Security Policy, or you can automate the process with a GPO. Although systems earlier than SP4 can't implement these rights, you can use a GPO to assign these rights to systems running Win2K SP2 and later without problems. However, if you distribute such a GPO to Win2K SP1 systems, the GPO won't load successfully. Because SP1 is so outdated, this problem shouldn't be a concern at most sites. For more information about these two rights, see the Microsoft article "Overview of the 'Impersonate a Client After Authentication' and the 'Create Global Objects' Security Settings" (http://support.microsoft.com/?kbid=821546).
The “Create global objects” right has introduced at least two problems on SP4 systems: one that might be a concern at many sites and one that affects only users of McAfee Security’s Parental Controls software. When a Terminal Services client searches for clip art in a Microsoft Office XP document, the Microsoft Clip Organizer responds with “not enough memory” or “not enough storage to complete this operation” error messages, which prevents Terminal Services clients from inserting clip art into Office XP documents. If I understand the problem correctly, the error occurs because the component that performs the clip search doesn't have permission to create a global object on the remote system. Microsoft Product Support Services (PSS) has an updated version of this component, msdaps.dll, that theoretically solves this Office XP problem. The second problem is a fundamental incompatibility between SP4 and the Parental Controls software. If you upgrade a system on which the parental-control software is installed to SP4, the system will hang during the restart. You can recover from this disaster only by booting into safe mode and removing the software. For details of these two problems, see the Microsoft articles "Windows 2000 Server-Based Computer Stops Responding When You Restart After You Install McAfee Parental Controls" (http://support.microsoft.com/?kbid=823043) and "'Not Enough Memory' Error Message When You Search for Clips in an Office XP Document During a Terminal Services Session" (http://support.microsoft.com/?kbid=821257).