DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
So, let us examine how this would work in practice. First, everyone would need to ensure their Web browser was set to the default setting that accepted only trusted components. Next, any company wanting to send the user an ActiveX component then has two routes to follow:
The approach doesnt work at all for ad hoc users of a companys services. Thus, if a person was browsing the Web and saw a bookshop with some really good books in it, he or she could not be sent catalogs and components to help him or her choose the books. Instead, he or she would have to contact the company and first ask for its public key.
It should also be noted that the Web browser is the point of failure in this whole scenario. If developers find a way via an uploaded ActiveX control or Java applet of changing the setting of the Web Browser to accept any ActiveX controls, then all of this elaborate protection falls apart.
Authorization
Authorization is controlled via Access Control Lists (ACLs). The basic list simply lists the objects and which users are allowed to access them. Control is not allocated at the method level. A user can be granted access to:
An object calling another object can pass the privileges it has obtained to the child, but that child cannot pass the security privileges it obtains from the calling object on to any other objects it calls. As such there are no inherited permissions.
The lists are set up using a DCOM configuration tool, DCOMCNFG, or can be set up programatically using the Windows NT Registry and Win32 Security functions. ACLs are also stored with the Registry and as such must be set up on every machine by the administrator. Each ACL list is unique and pertains to the components on that machineit is not replicated. Again, this may change when the Active Directory is introduced.
Security checking is automatically applied upon activation. In other words, where the object is being requested for the first time and an instance has to be requested, the checks are performed as part of the normal Directory processes for finding the object and creating an instance of it.
When multiple users require the services of a single nonsecurity aware server, a separate instance is created for each user, so that clients cannot access each others data. Where more than one client is the same user, the server is shared between clientsof course the server could then be multithreaded. All nonsecurity aware servers are run as the security principal that caused them to run.
Once the connection has been made between a client and an object, further checking at the method level or, for example, to recheck authorization has to be done by the server.
MSMQs security is an extension of the basic security provided with Windows NT and DCOM. Clearly, there are far more things that need to be placed under security control within MSMQsites, CNs, computers, queues, and so on. These are all treated as objects within MSMQ, and for each object, security permissions are set up in separate access control liststhese are not part of the Registry.
The administrator can define at queue level which applications can send messages to a queue, which applications can get messages from a queue, peek at messages, or get properties of a queue. The administrator is granted his own special access rights to enable him to set up the securityin other words, the ACL is itself subject to security controls. The special access permission the administrator obtains then enables him to set up sites, enterprise controls, connected networks, and so on. MSMQ also supports an auditing capability.
Encryption
Where encryption is required, the developer must use third-party software such as DES, although Windows NT does encrypt the password. It is now why we see that Microsoft has provided the CryptoAPIto enable developers to use other products to provide encryption capability.
Integrity checking
Authenticode has 128 bit or 160 bit hash functions in it to help in integrity checking.
Audit
Auditing is provided through Windows NT Event logs. Each NT workstation or server has three event logsa system log which is used to record configuration problems, state of services, and use of peripherals; a security log; and an application log. Clearly, it is the security log which is of interest here.
Security events cover successful accesses and failurescases where access was denied. The audit policy has to be set for each server to specify which actions to auditobjects, users, which types (success, failure, both). The messages sent to the log then all have the type of message, the date, time, source, user, eventid, and computer. Although problems are logged, serious problems are also written to the console.
Event logs can be viewed using SNMP links to SMS toolsNetview, etc., by using the System Event Viewer or by using tools provided with each service. MSMQ events, for example, can be viewed from MSMQ Explorer; however, MSMQ Explorer displays events only of type MSMQ. The Event Viewer covers all events but supports sorting, filtering, and searching of events.
Event logs are kept for each machine. In other words, there is no centralized event log for the entire system (although links can be built using SNMP to Systems Management Software if you want).
Previous | Table of Contents | Next |