Re: DCOM Access Permissions

From: Roger Abell [MVP] (mvpNoSpam_at_asu.edu)
Date: 12/10/04 

Date: Thu, 9 Dec 2004 16:54:04 -0700

I will acknowlege that the initial MS plans for Com based roles
seems to have never come into use, and that many (most) admins
have no concept of dcomcnfg.
If your application needs a specific identity to have access as
for launch, that is not covered by the defaults for components,
then - provided that you know the account or better have defined
a group - you should be able to just adjust the component permissions,
which if I am not mistaken are just ACLs on the reg keys. If by
administration done by the component you mean within Windows
rather than application internal, then instead of programmatic
override you could configure the identity used by the com package
when it is instanced (can be done by the ComAdmin api - if you
know the account).
Of course, I am tossing out ideas without knowing all aspects of
the system's architecture . . . 

-- 
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA,  MCSE W2k3+W2k+Nt4
"Jayme Pechan" <jayme.pechan@whitefeld.com> wrote in message 
news:eg6o34g3EHA.1524@TK2MSFTNGP09.phx.gbl...
>I would agree with you but Microsoft seems to think it must be done since
> the wizard puts it there for exe's.  Also, I wouldn't do this if I 
> expected
> an arbitrary client to connect to it but in this case, the installer also
> installs a web application that must connect to it for administration.
> These are 2 components of the same product, it becomes more of a hassle to
> the customer to install a product then have to go in and set the security
> for something that doesn't effect their end users at all.  If I was 
> required
> to do this, I would probably never get it working and probably just throw 
> it
> out and use someone else's product.  I believe that is why Microsoft 
> expects
> you to call this function.
>
> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
> news:e8cRbmM3EHA.4008@TK2MSFTNGP15.phx.gbl...
>> That is interesting.  I was starting to think it may be on
>> XP SP2 where there was issue, due to changes made to
>> RPC and DCOM authorization.
>>
>> Just FYI, I am not a fan of apps that utilize programmatic
>> security in COM components, and especially not of those
>> which use the little know ability to substitiute principal
>> in the first call.
>>
>> -- 
>> Roger Abell
>> Microsoft MVP (Windows  Security)
>> MCSE (W2k3,W2k,Nt4)  MCDBA
>> "Jayme Pechan" <jayme.pechan@whitefeld.com> wrote in message
>> news:Ohz3GCL3EHA.2804@TK2MSFTNGP15.phx.gbl...
>> > It appears to be a problem with the CoInitializeSecurity call on 
>> > Windows
>> > 2000 SP4.  On Windows 2003 and Windows XP, it works correctly.
>> >
>> > "Jayme Pechan" <jayme.pechan@whitefeld.com> wrote in message
>> > news:e13cAe%232EHA.2192@TK2MSFTNGP14.phx.gbl...
>> > > I have built an application that requires AccessPermissions to be set
> on
>> > the
>> > > COM Service.  One of the requirements is that after the install, the
>> user
>> > > must go into DCOMCNFG and add permission for the ASPNET user to 
>> > > access
>> the
>> > > COM Service.  I have found that this adds a binary entry to the AppID
> in
>> > the
>> > > registry.
>> > >
>> > > My question is, is there a way to do this programmatically?  Perhaps
> the
>> > > AccessPermission can be exported then imported during the install? 
>> > > My
>> > > suspicion is that that would be impossible since I have to assume 
>> > > that
>> the
>> > > binary data includes information on the actual user that requires
> access
>> > to
>> > > the resource.  I would imagine that on each machine, this may be
>> > different.
>> > > The name is likely to be the same on each but the ID for this user is
>> > > probably going to be different.  Does anyone have any thoughts
> regarding
>> > how
>> > > to go about doing this?  Thanks
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>