The current security model of Distributed COM has many good features and a few important limitations. The security model is strong because it leverages the strengths of MS-RPC and loadable SSP packages. This practice gives you a layer that conducts call-level authentication behind the scenes. You can change security providers and authentication levels without having to make any modifications to application code.
The security model is also somewhat limited because access permissions can be applied only with a processwide scope. This means that either you let a user account into the distributed application or you deny the user access. The model can't accommodate a more granular scheme. For example, you can't extend access permissions to one CLSID while denying permissions to another. Note that it is possible to write explicit code to provide more granular security: This can be done with a shim DLL written in C++ but not in a declarative fashion via Dcomcnfg.exe.
While Visual Basic provides all the self-registration code for in-process servers and local servers, it doesn't offer any assistance with AppIDs. You can configure an AppID with a utility such as Dcomcnfg.exe or OleView.EXE, but doing so can be frustrating because each utility has a few capabilities that the other doesn't have. To make things worse, certain tasks, such as creating a new AppID, can be accomplished only by hand or by using a script.
The next chapter covers the MTS run-time environment and explains how MTS is based on the RPC infrastructure and COM's security model. As you'll see, MTS builds on the strengths of Distributed COM while offering improved solutions for access-permission granularity and the configuration of servers and clients.