WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

ADSI
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

MsExchMailboxSecurityDescriptor


Question:

Anyone have an example of setting the MsExchMailboxSecurityDescriptor field?

The only reference I found is the http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/OLE~COM~ADO~CDO~ADSI~LDAP/ADSI~LDAP~CDO+Create~Mailbox~-~Exchange~2000~-~CDO~-~ADSI.txt

which in some respects doesn't seem to be accurate. On our setup you CAN set the MsExchange attributes on an account and a mailbox will automagically be created in E2K...without using CDO... the question is, is there a way this can be set properly prior to the cycle where Exchange actually creates the mailbox?

Answer:

Microsoft says that you should only use CDO to create your mailbox. Sure it's possible to do it with straight ADSI but the permissions won't be right (thus the MsExchMailboxSecurityDescriptor issue) and if something goes wrong with these users on down the line, you might not get too much support from MS. I doubt you'll be able to accurately and consistently set the MsExchMailboxSecurityDescriptor even though it is possible to change the value of that attribute.

Here is a description of the property as lifted from MSFT knowledge base article 304935. http://support.microsoft.com/default.aspx?scid=kb;en-us;304935

"The msExchMailboxSecurityDesciptor Attribute"
This attribute exists on the user object in Active Directory. It stores a partial copy of the user's mailbox security descriptor. This attribute is not back-linked to the user's mailbox security descriptor.

In other words, if you modify this attribute directly, you do not update the actual mailbox security descriptor on the user's mailbox in the Exchange information store, unless you set this attribute before the actual mailbox has been created in the information store.

In fact, if there is a conflict between the security descriptor that is reflected by the msExchMailboxSecurityDescriptor attribute on the user object in Active Directory and the security descriptor that is stored on the user's mailbox in the information store, Exchange fixes the msExchMailboxSecurityDescriptor attribute to reflect the security descriptor on the user's mailbox. If you modify the security descriptor of the user's mailbox from ADUnC or through the CDOEXM IExchangeMailbox interface, the msExchMailboxSecurityDescriptor attribute is updated automatically to reflect these changes."

In other words, you can modify the Security Descriptor in Active Directory only before the mailbox is created according to MSFT. I have never tried it so I can't say for sure. Since I have never tried it, I don't have an example but check out the ADSI extender help file. I believe there are some examples using security descriptors. You may need to examine an existing SD to determine what needs to be set.

Hope this helps, at least, a little.

User Reply:

As far as not using CDO, Everything works fine with ADSI with the exeption of the security description. There's too much extra coding and baggage (reg settings, files needed...etc) that goes along with CDO to make it appealing for what we're doing...

We are only using this to create new accounts. Since the client doesn't have a mailbox, setting the other Exchange attributes "tricks" E2k into also creating them a mailbox. My guess is that if this is set properly prior, it might also work...

What's actually happening now is what I would consider exchange stupidity. We leave this attribute blank, Exchange populates it when it creates the mailbox and for some reason only allows them into the mailbox but not the public folders... the user can't even open the root "Public Folders" (which all authenticated users should be able to read). It actually worked for quite a while but we recently switched to native mode, made a few other changes and it quit.

Answer:

Look what I found. I happened to stumble across this script fragment while searching my hard drive. I don't think it works exactly, but it is at least a start. It uses the ADSI extender but I think it can be done with WB OLE functions too.
EXCH_MODIFY_USER_ATT = 2 ; Modify User Attributes 
EXCH_MAIL_SEND_AS = 8 ; Send As
EXCH_MAIL_RECEIVE_AS = 16 ; Mailbox Owner

; Create an ace that allows the user to set properties, send and receive mail.
ace = dsCreatSecObj(sMailBoxPath, 3)
dsSetSecProp(ace, "Trustee", "mydomain\myuser")
AccessMask = EXCH_MODIFY_USER_ATT | EXCH_MAIL_SEND_AS | EXCH_MAIL_RECEIVE_AS
dsSetSecProp(ace, "AccessMask", AccessMask)
AceType = ACCESS_ALLOWED
dsSetSecProp(ace, "AceType", AceType)

; Get the descretionary ACL to hold the ACE
dacl = dsCreatSecObj(sMailBoxPath, 2)
dsSetSecProp(dacl, "AclRevision", 4)
dsSetSecProp(dacl, "AceCount", 0)

; Add the ACE to the ACL
dsAclAddAce(dacl, ace, -1)

; Create a security descriptor.
sd = dsCreatSecObj(sMailBoxPath, 1)
dsSetSecProp(sd, "owner", "mydomain\bigcheeez")
dsSetSecProp(sd, "Group", "mydomain\bigcheeez" )

; Add the ACL to the SD
dsSetSecProp(sd, "DiscretionaryAcl",dacl)

; Finally, set the security descriptor property.
dsSetProperty(sMailBoxPath, "msExchMailboxSecurityDescriptor"", sd)
Also, here is a link to a knowledge base article that covers the subject. http://support.microsoft.com/default.aspx?scid=kb;en-us;304935 A vb script example is at the bottom of the article. It seems to imply that you can change the "msExchMailboxSecurityDescriptor" after creation if you have EX2k service pack 2 or later. ???

Don't know why the descriptor behaves differently in native mode. I remember reading about it quite awhile ago but don't remember where. If I find the source I'll post a link or something.

Notice this line in the 304935 KB article:

"Any approach other than CDOEXM that is used to programmatically mailbox-enable the user object is not supported. "

I spent much time talking to Microsoft about not using CDO because I didn't want to use it either, but they were pretty adamant that you have to do it that way


Article ID:   W15818
File Created: 2014:07:18:09:43:46
Last Updated: 2014:07:18:09:43:46