none
Access denied for folder when permissions set with WMI RRS feed

  • Question

  • Hi,

    When I add/modify access rights based on the Win32_ACE class, there seems to be a difference in the result, then when setting it with the GUI in Windows.

    The situation is as follow:
    I want to set Modify access on a remote folder, but also want to avoid deletion of the folder itself. This can easily be done by setting "deny delete on this folder only" in addition to "allow modify to this folder, files and subfolders". So far no issue.

    Now I notice that, although the GUI shows exactly the same result in advanced settings of the security property, the folder set with WMI script gives a deny when opening it with the user account. The same folder, set with the same security and result in the advanced tab, but set in the GUI, works fine.

    Note: The reason that I use WMI is because the remote system is a standalone machine, not sharing the same domain or trust.

    I compared the ACEFlags, AceType and AccessMask for both the GUI set and script set permissions, and they are exactly the same.

    GUI => AccessMask:1179817 AceType:0 iAceFlags:3
    Script => AccessMask:1179817 AceType:0 iAceFlags:3

    What a strange world we live in... :-)

    Any idea?

    Thursday, July 24, 2014 6:34 AM

Answers

  • I found the solution thanks to the Rohn pointing out that only the allow ACE was listed. The deny ACE was also there, but I did not capture it. When I compared the deny entry with the ACE value set by the GUI, I noticed that I added the SYNCHRONIZE value with the DELETE value. Removing the SYNCHRONIZE value and only setting the DELETE value, solved it. And of course you don't see the SYNCHRONIZE value in the interface. Case closed.

    Thanks again!

    • Marked as answer by WiVM Thursday, July 24, 2014 6:06 PM
    Thursday, July 24, 2014 6:06 PM

