|
Posted by Roger Abell [MVP] on January 8, 2006, 11:24 am
Please log in for more thread options Try 3 and if these are domain accounts or explicitly stated local accounts
being used then 1 applies
Use of 2 is a last resort and whould for me rule out your application
as an allowed installable.
> Hi Roger,
> Thanks for the response. Unfortunately, I am the vendor :-) I have 3
> customers with the problem but the product is no longer in development and
> I
> am not familiar with the code.
>
> Yesterday I read the SP1 release notes in detail and I am confident that
> the
> changes to DCOM and certificate services are the culprit. What I don't get
> yet is do I:
> 1. add the non-adminstrative users to the new DCOM Remote users group
> created by SP1
> 2. change the computerwide DCOM access rights through
> MMC/Computer/Properties/COM Settings
> 3. Create an ACL that grants everybody launch and access to the DCOM
> application on the server.
>
> or some combination of the above. Items 1 & 3 i do not know how to do yet.
>
> Any more help appreciated. Nick.
>
> "Roger Abell [MVP]" wrote:
>
>> The first thing you should do is check with the vendor of the
>> application.
>> SP1 for W2k3 implemented tightened control on DCOM component launch
>> and access if the component is relying on default permissions (as opposed
>> to its having specified component specific permissions).
>> Since this change was first introduced much earlier during the beta cycle
>> for XP SP2 it is likely the vendor has faced the issue already, so there
>> may be no need for you to reinvent the wheel.
>>
>> --
>> Roger Abell
>> Microsoft MVP (Windows Server : Security)
>>
>
|