Exchange 2003 and disabled user accounts

  • Article

As some of you may be aware, the behavior when dealing with disabled user accounts has changed.  Prior to these changes, when you disabled a user account, any mail sent to that account would NDR, and accessing the mailbox was not possible.  In addition, you would see many 9548 warnings logged in the Application log for each mailbox-enabled user that had been disabed.  The text of the 9548 message would look like this:

Event ID : 9548
Raw Event ID : 9548
Category : General
Source : MSExchangeIS
Type : Warning
Generated : <date>
Written : <date>
Machine : SERVERNAME
Message : Disabled user /o=<Organization>/ou=<Administrative Group>/cn=Recipients/cn=UserName does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.

Each mailbox-enabled user account has an attribute called msExchMasterAccountSID.  This is important, because when Exchange receives an e-mail message for a recipient, the Simple Mail Transfer Protocol (SMTP) address is translated to a SID. Active Directory searches for an object that has an entry in the proxyAddresses attribute that matches the SMTP address. When an entry is found, Exchange tries to determine the active SID for the user account. If the user account is disabled and if the msExchMasterAccountSid attribute is not set, Exchange cannot determine an active SID. Exchange then logs a warning event 9548, and the message is returned as undeliverable.  In the past, tools such as NoMAS (written by Alex Seigler) could be used to correct this issue, as it would bulk search for accounts with incorrect settings (such as disabled accounts with msExchMasterAccountSID not set), and would then fix them.  This could also be fixed manually by either re-adding the SELF account on the mailbox permissions, or by adding another account, and specifying it was the "Associated External Account".

This behavior was changed in Exchange 2003 via a hotfix.  In Exchange 2003 SP2, builds of store.exe 6.5.7651.14 and greater incorporate the change, and with Sp1, builds of store.exe 6.5.7234.3 and greater incorporate this change.  The corresponding KB articles are 916783 (2003 SP2) and 903158 (2003 SP1).  The new behavior of Exchange is that if the SELF SID is missing from the Mailbox permissions, store.exe checks to see if the msExchMasterAccountSID is populated (this is the same as before).  If it is not populated, then store.exe will use the objectSID of the user account, which should always be present.

What does this mean for you?  Well, for one thing, it means that you should no longer see 9548 messages logged.  Since Exchange now goes on to use the objectSID if no msExchMasterAccountSID is detected for a disabled account, this also means that unless you take additional action, disabled accounts will now continue to receive e-mail.  For some companies, this is good.  Others may not like it as much.  If you happen to fall into the second camp, below you will find a few workarounds that will allow disabled accounts to once again generate NDRs, though it won't be the exact same NDR message as before.

To force a disabled account to stop receiving emails and instead, generate a Non-Delivery Receipt (NDR)to the sender, take the following actions:

Option 1:

Set Delivery Restrictions to only allow certain users to send messages to the disabled account.

  1. Open Active Directory Users and Computers and navigate to the disabled account object. 
  2. Right click on the account object and select Properties. 
  3. Click on the Exchange General tab and then click on the Delivery Restrictions button. 
  4. On the Delivery Restrictions property window, select "Only From" under "Message Restrictions" and do either of the following:
    • Add the user account itself to this list.
    • Create a dummy account that no one will use and add it to the list.
  5. Wait for AD Replication or Force AD Replication. Test sending mail to disbled user, you should get NDR as expected.

Logic here: Messages will be received on this account "ONLY FROM" the dummy account/the user itself.  Everyone else will receive an NDR as expected, though the actual NDR that is generated will be one for delivery restrictions (i.e. you don't have access to send to this person).

Option 2:

If Receiving message Size (Max) is set to Zero (0 KB), the sending user will get an NDR (Though the reason of NDR would be different).

To modify this option, go to the following location:
AD User properties=>Exchange General=> Delivery Restrictions=>Receiving Message Size=>Maximum KB = 0

Note: Options 1 and 2 should be able to be set in bulk by using either an import file (LDIFDE), or by using a tool such as ADModify, but they would need to be run each time another account is disabled.

Option 3:

If you set the size limit of mailbox as 0KB, you will receive an NDR (Though reason of NDR would be different)

To modify this option, go to AD User Properties=>Exchange General=> Storage limits=> Prohibit send and receive at (KB): 0

Note: Option 3 can be implemented using an Exchange System Policy. Simply create a new System Policy, define the Send/Receive limits, and then apply that System Policy to a Mailbox Store. Once the account is disabled, you would simply move the mailbox to the Mailbox Store managed by the policy, and the Send/Receive limit will automatically be enforced.

If a System Policy is used, it may also be desirable to not send warning messages to those mailboxes. This can be accomplished using the same policy, and setting the warning message interval to custom, and deselecting all time periods.

Option 4:

Remove the SMTP addresses from the disabled account.  This will result in an NDR being generated as the destination address will not exist.

Note: The Primary SMTP Address for a user account *cannot* be removed by using Active Directory Users and Computers. The interface will not allow it to be removed. If you choose this option, you would have to use another editing tool, such as ADSIEdit (available in the Windows Support Tools), or perhaps something such as ADMofity.

While none of these workarounds provide the same exact functionality the existed prior to this change, they are nonetheless valid workarounds.  The third option appears to be the easiest to implement in my opinion, but in today's world, it is all about choice.