WntAccessAdd 303 not applying to subfolders and files

[limnos]

We used this command for some years to add rights to dirs and all subdirs and files.  Currently, it only appears to add the rights to the target folder, but nothing below that.  Is there a different way to do this now?  Reason we need it, the new Oracle 19c client installer smokes off Authenticated Users as part of its install, and we need it back on there for the root folder and all sub dirs.

wntaccessadd("", "C:\Oracle", "Authenticated Users", 303, "Dir2K:Modify")

[td]

You need to review the rather lengthy documentation for the wntAccessAdd function.

https://docs.winbatch.com/mergedProjects/Win32Network/WIN32NET_WSN013.htm

Take notice of the red "* Note:". It explains why 303 behaves the way it does on your system.

While it doesn't discuss your specific issue this Tech Support article discusses inherited ACEs:

https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Networks~-~Servers/Microsoft~Client/wNT+wntAccessAdd~and~Inherited~Rights.txt

As for a solution, you will need to wait until Chuck C sees your post and provides commentary, spin through all the subfolders and files changing individual permissions, or attempt to set an inherited ACE on the top-level directory. The help file documentation shows how to create inherited ACEs using a custom access-string parameter.

[ChuckC]

As Tony already stated, the following:

wntaccessadd("", "C:\Oracle", "Authenticated Users", 303, "Dir2K:Modify")

Is effectively executed as the following:

wntaccessadd("", "C:\Oracle", "Authenticated Users", 300, "Dir2K:Modify")

As described in the help topic for the wntAccessAdd() function.

The pre-defined access string, "Dir2K:Modify", equates to the following:

"0:3:1245631"

Please note the ACE flags value of "3" in that access string.  It indicates that the ACE that is being added should be inheritable by all subfolders and files, the the underlying Win32 API function that is used to set the security on "C:\Oracle" being responsible for propagating all inheritable ACEs to all subordinate objects.

Inheritance can be blocked by setting the "Protected DACL" flag on the security descriptor of a directory or file, so that is something to investigate.  Another thing to verify is that the process executing the script actually has been granted access rights to modify the permissions or is running sufficiently elevated to do so via usage of LSA privileges.

[limnos]

It was far easier just to call icacls to do it.  This works like champ.

Runwait("C:\Windows\System32\icacls.exe", 'C:\Oracle /grant "Authenticated Users":(OI)(CI)M /T /C /L /Q')

[td]

Yes, we are all aware of the icacles.exe utility but many don't like to use it for various reasons.

And thanks, Chuck. I should have checked what the predefined access string was actually setting.

[ChuckC]

With the pre-defined access string having been confirmed to be using the correct ACE flags for inheritance, a report of wntAddAccess() not working makes me wonder what exactly is going wrong.  The code for that function is extremely well vetted from both the development side and from the end-user side in terms of countless usages where the only failures had to do with incorrect usage [e.g. input parameter values are incorrect] or the run-time environment was not compatible due to a lack of effective access [e.g. granted permissions or administrative privileges] to modify security.

With only seeing the OP's single line example, there's no additional context around the usage of the function, such as what does the rest of the script look like?  Have errors been suppressed so that it silently fails?  What does a low-level before & after dump of the SD's [Security Descriptor's] Control Flags & DACL [Discretionary Access Control List] look like?

Another possibility that I'd need to go back and test with is whether or not the domain name "NT AUTHORITY" needs to be used with the "Authenticated Users" group name.  Due to this well-known group having a SID of "S-1-5-11", it is documented as being under the "NT" authority, which applies to all SID values starting with "S-1-5-*".  As such, the fully qualified name would be "NT AUTHORITY\Authenticated Users".  There are some times when this decoration of the name is required for the account to be properly resolved to a SID value down inside the extender.  All of the Win32 API functions that manipulate security make use of SID values, not account names, and there is all kinds of translation between SID and account name that occurs down in the code.  To further complicate things, not all code that was ever written in the world that performs security management on the Windows NT platform family makes the same set of assumptions about account names and so they may internally "fudge" some things to facilitate abbreviated "short cut" names for some accounts.

[td]

Without the OP responding the cause will have to remain a mystery. Other users haven't mentioned any issues with the function so it is likely a one-off.  However, as time permits I will do some testing to determine if there are any code-related problems.

[td]

Belatedly did some wntAccessAdd function testing using "Authenticated User" with an Access-string of "0:1:1245631|0:1:-536805376".  Items created in the target folder after the call all had the "modify" permissions for "Authenticated User"  inherited from the target folder.