Setting Up DCOM and NT Security

Learn the basics of remote security issues and get five
quick tips for configuring DCOM servers.

by Steve Robinson

Reprinted with permission from Visual Basic Programmer's Journal, Volume 8, Issue 11, Copyright 1998, Fawcette Technical Publications, Palo Alto, CA, USA. To subscribe, call 1-800-848-5523, 650-833-7100, visit www.vbpj.com, or visit The Development Exchange at www.devx.com

Software developers never discuss NT and Distributed Component Object Model (DCOM) security. We treat the topic as taboo—we know it's there, we know we'll eventually have to deal with it, but we always find ways to avoid the subject. After all, security issues are for network administrators, not software engineers, right?

Wrong. Now that you're living in a distributed world and writing distributed applications, you need to know a little bit about security, even if only enough to test your remote servers. This article will cover remote server setup issues, while taking a quick look at NT security basics and DCOM security. You'll learn just enough about security to understand what's happening when you get that dreaded RPC_E_ACCESS_DENIED message. You'll also get a simple checklist for testing remote DCOM servers and clients that support connection points and sinks, respectively. Before getting into DCOM security, let's review some security basics.

Windows NT security is based on a domain-hierarchy model, where many machines share a database of trusted users. Every Windows NT network has a Primary Domain Controller (PDC). The exception is a standalone NT workstation machine, which is actually a domain of NT machines working together in a workgroup where every machine is also a standalone domain. A Trusted Domain is a setup that allows resources from one domain to access resources on another domain. Trusted Domains typically go in one direction, although they can be bidirectional.

