New Version of ExFolders Fixes Non-Canonical ACLs


When I wrote ExFolders, I thought the non-canonical Exchange ACL problems were permanently behind us in Exchange 2010. For this reason, ExFolders did not include any functionality to deal with non-canonical ACLs. It turns out I was overly optimistic.

In the last few weeks I’ve seen a couple of cases where customers ended up with non-canonical ACLs on public folders in Exchange 2010. They were seeing events like this:

Log Name: Application
Source: MSExchangeIS
Event ID: 9775
Task Category: General
Level: Warning
Description:
The mailbox ” contains a folder ‘My Public Folder’ with a security descriptor that violates the canonical format.

Trying to modify the permissions with Add-PublicFolderClientPermission would result in this error:

MapiExceptionNonCanonicalACL: Unable to modify table. (hr=0x80004005, ec=2409)

Each affected environment only had one folder in this state, so it does not appear to be a widespread problem, such as when something scanned the M: drive back in the Exchange 2000 days.

Even so, customers need a way to fix these problems. Since PFDAVAdmin fixed this for older versions of Exchange, it made sense to include this functionality in ExFolders for Exchange 2010.

Note, however, that what I’ve added to ExFolders is very different from the “Fix Folder DACLs” option in PFDAVAdmin. “Fix Folder DACLs” would run through your whole folder hierarchy looking for all kinds of problems and adjusting the DACL portion of the ACL.

What I’ve added in the October 20th, 2011 release of ExFolders for 2010 Sp1 is something much more limited in scope. When you right-click on a folder, you’ll see a “Clear Permissions” option. The previous build actually had this option as well, but it would not work on non-canonical ACLs. In this latest version, the “Clear Permissions” option accesses the raw security descriptor (similar to what PFDAVAdmin used to do) so it can clear it even when it’s non-canonical. You can use this to set one specific folder back into a good state and then manually set the permissions to whatever they should be.

This will be good enough to address these one-off non-canonical ACLs. I don’t expect we’ll be seeing widespread problems with this, but I’ll be keeping an eye on it. Hopefully there will be no need to introduce a bulk folder ACL fix again.

