After a successful authentication, the access check is performed against the access list. The access list is created from the DefaultAccessPermissionregistry settings, or provided programmatically through the DCOMAccessControlobject during server initialization. If the access check is successful, the user is granted access to the computer as a whole. No access check is performed for local activations; access requests are granted automatically.

Windows Mobile contains a DCOMAccessControlobject that the DCOM run time uses for all internal security checking. By default, the DCOMAccessControlobject is initialized with the contents of the AccessPermissionand DefaultAccessPermissionregistry keys. Alternatively, the registry keys can be supplied programmatically through the CoInitializeSecurityfunction. User authentication is based on NTLM verification of user name and password. A list of user names can be used to determine the access privileges of each user. This process is described in the following topics.

On Windows Mobile, after an application modifies security settings it must call the UpdateDCOMSettingsfunction to instruct DCOM to reload the DCOM security settings from the registry.

Also, all DCOM components that are already running must be reloaded for new settings to take effect on them. For example, if a user were to change the LaunchPermissionand AccessPermissionregistry keys for a particular component, and the component had already been launched, the component would need to be reloaded for permissions to take effect.

The EnableRemoteConnectand LegacyMutualAthenticationregistry settings are not supported in Windows Mobile and, if they are present, they are ignored.

The DefaultAccessPermission, DefaultLaunchPermission, AccessPermission, and LaunchPermissionkeys hold a REG_BINARY value that contains the access-control list (ACL) of the principals who can launch classes on the current system. The following code example shows the structure of the ACL.

	Copy Code
typedef struct { WORD wVersion; WORD wPad; GUID gClass; WCHAR szPerms[1]; } Permissions;

The wVersionmember should be set to = 3.

The gClassmember contains the globally unique identifier (GUID) of the AccessControlobject and should be set to CLSID_DCOMAccessControl. This value is ignored in the LaunchPermissionand DefaultLaunchPermissionkeys.

The szPermsmember is an access string that AccessControl::Loadreceives from the IStreaminterface. The following code example shows the BNF syntax used by szPerms.

	Copy Code
szPerms := "" szPerms := AccessList AccessList := IndividualControl AccessList := IndividualControl;AccessList IndividualControl := Principal IndividualControl := -Principal Principal := @groupname Principal := username Principal := @star star := *

Examples

The following string allows user1 and user2 and the administrator group and restricts the user3 user and the villains group.

	Copy Code
"user1;user2;-user3;@administrators;-@villains"

Strings are interpreted sequentially — in other words, if user1 is a member of the group1 group, the following strings will allow user1.

	Copy Code
user1 @group1 @group1;user1 user1;@group1 @group1;-user1 user1;-@group1 user1;-user1 *;-user1;-@group1

The following strings will restrict user1.

	Copy Code
-user1 -@group1 -user1;@group1 -@group1;user1 -user1;user1 -user1;*

This syntax incorporates the following rules:

• Group names are prefixed with the at sign (@).
  
  
• User names or groups are prefixed with a hyphen (-) to disallow access.
  
  
• The wildcard character asterisk (*) or at sign and asterisk (@*) allows all users, while the wildcard character hyphen and asterisk (-*) or hyphen, at sign, and asterisk (-@*) denies all users. The wildcard character asterisk (*) is a group and must be marked as such. Parsers inside DCOM understand both the at sign and asterisk (@*) and the asterisk (*) syntax, but they always use the at sign and asterisk (@*) syntax themselves.
  
  

Also, to be able to use the remote functionality of DCOM, the access credentials of the user must be set in HKEY_CURRENT_USER\Comm\Ident. The computer name should be set to a unique value on the local network in HKEY_LOCAL_MACHINE\Ident. For NTLM authentication to work, the domain must be configured in HKEY_LOCAL_MACHINE\Comm\Redir, as shown in the following code example.

Example

	Copy Code
[HKEY_LOCAL_MACHINE\Ident] Name=WinCEDCOMServer Desc=DCOM server box OrigName=WinCE [HKEY_LOCAL_MACHINE\Comm\Redir] DefaultDomain=REDMOND

Note:
For information about differences between the COM implementation available for Windows Mobile devices and that available for Windows Embedded CE devices, see COM and DCOM in Windows Mobile Devices.

See Also