Administrator privileges

[SeaFire]

To automate Word 2007, on a new system it takes administrator privileges, on
another, older system -- a regular user will do fine. What permission
changes must I make to allow Word 2007 to work under a generic user account?

 

[SvenC]

Hi SeaFire,

To automate Word 2007, on a new system it takes administrator
privileges, on another, older system -- a regular user will do fine.

I doubt that. A regular user should always be able to execute macros.

What permission changes must I make to allow Word 2007 to work under
a generic user account?

What part of the macro is not executing?
What error do you get?

If nothing is executed at all, please check you macro security settings:
if you have unsigned macros then you need to lower the default
macro security settings.

 

[SeaFire]

This is an automation startup issue through DCOM. There are no macros
involved. Adding the user account to the Administrators group allows Word to
start and open/save a document. Starting Word as a regular user fails with
no helpful advice on what is really going wrong.

 

[SvenC]

Hi SeaFire,

This is an automation startup issue through DCOM. There are no macros
involved. Adding the user account to the Administrators group allows
Word to start and open/save a document. Starting Word as a regular
user fails with no helpful advice on what is really going wrong.

Then start dcomcnfg.exe and look for "Microsoft Office Word ... Document".
Look at the security properties and set the launch and access permissions
like you need them.

 

[SeaFire]

I have to configure DCOM permissions in order to allow my code to run. Maybe
I will notice something obvious the next time I take a look at the two
systems.

Since there are a couple of permissions to talk about, I will focus on one
aspect of the issue by changing the identity of the user to a specified user
instead of using the interactive or launching user. On one system, setting
Word 2003 document DCOM user permissions up with administrator privileges
works (which is not what I want), and on another system permissions can be
set up as a regular user (which is what I want, although not having the
component use the permissions of the calling user is questionable). The two
systems were supposed to be set up to be identical with regards to Office
2007, but obviously there are one or more differences because one of the
systems requires the user to be a local Administrator. The 'older' system is
being more permissive than a fresh installation of the operating system and
Office 2007.

I am looking for the small permissions tweak/configuration that obviously
must be done to allow Word to be programmatically started without granting
the user full administrative privileges. It might be permissions to some
part of the file system. It might be something else, but I want to know how
to grant only one specific user enough permissions to run Word 2007 (and
maybe Excel in the future) through DCOM -- without jamming while trying to
start Word in the variable declarations part of my code, before even getting
to my try-catch block.

I will continue to play around with the permissions situation, but I was
hoping to be directed to a very simple permission configuration table, for an
obvious need, without going through a discussion of different problems and
paths taken, such as how to report which user is attempting to access a DCOM
component. That is another related issue. Should the question be put on a
different thread?

I am attempting to identify how to keep the computer system as secure as
possible within reason, for example, I do not believe granting everybody
administrative privileges is a wise security policy. Saying that nobody
knows what permissions are necessary to automate Word -- is a flawed security
policy. This is like my WIA question. Adding my code (I am making an
assumption that my code is part of the problem) leaves me with two known
situations: a DCOM error OR one turns on the WIA service (a potential
security risk but no error happens). There seems to be no way in the newer
system to restrict access in a rational, controlled manner. Setting up the
two computer systems the same way is yielding different results, of course,
part of the older system's installation process happened before I came on the
scene. This gets back to the question of exactly how to configure
permissions to run Word 2007 through DCOM. Sure, one solution is to turn on
an extra service and run Office as an administrator, but is this the most
secure solution possible?

 

[SvenC]

Hi SeaFire,

I have to configure DCOM permissions in order to allow my code to
run. Maybe I will notice something obvious the next time I take a
look at the two systems.

Since there are a couple of permissions to talk about, I will focus
on one aspect of the issue by changing the identity of the user to a
specified user instead of using the interactive or launching user.

Don't do that! You could cause strange behaviour when an Office
app is running with different credentials than the interactive user who
is using that app.

On one system, setting Word 2003 document DCOM user permissions up
with administrator privileges works (which is not what I want), and
on another system permissions can be set up as a regular user (which
is what I want, although not having the component use the permissions
of the calling user is questionable). The two systems were supposed
to be set up to be identical with regards to Office 2007, but
obviously there are one or more differences because one of the
systems requires the user to be a local Administrator. The 'older'
system is being more permissive than a fresh installation of the
operating system and Office 2007.

I think I remember that the default permissions have been strengthend
with SP2 for Windows Server 2003. Maybe your systems are on different
SP levels or at least on different hotfix levels.

It might also be restrictions which have been applied through group
policies if those two computers are members of a domain.

I am attempting to identify how to keep the computer system as secure
as possible within reason, for example, I do not believe granting
everybody administrative privileges is a wise security policy.
Saying that nobody knows what permissions are necessary to automate
Word -- is a flawed security policy.

The user who wants to automate Word must have launch and
access permissions.