joeware - never stop exploring... :)

Another one from the mailbag…

adfind -b cn=ZZZ,ou=Users,ou=AAA,ou=XXX,ou=ad,DC=YYY,DC=com dn msexchmailboxsecuritydescriptor publicDelegates publicDelegatesBL -f “(&(objectcategory=person)(objectclass=user))” -sddc++ -resolvesids >> C:\textfile.txt

what an i missing to pull permissions off a mailbox that they user has applied on the client. Say I have an account reviewer to my contacts in my mailbox

Thanks for any help

This one needed a bit of a long winded answer, here is part of what I responded with…

Unfortunately for your question you are running into the crapissions that Exchange uses and calls the Exchange permissioning system. Off the top of my head there are five separate and distinct ways in which permissions are applied in Exchange. Its been a bit since I looked at these but let me regurgitate what I recall…

First off this is Exchange 2000/2003, I haven’t played with 2007 but I expect it hasn’t changed.

The first set of permissions are applied in the configuration “partition/naming context/container” on the Exchange objects at the ORG level and below on the nTSecurityDescriptor attribute. These are worked with with any AD Permissions tool. These permissions are used for Exchange for managing the config stuff but also in the case of “Send As / Receive As” are also translated to Full Mailbox permissions on the mailboxes. I.E. If you want to give someone full mailbox control over all mailboxes in a DB, SG, Server, AG, or the Org you give them “Send As / Receive As” over that level of the objects in the configuration container and they will show up as “inherited” permissions on the mailbox itself and will be reflected in the second set of permissions – the msExchMailboxSecurityDescriptor.

The second set of permissions are in the normal domain partition or at least reflected there in the msExchMailboxSecurityDescriptor attribute. This attribute is only authoritative (and can be set) for a mailbox until the mailbox has been instantiated in the store, once that occurs, this attribute *may* reflect a copy of the permissions in the store. I have seen cases where this attribute does not properly reflect what is in the store for the mailboxes. Usually though it seems right. Anything that shows as inherited is coming from the config NC as mentioned above, anything explicit was applied directly to the user. You cannot inherit permissions to this through the domain NC OU structures. You can work with these permissions via CDOEXM with info from the following link – http://support.microsoft.com/kb/310866

The third set of permissions are maintained in the normal domain partition on the nTSecurityDescriptor. This is where you would add Send As / Receive As when you want it to work actually as Send As / Receive As instead of being a full mailbox control. These can be inherited down through the OU structure. Not sure why MSFT even did this but they did. Seemed like an unnecessary complication on a system that was already too complicated. If you have Send As you can send as the person. These are worked with with any AD Permissions tool.

The fourth set of permissions are maintained in specific attributes such as the publicDelegates. This allows you to send mail on behalf of the person. You get no permissions over the mailbox folders unless specifically granted. The GUI in Outlook can really confuse people on this. This is also very special in that there is the AD component and the Store component and they are separate and can get out of sync. This was a common problem (more common than people may realize) for folks with multi-domain forests when their outlook client connected to a GC that wasn’t a DC for the domain the user was in. One side of that permission (in the store) could be set up or removed, but not the AD side. This can cause all sorts of funky issues with your public delegates. This was the reason I fought for and eventually got the change to DSACCESS to have it try to give you a GC that is a DC for the domain your user account was in.

The fifth and important to you set of permissions aren’t really permissions so much as they are MAPI properties inside the mailbox on the folders, etc that reside there. This information is NOT in any way shape or form mapped back into AD. The only way to get that info is to contact the mailbox and enumerate the folders via CDO. Take a look at
http://support.microsoft.com/kb/295558

 

Hope this helps.

   joe