COM Access Control (Windows CE 5.0)
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 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 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 theLaunchPermission 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 **LegacyMutualAthentication****registry settings are not supported in Windows 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=WinCEDCOMServerDesc=DCOM server boxOrigName=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.
See Also
COM and DCOM Security | COM Authentication | DCOM Security Configuration Utility | Developing Secure ActiveX Controls | COM and DCOM Registry Settings | Component Services (COM and DCOM) | Enhancing the Security of a Device
Send Feedback on this topic to the authors