Comments (23)

  1. Anonymous says:

    Hi Xaxe,

    You're trying to change mailbox permissions (i.e. Add-MailboxPermission), correct? If so, I don't know of any tool for that on 2010 (you can use FixMailboxSD on 2007/2003). The easiest fix is probably export to PST, mail-disable the user, mail-enable the user, import from PST. Not fun.

    Do you know how the mailbox got into this state? If you're able to reproduce it, I would love to know the steps needed to create a non-canonical mailbox ACL.

  2. Anonymous says:

    Is there a way to use the "Clear permissions" recursive on subfolders ?

  3. Anonymous says:

    The SP1 version works for SP1 and later, so there's no separate version for SP2.

  4. Anonymous says:

    Normally, you want to interact with folder permissions via PR_ACL_TABLE as described in support.microsoft.com/…/297493. If you use this approach, you don't have to worry about the proper order of ACEs, because Exchange handles it for you.

    If you want to make things very difficult, you can use the PR_NT_SECURITY_DESCRIPTOR property. In that case, it's up to you to order the ACEs properly and make sure the other rules of Exchange canonical order are followed. This is generally a bad idea.

    Both properties are exposed in MfcMapi.

  5. Anonymous says:

    Wow, do you have any idea how that happened to all those folders? I'd be very curious to know.

    You can run this against a whole tree of folders, but the option is sort of hidden.

    1. Go to Tools->Custom Bulk Operation.

    2. Click Add.

    3. Choose "Clear Folder Permissions" and click OK.

    4. Leave the checkbox to "Restore previous permissions" checked, otherwise all permissions will be lost when you do this. Click OK.

    5. In the Custom Bulk Operation window, click OK to start the operation.

    This is dangerous, so please export the permissions first and make a backup.

  6. Anonymous says:

    Karsten, sorry I seem to have missed your comment. Replace should have worked. However, I’m working on a new tool to replace ExFolders. It doesn’t have that functionality yet, but I’ll put it on the list. It’s getting hard to maintain the old ExFolders code.

    Mike, that is very interesting! I will have to try that and see if I can reproduce a non-canonical ACL that way. Unfortunately, your only option for dealing with the mailbox ACL (what you see with get-mailboxpermission) in 2010 and later is Powershell. So if the Powershell cmdlets don’t work, you are out of luck. In past versions of Exchange we could go in via CDOEXM to modify the raw mailbox ACL and fix it, but that is no longer possible.

  7. Anonymous says:

    great article but I have not gotten around to resolving the error I receive when I run Add-PublicFolderClientPermission

  8. Anonymous says:

    No there isn't. Do you actually have an environment where there's a whole tree of folders in this state?

  9. Anonymous says:

    Hi,

    Will you make a new version of this tool for SP2 or it's fully compatible ?

    Thanks

  10. XAXE says:

    Hi,

    I've posted this to technet (after scouring and trying every solution out there)  but non one can help, you're the last hope…

    I'm getting a The ACL for object <user> is not in canonical order (Deny/Allow/Inherited) and will be ignored/

    When I try and change the permission/send-as.

    We're on Exchange 2010 sp1.

    Any suggestions/utilities?

  11. XAXE says:

    Thanks anyway Bill.  

    I, too, am confused as to how it became unsorted.

    I'll try try to kill.re-create.

  12. james says:

    I also have a single user mailbox that I am unable to modify permissions on because of a non-canonical ACL warning. I have no idea how the mailbox ACL got in that state either.

  13. Chris says:

    Is there a way to call the "clear permissions" bit through scripting (i.e. PowerShell).

    We have a recurring problem in a hosted environment and would love to automate this!

    Thank you,

  14. henk says:

    It is possible to do this with scripting? as we have at least 10.000 folders with this issue.

  15. sam says:

    How to we see this ACL table ?

    mfcmapi doesn't show the proper order of ACL's in ACL Table

    none of the windows ACL tools works or probably we don't know how to use those tools against PF

    only cmdlet we know is get-publicfolderclientpermissions,

    trying to understand how to retrieve the ACL table, in EX2013

  16. Karsten says:

    Hi Bill,

    I tried to use the exfolders tool to propagte the folderpermissions of a folder to all subfolders. The goal ist to give the subfolders the same rights as the main folder has. If the subfolder has additional userrights – they should be deleted. I tried with Tools | Custom Bulk Operation | Folders Permission | Replace. But that seemed to does not work.

    Is there way to do this with exfolders?

  17. mike says:

    I was able to get the "ACL for object is not in canonical order (Deny/Allow/Inherited) and will be ignored/" by deleting a user account, realizing it was needed, cleaning the mailbox datastore on an Exchange 2010 server, re-creating the deleted account
    and re-attaching the orphan mailbox. Unfortunately, now I can’t give myself full access permissions to the mailbox. Do I need to delete the account and try this all over again?
    Thanks for any help!

  18. Jeffrey says:

    I used to have a 2008 server that the folder ACLs were scrambled beyond repair.
    I used ntbackup and restored without permissions then easily rebuilt permissions in the Gui
    I am a big fan of transplanting ntbackup to 2008R2 and 2012 systems (it’s only two files)

  19. Bruce St.Clair says:

    I tried the trick of doing bulk but then nobody could see the public folders at all. I had exported the permission before I started and then imported them back in but to no avail. When you run the bulk is there anything special about the root permission
    I should be aware of? THank you.

  20. Mike Bedinghaus says:

    Bill, sorry to drag this kind of thing up again. I have a Public Folder That for some reason, when I apply permissions for users, that they cannot see those PF’s that I had applied permissions for, as well as a test account that I have configured for Non-PublishingEditor
    for. I have found that there is an "orphaned" account That has "Owner" permission for that folder and it’s sub-folders, so I have removed that account thinking it is screwing up the ACL. I have used EXFolders for permissions on many occassions with no issue.
    I grabbed the MAPIFOLDERS app and get a message about "Either there is no default mail client or the current mail client cannot fulfill the messaging request" on my admin server and the PF server. Outlook 2010 64-Bit is installed on my admin server that I
    use to "profile" accounts, and works quite well for that purpose. There are accounts on the PF structure that I am dealing with that have the access needed. I am thinking that for some reason, the "orphaned" account, that has "Owner" permissions is preventing
    the ACL from synchronizing the changes in permissions. I can surely provide more data about my configurations. Thanks, Mike.

  21. TheresNoTime says:

    Trying to recursivly replace Public Folder permissions but getting
    "Updating permissions…"
    "Replace permissions failed with exception: SecurityPrincipal must at least have a valid index string."

    How to fix or what could I be doing wrong?

  22. Richard says:

    We just had 2 shared Mailboxes that had this problem. They were working fine until yesterday and then the ACLs became corrupt. ExFolders showed each folder and subfolder having Default: none & Anonymous: None

    There were hundreds of sub folders. I had to manually clear permissions on each one then set the permission at Top Of Information Store then I could propagate the permission down the folder hierarchy.

    Having a recursive Fix DACL like in PFDavAdmin would be great. Please consider it.

    Any idea what makes ACLs go corrupt?

    Thanks,
    Richard

  23. Richard says:

    We just had 2 shared Mailboxes that had this problem. They were working fine until yesterday and then the ACLs became corrupt. ExFolders showed each folder and subfolder having Default: none & Anonymous: None

    There were hundreds of sub folders. I had to manually clear permissions on each one then set the permission at Top Of Information Store then I could propagate the permission down the folder hierarchy.

    Having a recursive Fix DACL like in PFDavAdmin would be great. Please consider it.

    Any idea what makes ACLs go corrupt?

    Thanks,
    Richard