Working with Remote Unmanaged Components


In general, once you add the proper code to your components, maintaining security becomes a matter of configuration. When working in the Win32 API environment, the tool of choice for component security configuration is the DCOM Configuration Tool, which is available on most NT-based systems by default and downloadable for Windows 9x systems. The DCOM Configuration Tool is a powerful utility that helps you to work with the components registered on a client machine. You can set the component to execute remotely or locally. In addition, this utility lets you modify the security setup for the component.

You can also use this utility to modify general DCOM operation on a client machine. For example, even though UDP/IP is the normal protocol used to create a connection between the client and the server, you can set it to any of the protocols that both client and server support. This means that you could create a secure connection between client and server by using an encrypted protocol instead of a plain text protocol like UDP/IP.

Although there are many tasks you can perform with the DCOM Configuration Tool, such as setting the endpoint communication protocols, the following sections concentrate on the security features of the program. When you need to perform additional component configuration, you might want to look at the other areas of the program as well. For example, you use this utility to redirect component execution from the local machine to a remote location. You’ll also see a few general details when security needs require their mention.

Setting Up the General DCOM Environment

Microsoft assumes certain defaults when setting up DCOM on your machine during the Windows installation process. Normally, these defaults work just fine, but you may find that you either need to change the features supported by the DCOM or the protocols used to communicate between client and server.

The first thing you need to do is start the DCOM Configuration Tool. Use the Run command on the Start menu to display the Run dialog, then type DCOMCnfg in the Open field can click OK. You’ll see the initial Distributed COM Configuration Properties dialog box. The Applications tab of this dialog displays all of the registered out-of-process servers that are installed on the client machine, including managed components that you register using the RegAsm utility. It’s important to note that this dialog box only contains registered components—it doesn’t matter whether the component is managed or unmanaged.

Note

Windows XP replaces the DCOM Configuration Tool with an MMC snap-in that is part of the Component Services console. The MMC snap-in version lets you configure individual components, but doesn’t allow you to configure the DCOM settings overall. To gain access to the overall settings, use the older version of the DCOM Configuration Tool. You can obtain this older version as part of the Windows Resource Kit or from another version of Windows such as Windows 2000. Some older versions of Microsoft’s programming tools might also include this tool. Don’t use the Windows 9x version of the tool because it doesn’t include all of the features of the NT-based version.

The Default Properties tab contains the general settings for DCOM on your machine. The Default Authentication Level list box controls how DCOM handles communication security between the client and server. The default setting is Connect, which means that security is handled only once per connection. See the “Setting the Authentication Level” section of the chapter for additional details.

The Default Impersonation Level list box controls what the server can do on the user’s behalf when it comes to identification. For example, this setting affects what will happen if the server has to create another component to satisfy a user request. This setting controls identification issues such as creating the component in such a way that it looks like the user has created it directly. The matter of impersonation level affects what kinds of things the server can do for the client and how it does them. The default setting for this field is Impersonate. The following list defines the various levels of impersonation that DCOM supports:

Anonymous This is the least secure impersonation level. The server performs processing tasks for the client without knowing the identity of the client application. Unfortunately, this setting limits the server to performing tasks that an anonymous user could perform—which means that many resources will be out of reach.

Identity This level of impersonation lets the server to identify the client application. This means the client will gain full access to the resources and services available on the server as long as the client makes the call directly. The server can’t impersonate the client, even for local service and resource requests.

Impersonate This is the highest level of impersonation that the Windows authentication service supports natively. It lets the server impersonate the client locally, which means that the server will impersonate the client for any services or resources that the server has to request to satisfy a client request. The Impersonate level only allows client impersonation on the local server; a server can’t impersonate the client on other servers.

Delegate This is the most secure impersonation level. The server performs all tasks as if it were the client. This includes requesting services and resources on other servers. Windows authentication service doesn’t support this level of impersonation.

The Provide Additional Security for Reference Tracking check box tells the server to track connected client application requests. Checking this option uses additional server resources—both memory and processor cycles. However, it does enhance server security because a client won’t be able to artificially set a server process’s reference count to 0, which could kill the process prematurely. The effect of killing a process prematurely is that other clients will likely crash when they attempt to free reference pointers to objects that no longer exist.

Warning

Securing the server and the components that reside on it still don’t secure the data that gets transferred between client and server. Make sure that you always use some type of secure communication protocol to transfer data from one point to another—especially when working on a public network. Check the various options in the “Setting the Authentication Level” section of the chapter for details on how you can use built-in DCOM settings to make your data more secure (a good encryption product will only enhance the security you can get by default).

Using the General DCOM Security Options

You’ll find the general DCOM security settings on the Default Security tab of the Distributed COM Configuration Properties dialog box. This dialog box includes three main security areas: access, launch, and configuration. The access area determines who can connect to your machine to use DCOM. The launch area determines who can remotely run applications on your machine. Finally, the configuration options determine who has permission to configure the DCOM settings on your machine. The following list tells you about these areas in more detail.

Note

None of the settings in this section will override application specific settings. Windows uses the application specific settings first.

Default Access Permissions This option defaults to the same access level permissions provided by the system as a whole. In other words, if a person has permission to access your hard drive in some way, they usually have permission to access the applications they find there. Of course, access doesn’t necessarily mean the ability to execute. The Default Access Permissions option determines who can access applications on the machine.