The process of one domain trusting another domain and passing user authentication to another domain is called pass-through authentication. (Note: This applies within a domain also—a Backup Domain Controller uses pass-through authentication to check with the PDC if it doesn't find the user in its database.) Groups are collections of users with common attributes. Typically, users are grouped together to ease administration of accessibility rights. Setting up groups is the easiest way to administer accessibility to resources. Groups, like users, are set up through the User Manager. On our network, the group is allowed to access the Gateway DCOM server (see Figure 1).

Figure 1 The User Manager Dialog Box. The User Manager sets up groups to make accessibility rights easier to administer. Users are also set up through the User Manager. Under any computer-security model, when a client makes a call into a server, the server must confirm that the client is permitted to communicate with the server. The server must be able to authenticate the client and accredit the client's requests. The first goal of security is exactly that—authenticating clients. It's obvious that you must protect servers from rogue clients by authenticating that the client is who it claims to be.

But, security must go beyond authenticating clients. Just because you permit a client to connect to a server doesn't mean the client should have access to all resources on the server. Determining whether a server knows who is calling it and whether the server can do operations using the client's identity is referred to as impersonation. During impersonation, the user ID and password are verified, and an access token is created. Security IDs (SIDs) are unique IDs used to identify users or user groups. When you create a user or user group in NT's User Manager, a SID is automatically assigned. SIDs comprise the building blocks for authorizing access to resources on Windows NT.

DCOM SECURITY
Now that you've gained a basic understanding of NT security, you can look at DCOM security issues under a Windows NT domain. DCOM allows components to be launched and accessed from remote clients. The server machine handles DCOM's determination of whether a client can launch a server. It does this in one of two ways: Either the server machine can specify which applications can be executed, or the server can specify which users have the rights to launch an application.

Additionally, and just as important, DCOM uses an interchangeable security model, which is one of the reasons you can port DCOM to other operating systems. DCOM exposes its security model through Security Support Provider Interface (SSPI). NT's current security model is the NT LAN Manager Security Support Provider (NTLMSSP). Under NT 5.0, NT and DCOM on NT will use the Kerberos security system.

Figure 2 Show the Application IDs. DCOMCnfg, which you start through the Start menu's Run dialog box, shows all the registered DCOM AppIDs (ProgIDs). The initial window has two additional tabs: Default Properties and Default Security.

The most common way to specify application access and launch permissions is through DCOMCnfg. (OleView.exe in the expert mode is another way to set up DCOM components.) DCOMCnfg, which you start through the Start menu's Run dialog box, shows all the registered DCOM AppIDs (ProgIDs). Applications that don't register a string ProgID will show the AppID in the form of a GUID. The initial window has two additional tabs: Default Properties and Default Security (see Figure 2).

The Default Properties tab enables DCOM and allows you to set authentication and impersonation levels. The authentication level allows you to specify defaults for applications that don't internally specify authentication levels. Authentication levels range from None to Packet Privacy (see Table 1).

Authentication Level Security Level
None No authentication and the least amount of security. Use None when Anonymous is selected as the default authentication level.
Default The level of security is set to Authentication Service. Windows NT uses Connect as the default.
Connect Authenticate security on an initial connection to the DCOM server. This is the highest level of security available on Windows 95.
Call Authenticate security on every call accepted by the DCOM server.
Packet Authenticate all data with the sender's identity.
Packet Integrity The sender's identity and signature are encrypted to ensure the authenticity of the sender and to ensure that packets haven't been changed during transit.
Packet Privacy The sender's identity and the data are encrypted to ensure maximum security.
Table 1 DCOM Authentication Levels. The various levels of DCOM security go from None to Packet Privacy, where the sender's identity is encrypted.

The impersonation level allows you to set the level of permissions a client application grants to a server application to perform processing tasks on behalf of the client. Again, this is valid for servers that don't specify impersonation through custom coding. Security settings have a number of ranges (see Table 2).

Impersonation Level Permission Level
Anonymous The server application performs processing tasks for the client without knowing the identity of the client. This is equivalent to an anonymous FTP. This impersonation level should be used when the authentication level is None.
Identify The server application can verify the client to check permissions, but can't access system objects.
Impersonate The server application can perform processing tasks by impersonating the client. The server application can impersonate the client application only on the computer running the server application.
Delegate The server application can act as the client application on another computer. The server application can perform processing tasks on another computer as the client application. This isn't currently supported on the current Windows NT authorization service.
Table 2 Client Security Levels. The highest security level is Delegate, which can act as the client application on another computer.

The Default Security tab allows you to set system-wide default access permissions, default launch permissions, and default configuration permissions. You can override all these settings through code or by providing application-based custom settings. Use default access permissions to set user accounts that allow or deny access to applications on the computer. Default launch permissions permit you to allow or deny domain members the ability to launch DCOM servers. Default configuration permissions allow you to set read, write, and custom-registry access permissions. Full-write capabilities are typically limited to domain administrators and creator owners. DCOMCnfg with the defaults set for connection authentication and client impersonation are important to understand (see Figure 3).

Figure 3 Distributed COM Configuration Properties. Here, the DCOMCnfg defaults are set for connection authentication and client impersonation. Once you set the default security levels for your server machine, you're ready to customize security-launch permissions for your particular DCOM server application. When Windows NT is installed, default launch permissions for DCOM are set to Administrators, the Interactive User, and the System. While it's tempting to set the default to Everyone, you should create application-particular settings. Highlighting an application or GUID in the main dialog and clicking on Properties brings up a Properties dialog for the selected application.

The Location tab allows you to set the location where the DCOM server will be instantiated and run. This is how you set up clients to point to a DCOM server located on another machine in the absence of CoCreateInstanceEx.

 
Figure 4 Gateway Class Properties Security Tab. All members of the Gateway users group can access and launch the Gateway server class.

The Security tab, which allows you to customize access and launch permissions, is probably the most important tab because you're providing access to your computer. As mentioned earlier, the easiest way to provide access is by selecting a custom group created in the User Manager. All members of the Gateway users group can access and launch the Gateway server class (see Figure 4). The Identity tab allows you to select the user account where your DCOM server runs. Identities can confuse the most advanced DCOM developers, but keeping these in mind will help:

  • Selecting Interactive User means you'll run in the account of the currently logged-on user. Use this setting if you know the currently logged-on user will always be logged on. However, if no user is logged on and the machine is running, the DCOM server won't start.
  • Running as the Launching User requires the launching user to have access privileges to the DCOM server, as well as machine privileges. This implies that the launching user must have both membership in the user group and machine access rights, such as a Domain Administrator. If the Identity settings are set to Launching User and no one is logged on to the machine hosting the DCOM server, the DCOM server application will be launched.
  • Selecting This User requires you to select a domain member that has security privileges on the machine running the DCOM server, such as a Domain Administrator. However, the selected user doesn't need access to the DCOM server. For example, the Gateway server will run under the Kim account, who is a Domain Administrator at Panther not allowed to access the Gateway server (see Figure 5). Creating this setting also adds this account as "Log on as a batch job" on the server machine's advanced user rights (Administrative Tools | User Manager | Policies | Show Advanced User Rights). When setting up a DCOM server application to run in a specified account, the typical error occurs when the specified account doesn't have computer access rights and can't "Log on as a batch job."

    Figure 5 Gateway Class Properties Identity Tab. Under this setting, the Gateway server will run the Kim account. TIPS FOR CONFIGURING DCOM SERVERS
    In addition to the guidelines above, here are my top five tips for configuring DCOM servers.

    1. Users on Trusted Domains need to have an account created for them with matching usernames and passwords on the DCOM server's domain. The purpose of this is to set up a matching SID. Trusted Domain group members need to have remote DCOM servers initiated for them by a Primary Domain member.

    2. Workgroup machines are individual domains, so you must set up matching SIDs (usernames and passwords) to establish connections between the machines.

    3. Always create a Global Group through NT Server's User Manager and add the members for whom you want to provide access to specific DCOM servers. Then, use DCOMCnfg to set the launch permissions to that group. This makes administration easy to manage, even if you have a group that contains everyone.

    4. If the client application implements a sink, the server must be able to call back to the client. You must configure the client to accept calls from the server. Just because the client can connect to the server doesn't mean the server can call back to the client.

    5. Callbacks (sinks) in Windows 95 clients require user-level security. Select Control Panel, then Network, and specify "Obtain list of names from XXX, "where XXX is the NT Domain on which the server resides.

    If you don't want to set up user-level security, or you already have user-level security but don't want to change the domain where user IDs are obtained, you can set up your Windows 95 machine to allow anyone to access its COM servers. To do this, you need to update the Registry. Run Regedit and add this named value: 

    HKEY_LOCAL_MACHINE\Software\Microsoft\
Ole\LegacyAuthenticationLevel

    This is a DWORD value—set it to 1 to totally turn off security. Note that by setting this key, you're allowing any remote machine to call into any COM server on your Windows 95 machine. For more information, see the sidebar, "Where to Go From Here."

    Where to Go From Here
    This article covers most of the main territory for DCOM security. Some of the security issues are simplified, however, in the interest of space. For more information, you might want to peruse these Microsoft Knowledge Base articles: Q161837 and Q158508. The second article, "COM Security Frequently Asked Questions," is particularly important, solving some hard-to-track problems. In particular, it covers network/Universal Naming Convention (UNC) restrictions of the LocalSystem account. In some circumstances, these restrictions (also applicable to NT services) can be extremely limiting.


    Steve Robinson is president of Panther Software, which provides software consulting and development for major software companies and Fortune 500 companies. Reach the Los Angeles-based company at http://www.panthersoft.com.