|
Posted by =?Utf-8?B?RCcnbmkgRXhwbG9yZXI= on October 11, 2006, 2:20 pm
If you were Registered and logged in, you could reply and use other advanced thread options
needed, so it seems to be an issue only with the folder permissions. Outside
of our app I am not able to even open the desired folder in Windows Explorer
and get the "access is denied" error message. I will try to use filemon when
executing our app to see if we need more permissions.
Thank you.
"Roger Abell [MVP]" wrote:
> Well, your sequence is correct and hence not the cause.
> You have defined the group, ACL'd the resource with this,
> defined the account as member of group, and then logged
> in, at which point the account should have the permissions
> that you have ACL'd.
>
> Are you using auditing for failure on the resource so that
> you would get a detail failure message in the event log?
> Such may show that the open action is requesting more
> than just read and execute, such as write, when it asks
> for the handle. Of course, if that is the issue, then what
> you initally described, adding Modify and then removing
> would not cure things (well, there is an end-case for XP
> where sometime some residual excess grant can remain
> that only shows if you look at the Advanced view to see
> the Special details - which is why I was asking about the
> OS version involved). As it is your application you could
> probably examine and see what accesses are requested.
> Otherwise you could try use of filemon from sysinternals.com
> to see details of the failing actions.
>
> You initally also posted that you have similar issue with
> registry grants. I was unclear whether these clear up due
> to your tweaking with the NTFS permissions or whether
> some other action was needed with them.
>
> In summary, what you are doing to provision the account
> sounds correct, and it should work IF what you are granting
> is all that is needed to use the area, and that there is no known
> (mis-)behavior of the ACL'ing mechanisms that would account
> for what you are seeing (other than mentioned above).
>
> Roger
>
> > Thank you for your reply. Here is what I am trying to do:
> >
> > During our install, we have a custom action that creates a local group
> > using
> > the NetLocalGroupAdd() API function, passing in a LOCALGROUP_INFO_1
> > pointer
> > for one of the function's parameters. After rebooting, I log in as
> > administrator and create a new user. I then open the user's properties,
> > go
> > to the "Member Of" tab and add the new local group created by our install.
> > The security properties for our installation folder are set based on the
> > usage of our new local group (we set read/execute, list folder contents,
> > and
> > read permissions on the folder). I log out from the Administrator account
> > and log back in using my new test user account. Under the new test user
> > account I find that I cannot access our installation folder or run the
> > application. I get the "<folder> not accessible. Access is denied" error
> > message. I am currently performing these actions on Windows Server 2003
> > SP1.
> >
> > "Roger Abell [MVP]" wrote:
> >
> >> > As part of our product's installation, we create a new security group
> >> > to
> >> > allow/restrict access to our product's installation folder, registry
> >> > entries,
> >> > etc. The problem is that if we create a new user account, then add
> >> > that
> >> > new
> >> > user to our new security group, the user cannot access the product's
> >> > installation folder even though that user is part of our group that has
> >> > permission to access that folder (get the "<folder> is not accessible.
> >> > Access is denied" error message). If we open the the folder's security
> >> > properties, check "modify" and then uncheck "modify" for our new group,
> >> > everything works and the new user can now successfully access the
> >> > folder,
> >> > registry entries, etc. Am I missing something or is this a known
> >> > behavior?
> >> >
> >>
> >> Well, yes you probably are missing something. But from what you have
> >> said it is not easy to determine what. And no, this is not a known
> >> behavior.
> >>
> >> What is the OS where the install happens, what is the precise sequence of
> >> events (new user login _afer_ configured to be in the group?) etc.
> >>
> >> It is quite peculiar that adding and removing Modify on the directory
> >> would
> >> clear up access to the registry, for example - well actually it is pretty
> >> odd
> >> it is needed at all (i.e. for the directory either).
> >>
> >> --
> >> Roger Abell
> >> Microsoft MVP (Windows Server : Security)
> >>
> >>
> >>
> >>
>
>
>
| 
XML site map