All replies

  • What GUI are you referring to?

    The "Security Wizard" does not show Access Mask or flags as numbers.


    ¯\_(ツ)_/¯

    Thursday, July 24, 2014 10:23 AM
  • What GUI are you referring to?

    The "Security Wizard" does not show Access Mask or flags as numbers.


    ¯\_(ツ)_/¯


    Graphical User Interface
    Thursday, July 24, 2014 10:33 AM
  • What GUI are you referring to?

    The "Security Wizard" does not show Access Mask or flags as numbers.


    ¯\_(ツ)_/¯


    Graphical User Interface

    What program are you referring to?  How are you seeing this in the GUI.  Is it just written on the desktop?

    Are you asking about WBEMTEST?

    You have to be clear about your question.


    ¯\_(ツ)_/¯

    Thursday, July 24, 2014 11:00 AM
  • What GUI are you referring to?

    The "Security Wizard" does not show Access Mask or flags as numbers.


    ¯\_(ツ)_/¯


    Graphical User Interface

    What program are you referring to?  How are you seeing this in the GUI.  Is it just written on the desktop?

    Are you asking about WBEMTEST?

    You have to be clear about your question.


    ¯\_(ツ)_/¯

    With GUI I refer to the operating system interface. In other words, when I set the exact same permissions on the folder with the Windows interface, the access is properly working. When I do the same with WMI, it denies. The most likely reason is that WMI forgets to set something that the user interface does. But when I look at the permissions tab in the interface, both are identical. And also when I read out the ACE properties, they are both identical. Still... the permissions set with WMI deny, those with the interface work as they should be.

    I think it has to do with combination "Modify" and deny delete for this folder only. It really is set as deny to delete the folder only. I do it regularly for folders, works without any issue. But to do so you need to use advanced permissions, and there are two entries in the advanced tab: one for the deny and another one for the allow. This is normal and by design. But why does the folder return a FULL deny when accessing it? It should only deny to delete the folder, not to access it. Once again, this works when set with the normal user interface (Windows), it fails with WMI, but both look to be set the same. I must be overlooking some minor detail or it is a bug...


    • Edited by WiVM Thursday, July 24, 2014 11:10 AM
    Thursday, July 24, 2014 11:09 AM
  • What Operating System Interface are you referring?  What program?

    You are being obtuse. What is it that you are trying to compare. THe settings in WMI cannot be directly compared to anything in the Security Wizard.


    ¯\_(ツ)_/¯

    Thursday, July 24, 2014 2:34 PM
  • What Operating System Interface are you referring?  What program?

    You are being obtuse. What is it that you are trying to compare. THe settings in WMI cannot be directly compared to anything in the Security Wizard.


    ¯\_(ツ)_/¯

    Just the properties of the folder in Windows on the security tab. The result is the same for both the permissions set with the interface as well as the one set with the WMI script. The two references you see are just taken with WMI:

    Set by Windows interface => AccessMask:1179817 AceType:0 iAceFlags:3 
    Set by WMI script => AccessMask:1179817 AceType:0 iAceFlags:3

    This are the values "AceFlags", "AceType" and "AccessMask" from management class WIN32_ACE: http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx

    I just want to show that the actual ACE object returns the same values for both methods, but the effect appear to be that the script set permission are denied. And I am looking for the reason why.

    Thursday, July 24, 2014 3:44 PM
  • What Operating System Interface are you referring?  What program?

    You are being obtuse. What is it that you are trying to compare. THe settings in WMI cannot be directly compared to anything in the Security Wizard.


    ¯\_(ツ)_/¯

    Just the properties of the folder in Windows on the security tab. The result is the same for both the permissions set with the interface as well as the one set with the WMI script. The two references you see are just taken with WMI:

    Set by Windows interface => AccessMask:1179817 AceType:0 iAceFlags:3 
    Set by WMI script => AccessMask:1179817 AceType:0 iAceFlags:3

    This are the values "AceFlags", "AceType" and "AccessMask" from management class WIN32_ACE: http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx

    I just want to show that the actual ACE object returns the same values for both methods, but the effect appear to be that the script set permission are denied. And I am looking for the reason why.


    Can you provide the script that you're using to create the ACE(s) and add them? If I'm understanding what you're trying to do, there should be two ACEs created: one to allow the modify access and one to deny the folder deletion. The ACE you're showing is just an allow ACE (AceType 0).
    Thursday, July 24, 2014 4:13 PM
  • But these two values are identical????

    Set by Windows interface => AccessMask:1179817 AceType:0
    iAceFlags:3 

    Set by WMI script => AccessMask:1179817 AceType:0 iAceFlags:3 <o:p></o:p>


    I do not see a difference.

    You are talking about "both methods"  What two methods?  YO are not showing any methods - only results.

     


    ¯\_(ツ)_/¯

    Thursday, July 24, 2014 4:20 PM
  • What Operating System Interface are you referring?  What program?

    You are being obtuse. What is it that you are trying to compare. THe settings in WMI cannot be directly compared to anything in the Security Wizard.


    ¯\_(ツ)_/¯

    Just the properties of the folder in Windows on the security tab. The result is the same for both the permissions set with the interface as well as the one set with the WMI script. The two references you see are just taken with WMI:

    Set by Windows interface => AccessMask:1179817 AceType:0 iAceFlags:3 
    Set by WMI script => AccessMask:1179817 AceType:0 iAceFlags:3

    This are the values "AceFlags", "AceType" and "AccessMask" from management class WIN32_ACE: http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx

    I just want to show that the actual ACE object returns the same values for both methods, but the effect appear to be that the script set permission are denied. And I am looking for the reason why.


    Can you provide the script that you're using to create the ACE(s) and add them? If I'm understanding what you're trying to do, there should be two ACEs created: one to allow the modify access and one to deny the folder deletion. The ACE you're showing is just an allow ACE (AceType 0).

    That is correct there are (or should be) two ACEs. I cannot get hold on my source right now (will be later today), but my code is based on this source: http://www.minasi.com/forum/topic.asp?TOPIC_ID=7501

    What I basically do is getting the DACL properties, loop through it to check that the user exists that I want to update. If it does I check that the current AceType is of the same type (allow or deny) that I am updating/adding. If that type is a match, I replace the ACE object with the new Flag, Type and Mask using a Win32_ACE object. If type type doesn't match, then I add both the current ACE with the new ACE at the same time. I noticed that if I don't do it at the same time, only the last remains. If the user doesn't match I check that the AceFlags is not equal to 16 (inherit) and then add the original ACE object in the ACE array. At the end I add the new ACE if the user was not found at all (new). The array of individual ACE objects is added to List of managementobjects and then again linked to the DACL value.


    • Edited by WiVM Thursday, July 24, 2014 5:10 PM
    Thursday, July 24, 2014 5:10 PM
  • I still do not see how that has anything to do with what you see in the GUI. The GUI is a list of string names for flags, types and permissions.  There are no numbers to match.

    Minasi's forum is just a discussion on how to decode a mask.  Is says nothing about how to compare a mask to a GUI.


    ¯\_(ツ)_/¯

    Thursday, July 24, 2014 5:20 PM
  • I found the solution thanks to the Rohn pointing out that only the allow ACE was listed. The deny ACE was also there, but I did not capture it. When I compared the deny entry with the ACE value set by the GUI, I noticed that I added the SYNCHRONIZE value with the DELETE value. Removing the SYNCHRONIZE value and only setting the DELETE value, solved it. And of course you don't see the SYNCHRONIZE value in the interface. Case closed.

    Thanks again!

    • Marked as answer by WiVM Thursday, July 24, 2014 6:06 PM
    Thursday, July 24, 2014 6:06 PM