COM Access Control (Windows Embedded CE 6.0)

1/6/2010

After a successful authentication, the access check is performed against the access list. The access list is created from the DefaultAccessPermission registry settings, or provided programmatically through the DCOMAccessControl object 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 Embedded CE contains a DCOMAccessControl object that the DCOM run time uses for all internal security checking. By default, the DCOMAccessControl object is initialized with the contents of the AccessPermission and DefaultAccessPermission registry keys. Alternatively, the registry keys can be supplied programmatically through the CoInitializeSecurity function. 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 Embedded CE, after an application modifies security settings it must call the UpdateDCOMSettings function 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 LaunchPermission and AccessPermission registry keys for a particular component, and the component had already been launched, the component would need to be reloaded for permissions to take effect.

TheEnableRemoteConnectand LegacyMutualAthenticationregistry settings are not supported in Windows Embedded CE and, if they are present, they are ignored.

The DefaultAccessPermission, DefaultLaunchPermission, AccessPermission, and LaunchPermission keys 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.

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

The wVersion member should be set to = 3.

The gClass member contains the globally unique identifier (GUID) of the AccessControl object and should be set to CLSID_DCOMAccessControl. This value is ignored in the LaunchPermission and DefaultLaunchPermission keys.

The szPerms member is an access string that AccessControl::Load receives from the IStream interface. The following code example shows the BNF syntax used by szPerms.

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.

"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.

user1
@group1
@group1;user1
user1;@group1
@group1;-user1
user1;-@group1
user1;-user1
*;-user1;-@group1

The following strings will restrict user1.

-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

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

**For more registry settings information, see COM and DCOM Registry Settings.

For more information about local and pass-through authentication, including usage and registry configuration instructions, see Security Support Provider Interface Architecture.**

See Also

Concepts

COM and DCOM Security
COM Authentication
DCOM Security Configuration Utility
Developing Secure ActiveX Controls
COM and DCOM Registry Settings

Other Resources

Component Services (COM and DCOM)
Enhancing the Security of a Device