[개발/VC++] AppID란 무엇인가?

번역 : 쌈꼬쪼려 소백촌닭

AppID 가 도대체 뭐꼬?

출처 : http://blogs.msdn.com/b/jigarme/archive/2007/10/09/what-is-appid.aspx

What is AppID?


If you have got chance to work with DCOM /COM+ frequently; you might have come across the term called AppID (if you are not able to recollect, take a look here, HKEY_CLASSES_ROOT\AppID). Many people are confused about what AppID is?? If you are one of them, go on... read the following part.

The AppID concept was introduced as part of the security support in COM. The AppID essentially represents a process that is shared by multiple CLSIDs. All objects in this process share the same default security settings.

DCOM provides mechanisms to externally configure security settings for objects and clients. In the current implementations of DCOM all security policies are enforced at the process level. All objects in a process share the same security policies, unless they programmatically override them. To match this process-wide security configuration, DCOM introduces the concept of an AppID.

AppIDs group the configuration options for one or more DCOM objects into one centralized location in the registry. COM objects hosted by the same executable must map into the same AppID. In-process COM objects that are run in a surrogate process can be forced into the same process by assigning the same AppID to their CLSID entries.

AppIDs are 128-bit GUIDs. Individual classes are mapped onto their AppIDs by adding a named value, "AppID" under their CLSID key in the registry:

[HKEY_CLASSES_ROOT\CLSID\{<clsid>}]
    "AppID" = "{<appid>}"

A named-value "AppID" of type REG_SZ contains the string representation of the AppID. This mapping is used during activation to obtain the default launch permissions.

The actual configurations for an AppID are stored in a newly created registry key hierarchy under:

[HKEY_CLASSES_ROOT\AppID\{<AppID>}]

Applications or their setup programs can directly modify registry keys under the AppID key. Administrators can use the DCOM Configuration utility (DCOMCNFG.EXE) to manually configure default security settings.

Access security

DCOM enforces access security on every method call on an object. If the process does not programmatically override security settings, DCOM reads a security descriptor from the registry. When a call arrives, DCOM authenticates the caller (using whatever security provider is configured) and obtains an access token. It then performs an access check on the security descriptor with the access token.

The content of the value in the registry is a simple copy of the in-memory representation of a self-relative security descriptor:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "AccessPermission" = hex: [self-relative security descriptor]

Launch security

Launch security is enforced whenever a new process needs to be created as part of object activation. DCOM finds the AppID corresponding to the activation request and reads a security descriptor from the registry. It then authenticates the activator and checks the activator's access token against the security descriptor.

The launch security settings are stored in the following registry key:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "LaunchPermission" = hex: [self-relative security descriptor]

Identity

DCOM chooses the identity of an object at the time it launches the process containing the object. It determines, again, the AppID of the process being created and obtains the identity setting from the registry. Three choices are available:

•Run as Activator. The process is created in a new Window Station under the credentials of the caller. Although this option is the default, it is not typically recommended. If multiple users create the same object on a machine, independent Window Stations and processes are created for each user. Window Stations consume a significant amount of resources and their number is limited on current versions of Windows NT.
•Run as Interactive User. The process is created in the Window Station of the locally logged on user. If no user is logged on, the object creation fails. This option is useful for interactive distributed applications as well as during debugging or troubleshooting.
•Run as a fixed user account. The process is created in a non-interactive Window Station corresponding to a specific user account. If a non-interactive Window Station for the account exists, DCOM reuses it. In order to obtain security credentials, DCOM needs the current password for the user account. This password is stored separately in a secured section of the registry.
The security identity is indicated using the following registry entries:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "RunAs" = "InteractiveUser"
[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "RunAs" = "mydomain\myaccount"

Absence of the RunAs value indicates Run as Activator.

How to create AppIDs OR Who creates AppID?

So, you would be wondering who creates this AppID? Are you supposed to create it yourself or that gets generated by regsvr32 or some other tool? Here is how it happens.

While you can modify AppIDs in the Registry by hand, it's better to use the configuration utility called Dcomcnfg.exe, which is on all machines that run Distributed COM. You run this utility by choosing the Run command from the system's Start menu. When you run Dcomcnfg.exe, you see a list of all the registered AppIDs on the local machine. (It might take a few seconds to start up Dcomcnfg.exe the first time you launch it because the utility walks through the list of out-of-process CLSIDs and creates an AppID for each one that needs one.) So, when your component (out of process COM server) is registered with registry, CLSIDs of components in the Server are registered, AppIDs are not generated that time, but when you open DCOMCNFG, it will look for all the CLSID and ask you to create AppID for all components who doesnt have already.

If you have any other question, feel free to ping me.