MTS, COM, COM+, VB FAQ

Welcome to Sabbasoft


1)		What is security context delegation and how to set it up
2)		Is GetObjectContext.CreateInstance obsolete in COM+ ?
3)		What is Fallback Authentication (that is, how do i set up authentication among computers NOT running in the same domain) ?
4)		How do I impersonate the client in my COM+ Application (MTS package) ?
5)		What the major changes in the role based security model in COM+ ?
6)		How do I make COM objects deployed into a COM+ Application availalable to clients ?
7)		What is COM+ 1.5 ?
8)		Can the same component be registered in different COM+ Applications /MTS Packages ?

1) What is security context delegation and how to set it up

Delegate is the new impersonation level available in COM+. Delegation is available on COM+ since now is supported by the underlying Security Support Provider (SSP) available on windows 2000: Kerberos.
The delegate impersonation level means that the client credentials can be hopped from server to server during the call chain to be used by the server process to perform work using the client credentials.
Due to the limitations of the NTLM SSP used on NT4, delagation was not supported on NT4, a less powerfull setting was available: impersonate. In this case client credentials could be used only by server A invoked directly by the client, but they couldn't be hopped to another server B invoked by server A.
Remeber that the impersonation level is determined exclusively by the client (unlike authentication level, where the level applied is the common lowest watermark choosed among the preferences expressed by the client AND the server).
BTW: The impersonation level cannot be set on a per application basis declaratively using DCOMCNFG, hence (since you cannot call the COM API CoInitializeSecurity in VB to set this level programmaticaly) you have to modifiy the machine wide impersonation level setting on DCOMCNFG to set up an impersonation level for a VB application (but in this way you influence all client applications that do not call explicitely CoInitializeSecurity).

Ok, so it seems simple to set up delegation; every entity in the call chain must call CoInitialize security requiring delegation. Unfortunately it's not that simple; let's see what's the extra work required:

1) Call CoInitiliazeSecurity with a proper flag () EOAC_STATIC_CLOACKING or EOAC_DYNAMIC_CLOACKING) to require Cloacking. If you require Cloacking COM+ will use the thread identity and not the process identity when performing calls to a proxy. It may sound weird to require such a thing; the reason why this is not the default behaviour in COM+ is not to break existing apps developed on NT4 when they are ported on W2K, since no-cloacking was the only available behaviour in COM on NT4.

2) All actors taking part in the delegation scenario must have been granted proper permissions on Active Directory:
Server Identity :Account is Sensitive And Cannot Be Delegated disabled
Client identity : trusted for delegation Enabled
Computers: trusted for delegation

2) Is GetObjectContext.CreateInstance obsolete in COM+ ?

Yes. Createinstance was necessary in COM to provide a COM object activation mechanism that could be hooked by the MTS runtime before the activation request reached the COM runtime. So that MTS could apply some pre and post activation magic to put a wrapper around the real object and return this wrapper to the client.
This was due to the fact that MTS was not integrated with COM but ws built on top of COM.
COM+ has now embodied within its runtime the required interceptions mechanism, so there GetObjectContext.CreateInstance is no more necessary, still this syntax is still supported for backward compatibilities.
Nevertheless I suggest you to make conditional builds that use GetObjectContext.CreateInstance or Createobject according to your target OS.

3) What is Fallback Authentication (that is, how do i set up authentication among computers NOT running in the same domain) ?

COM doesn't have a built in security mechanism, but relies on Windows authentication services (Security Service Providers).
When you need to acces a resource or invoke a method in a remote Dcom server (or MTS package / COM+ Application) security checks cannot be performed in the standard way if the client is not running into the same domain (or, of course, workstation, but in this case there would be no remote communication) where the server is.
A principal that tries to launch/access a dcom server may be a local user defined in the client workstation account database or a user defined in a domain. If the client identity is a user defined in the same domain where the server is (or in a domain that is trusted by that domain) then everything is fine. If it's not the case (this applies in the situation where the server is not in a domain as well), then the server doesn't know who to ask to authenticate the user identity (match the password).
To let resource access and DCOM communication possible in this case, Windows implements the so-called Fallback authentication:
1) The server tries to see if there is a user that matches the client identity in the domain or workstation account database he belongs to .
2) If step one succeded then windows check if this user password match the password of the client identity.
If both steps succeeded then the client is "indirectly" authenticated and then, form this point, all access control is performed using this "matching" user.

Fallback autientication is not easy to maintain, since two accounts must be kept in synch, but in some situation this mechanism may turn usefull.

4) How do I impersonate the client in my COM+ Application (MTS package) ?

1) During a client Server conversation it's ONLY the client that decides what impersonation is allowed; playing with the impersonation level of the COM+ App has no effect, changing this setting you are declaring what is the impersonation level that your COM+ lets to use when will make a call to another process (read com+ application, thus acting as a client).

2) If the client process choosed a Impersonate or Delegate impersonation level, then your server can call successfully CoImpersonateclient(); from this point to a subsequent call to CoRevertToSelf() all the code will be executed in the security context of the client (SQL integrated authentication included).

3) VB can't call successfully call CoInitialize security, A "VB created client process" get the system wide impersoantion level, so situation is not really nice.

4) If the calling process is IIS, then everything works OK, and you can run in the context of the caller, whose identity depends on IIS authentication settings.

5) What the major changes in the role based security model in COM+ ?

There are basically two major changes in the role based security model in COM+.

1) You can set role based security on Library packages (in MTS you could set role based security on server packages only. This can be very usefull in web based applications, since you can set up security policies on web users access avoiding the cross process overhead involved in using server packages (you might have already gone once through such overhead defining your IIS application as running in medium or high isolation mode).

2) You can set role based security at method level (in MTS you could set role based security at class and interface level only). I personally try to avoid this feature, since i think it's a good design practice to set up security at interface level to force interface semantic.

6) How do I make COM objects deployed into a COM+ Application availalable to clients ?

What I describe for COM+, applies to MTS with some slight differences as well.
Registering COM objects remotely has been quite a pain before MTS showed up (rememeber the VBR file?).
In COM+ it's very easy to do.

1) Right click on the COM+ application and choose export Choose application proxy, choose the export package file name (.msi file)
2) Go to the client, run the .msi, (make it accessible to the server creating a proper share), you are done.

Watch out there is a bug in W2K SP2 that produces a bad .msi file that don't register the component corrrectly. Get the the proper post SP2 fix from MS before SP3 will be released.

The other export option you have in W2K is conceived to deploy an exact copy of the COM+ App to another server. In MTS you do not have these two options separately. The export option in MTS produces both kind of exports. The export for the client is the exe file in the client subdirectory.

7) What is COM+ 1.5 ?

COM+ 1.5 is an evolution of COM+ 1.0. COM+ 1.0 was released with windows 2000. COM+ 1.5 has been released with Windows XP / .NET Servers. COM+ 1.5 provides some new features like application recycling and COM+ partitions, running COM+ applications as services and more (I'll likely cover these new features in a coming FAQ).
COM+ 1.5 WILL NOT be available as an upgrade in the windows 2000 operating system. To get COM+ 1.5 you've to upgrade to WIndows XP / .NET servers.

	8) Can the same component be registered in different COM+ Applications /MTS Packages ?
	NO, this is not possible in MTS or COM+ 1.0 (W2K). It is possible in COM+ 1.5 using COM+ partitions.

Comments, suggestions .. whatever .. drop me a line if you wish

You are visitor number

Since 2001/01/01