Archived Boards > Network Extenders

wntAccessGet error

(1/4) > >>

etippelt:
Basically, I am trying to write a utility that will scan a directory tree and list the permissions on the files and folders.
It's working, apart from a problem with wntAccessGet which on certain "files" reports WIL Extender Error 542: Invalid User/Group Name.

Having had a look in the displayed permissions of the sample file concerned, (C:\ProgramData\regid.1991-06.com.microsoft\regid.1991-06.com.microsoft Microsoft Office Professional Plus 2013.swidtag), there are two "groups" with a different symbol which are causing the error. The groups in this case are called ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES.
Instead of the "Two person" symbol, the symbol looks like a couple of sheets of paper with images on them.  (see attached image)
Any ideas why these groups are causing an error with wntAccessGet when they are happily retrieved by the wntAccessList command.

Thanks
Ed

td:
The two groups are special system groups used to grant access to objects by "Windows Store" apps or "UWP" apps or whatever MSFT is calling them this week. 

Assuming you are running with sufficient privileges (most users can read privileges),  can't say why wntAccessGet is not recognizing those groups.  The function happily returns permissions for those groups on my Windows 10 workstation.  You might want to check your function parameters to make sure they are correct.  You could try using the two group's SIDs instead of their names but that was not necessary on my system.     

td:
The simple test used to check the access function:


--- Code: Winbatch ---AddExtender("wwwnt34i.dll",0,"wwwnt64i.dll")         ; Installs a WIL extender dll.
strPrivs1 = wntAccessGet("", 'C:\ProgramData\regid.1991-06.com.microsoft', 'ALL APPLICATION PACKAGES', 300)
strPrivs2 = wntAccessGet("", 'C:\ProgramData\regid.1991-06.com.microsoft', 'ALL RESTRICTED APPLICATION PACKAGES', 300)
 

etippelt:
Hi td,
Thank you for the script suggestion, but in your example, you are quoting a folder location, and not a file within that folder.
So for example, in my script, I am running wntAccessGet on the following resource:  C:\ProgramData\regid.1991-06.com.microsoft\regid.1991-06.com.microsoft Microsoft Office Professional Plus 2013.swidtag
It is that request that is causing the error. I am basically using the file extender to itemise the list of files in a subdirectory tree and then passing each file to the wntAcccessGet command. The code extract looks like this:

fh=FileOpen(outfile,"WRITE") 
Edcount=0    ;pointer to keep track of search hits
If silent==0 then BoxOpen("","")

;Start of search loop
For i=1 to param0
Extvar=param%i%

   If silent==0 then BoxTitle("Searching from %Drivep%")
   If StrSub(Drivep,StrLen(Drivep),1)!= "\" Then Drivep=StrCat(Drivep,"\")
   
   handle=fafOpen(Drivep,Extvar,144)

:start
        Edfile=fafFind(handle)
        if Edfile=="" then goto finish 
        Edcount=Edcount+1
        pos=StrIndex(Edfile,"\",0,@backscan)+1
        filename=StrSub(Edfile,pos,-1)
        FileWrite(fh,Edfile)

        aList = wntAccesslist("",EdFile,300,3)
        ;Get the list of items
        aListcount = ItemCount(aList, @TAB)
        If aListcount > 0
          For j=1 to aListcount
          group=ItemExtract(j,aList,@TAB)
          ;Message("",Group)
           If group == "APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES" || group == "APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES"
            records = "Not Read"
           Else
            records = wntAccessGet("",EdFile,group,300,0)
           EndIf
          ;Message("",records)
          group = strCat(group,@TAB,records)
          FileWrite(fh,group)
          Next
        Endif
        FileWrite(fh,@CRLF)

        if silent==0 then BoxText(EdFile)
        goto start
:finish
   fafClose(handle)

Next

Fileclose(fh)


You can see where I have added some code to detect the problem groups and not try to extract the permissions, but before I did this, the code bombed every time.

So let me know what I might have overlooked!

Cheers
Ed

ChuckC:
Take a look at your wwwbatch.ini file, as the various wnt*() extender-based functions are pretty good at recording diagnostic information there when an underlying Win32 API function call fails.

If I'm understanding things correctly, wntAccessList() is able to identify these accounts as security principals to which permissions have been assigned on the specified files, and the account names are returned in a delimited list.  However, calls to wntAccessGet() for these account names results in an error which means that the account name couldn't be translated into a SID value.   If that's the case, then the underlying Win32 API functions used to convert between SID and account names are most likely failing to "round trip", with LookupAccountSidW() being able to take the SID value from an ACE in the DACL and convert it to "APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES", but then, later, a call to LookupAccountNameW() fails convert that fully-qualified account name into a SID value.

IIRC, there's code buried down inside the Win32 Network Extender that deals with this type of issue since there are certain well-known domain names that get returned when converting a SID to an account name that cannot be present when attempting to convert an account name back to a SID value.  If the problem is what I think it is, though, then "APPLICATION PACKAGE AUTHORITY" is also another one of those types of well-known domain names.

To test that theory, try calling wntAccessGet() for those accounts, but trim off the pseudo-domain prefix up to and including the '\' character, such that you only try to get the assigned permissions for "ALL RESTRICTED APPLICATION PACKAGES" and "ALL APPLICATION PACKAGES".  If that is successful, then you'll have to test for the presence of the well-known domain prefix "APPLICATION PACKAGE AUTHORITY\" and remove it from the values returned by wntAccessList() before making calls to wntAccessGet().

If this proves to be the case, then, long term, the Win32 NetWork extender may need to have some slight modifications made to it w/respect to the internal methods it uses for performing translations between SID values and account names so that the problem can be silently dealt with and prevented from happening regardless of whether or not you pass in the account name with or without that particular well-known domain prefix on it.

Navigation

[0] Message Index

[#] Next page