Finally, you need to use the bitmask operations that Web Table 1 and Web Table 2 (http://www.exchangeadmin.com, InstantDoc ID 38190) show to translate the hexadecimal SD property values. For example, an AccessMask value of &h30003 translates into the following AccessMask flags:
E2K_MB_FULL_MB_ACCESS
E2K_MB_SEND_AS
E2K_MB_DELETE
E2K_MB_READ_PERMISSIONS
An AceFlags value of &h2 implies the use of the CONTAINER_INHERIT_ACE flag, and an AceType value of &h0 implies the use of the ADS_ACETYPE_ACCESS_ALLOWED flag. For a glimpse into how I'm performing these operations, see "Boolean Arithmetic with Hexadecimal Values," June 1999, http://www.winscriptingsolutions.com, InstantDoc ID 5457.
PostExchange 2000 SP2
With Exchange 2000 SP2, you can update the mailbox SD in the Exchange Store by using a new property called MailboxRights, which the IExchangeMailbox CDOEXM interface exposes. CDOEXM acts as an ADSI extension, so the MailboxRights property is associated with the ADSI IADsUser interface. Listing 2, page 3, shows GetSDViaCDOEXM
.wsf, which uses CDOEXM to retrieve the Exchange 2000 SD.
Like GetSDViaADSI.wsf, GetSDViaCDOEXM.wsf starts with an ADSI bind operation to the user object. However, instead of getting the msExchMailboxSecurityDescriptor attribute value, the script gets the SD value from the MailboxRights property, as the code at callout A in Listing 2 shows. Interestingly, the SD format is still an ADSI SD. So, the script can use the same DecipherSecurityDescriptor function that GetSDViaADSI.wsf uses to display the SD values.
Unlike the ADSI technique, the CDOEXM technique updates the SD in the Store. Although updating an SD is a good idea for many reasons, a compelling reason is that doing so permits the automatic creation and updating of Exchange 2000 mailbox security. Without this automated feature, a mailbox security update is almost impossible to perform through scripts. This new feature is especially useful in multiforest environments because of the involvement of external accounts. Briefly, in a multiforest environment, the mailbox is hosted by a disabled mailbox-enabled user account in a dedicated Exchange forest called a resource forest. The real user account—the one that the user uses to log on—is in another forest, called an account forest. To grant access to the user account in the account forest on the mailbox located in the resource forest, you must add the real account as an external user account, which is simply a specific right of the Exchange mailbox. (This process assumes that you've properly established the required trusts between the forests.)
Listing 3 shows SetSDViaCDOEXM.wsf, which uses CDOEXM to update the Exchange 2000 SD. In particular, this script shows you how to add an ACE for an external account to the mailbox. This code snippet is the SD update typically used for a multiforest context. Like Listing 2, Listing 3 starts by binding to the user object and reading the SD value. Next, as in the DecipherSecurityDescriptor function, the script extracts the discretionary ACL (DACL) from the SD. Then, the script creates a new ACE to add a new setting to the extracted DACL. To add an external account to the mailbox, the script sets the various ACE properties to different values, as defined in SecurityInclude.vbs, which Web Listing 3 shows. The code at callout A in Listing 3 calls SecurityInclude.vbs into action. After initializing the new ACE, the script updates the DACL to update the SD, as the code at callout B in Listing 3 shows.
The final operation consists of transferring the updated SD back to the Store, as the code at callout C in Listing 3 shows. Note that the script passes the SD back to the MailboxRights property as an array. (This property actually requires a pointer to the ADSI SD object and not the ADSI security descriptor object itself.)
If, by any chance, the script refers to an invalid trustee, CDOEXM will return the message that Figure 2 shows when updating the SD in the Store. An aspect that Listing 3 doesn't consider is ACE ordering, which is particularly sensitive when you deny permissions on objects. ACE ordering is important in avoiding security breaches. For more information about ACE ordering, see the Microsoft article "HOWTO: Use Visual Basic and ADsSecurity.dll to Properly Order ACEs in an ACL" (http://support.microsoft.com/?kbid=269159). After the update is complete, you should see the settings that Figure 3 shows in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.
Pain-Free Scripting
Like any service pack, Exchange 2000 SP2 offers a set of corrections and new features. The new CDOEXM feature eliminates the pain of using scripts to manage Exchange 2000 mailbox security. This small enhancement hides a much more important goal: manageability of Exchange 2000 mailboxes in a multiforest architecture. Because the standard UIs aren't designed for the management of multiforest architectures, such a design requires that you develop extra code to simplify multiforest management.
End of Article
Prev. page
1
[2]
next page -->