Default Launch Permissions DCOM applications normally recognize three groups for launching purposes: Interactive Users, Administrators, and System. You must specifically assign a user to the Interactive Users or Administrators groups before they’ll have launch permission. Only system-level services can use the System account. This particular dialog box also lets you to add specific groups that can’t launch an application. However, you need to remember the rules for using an ACL when adding deny entries. The ACL always goes from the top of the list to the bottom and acts on the first entry it sees. So, if a user is part of two groups, one that is allowed to launch DCOM applications and another that isn’t, you need to put the deny group first. Otherwise, the user can launch DCOM applications based on the group entry that’s allowed to launch applications.

Default Configuration Permissions This list includes anyone who can configure DCOM on a machine. Normally, the System account and the Administrators group have full configuration control. Everyone else can read the configuration, but not change it. You must provide read permission to anyone who will launch or access applications. You can also use the Special Access setting that allows you to customize settings, but this is a difficult entry to set up and normally you won’t need to use it.

All three settings work the same way, so I’ll discuss them as a single entity, even though each area affects a different area of DCOM communication. Clicking Edit Default on the Default Security tab displays a Registry Value Permissions dialog box for launch permissions. This dialog box lets you add and remove users from the access list.

Click Add and you’ll see an Add Users and Groups dialog box. This dialog box presents a list of domain users and groups; you can also choose from a list for the local machine. Using each list has advantages. Using the local machine’s list helps you control the security settings on a machine-by-machine basis. On the other hand, using the domain list means that you only need to change the settings on one machine to add a new user to a group that will affect all machines that are running DCOM applications.

Working with Component Level Security

Component level security works much like general security except it affects just one application. To access this level of security, choose a component from the list on the Applications tab of the Distributed COM Configuration Properties dialog box. Click Properties and you’ll see a Properties dialog box for that component. Select the Security tab.

You can choose between general security and component level security for all three areas discussed in the “Using the General DCOM Security Options” section of the chapter. If you choose the default security option, then DCOM uses the options set on the Default Security tab of the Distributed COM Configuration Properties dialog box. Otherwise, you’ll need to click the individual Edit button to set the security you want for that area of component level security for the selected component. Since the actual process of setting component level security is the same as default security, this section doesn’t discuss the various options.

Setting the Authentication Level

There are two ways to set the authentication level for your component: at the DCOM or individual component level. Both authentication level settings determine the minimum authentication requirements for the client and server. In other words, this setting determines how the client and server exchange security information during a session.

You’ll find the Default Authentication Level setting on the Default Properties tab of the main Distributed COM Configuration Properties dialog. As previously mentioned, the default general setting is Connect. The component specific setting appears on the General tab of the component’s Properties dialog box. The default setting, in this case, is Default. These two settings represent a minimalist approach to DCOM security. You can use other settings to improve security. The following list describes each of the Default Authentication Level settings.

Default At the individual component level, this setting means that the component uses the general DCOM setting. At the DCOM level, this setting means that DCOM as a whole will use whatever security the authentication method uses in general. For example, Windows 2000 Security Services uses Connect level authentication. The results of using this setting vary according to the authentication method used.

None The client and server don’t authenticate each other. You must use this setting when creating anonymous connections. However, this setting also works in a small workgroup situation where physical security is high and there aren’t any connections to the outside world. This setting reduces overall network traffic to the lowest possible level, but also represents the greatest security risk.

Connect One-time authentication takes place during object creation. The client and server verify each other’s identity during this initial request. There’s a good chance a third party could break network security when using this mode since the client and server don’t have any way to verify either packets or requests. The advantage to this method is that initial authentication places limits on what the user can do and it minimizes network traffic.

Call Authentication occurs for every call while DCOM maintains a connection. This moderately high security level ensures the client and server verify each other’s identity for each method call, which may involve several packets. You’ll notice a slight increase in network traffic when using this authentication level and there’s no guarantee of complete security from third party intrusion.

Packet This is the first of three levels of truly secure DCOM communication settings. DCOM encrypts the sender’s identity and packages it with the packet. This means that the receiver can verify the authenticity of the sender with every packet, which greatly reduces the probability of third party intrusion. However, this method also bloats the size of the packet and greatly increases DCOM related network traffic. This setting represents the most reasonable level of protection for a network that allows outside access.

Packet Integrity DCOM encrypts the sender’s identity and a packet signature as part of the packet. Using these two forms of authentication ensures the sender authorization and packet integrity. However, this method won’t ensure that a third party hasn’t read the packet and it does increase network traffic over Packet authentication. Only use this setting when the integrity of the data is essential, but you don’t care who reads the packet.

Packet Privacy This is the paranoid security level. Not only does the packet contain the sender’s identity and a packet signature, but DCOM also encrypts the packet to ensure that a third party can’t read it. This level of authentication greatly increases network traffic and could actually slow communications to a crawl when used on slower traffic media like a dial-up connection. Use this level of authentication to ensure safe financial transactions and the transmittal of critical confidential information from one site to another.




.Net Development Security Solutions
.NET Development Security Solutions
ISBN: 0782142664
EAN: 2147483647
Year: 2003
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net