Exchange user mailbox permissions issues

An IT infrastructure so organic, sometimes I feel like this guy.
An IT infrastructure so organic, sometimes I feel like this guy.

I work for a company who’s network and server environment represent a fairly common scenario in the corporate IT world. They had moved to Active Directory and Exchange about a decade ago and continued to upgrade and grow based off of a general configuration or structure that had been established when those services (AD, Exchange, etc.) were first set up.

Over time, various administrators made changes to these systems to accommodate new services, programs, and initiatives. These changes, being completely necessary and reasonable caused the IT infrastructure to grow and change in a somewhat organic fashion. When I use the word organic in this case, I mean it in the sense that servers and the network were configured around the changing needs of the company, bit by bit. Consequently, I occasionally run into quirks or issues like the one I’ll be discussing below. I like to think these quirks give the infrastructure character. It keeps me on my toes.

I was changing an Exchange user’s mailbox properties the other day to remove a quota that had been set. When I clicked the OK button to apply the new settings to the mailbox, I received the following error:

ExchangePermissionsErrorThe error message is as follows:

“Error: Active Directory operation failed on emailserver.organization.com. This error is not retriable. Additional information: insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
The user has insufficient access rights. “
 

After some moderate googling, I came across some blog and support forum posts by others who had encountered this error. The general consensus was to check the user’s AD security settings to ensure that the “Exchange Enterprise Servers” group had appropriate permissions. Permissions could be fixed by ensuring that inheritance was applied to the user.

ExchangePermissionsError1

I confirmed that the user object had inheritance enabled but I was still unable to apply the changes to the mailbox. I had gone back to skimming the blogs again when I noticed a suggestion in a post to check the inheritance settings for the OU that the user account was in. It turns out that the OU’s inheritance setting had been disabled.

ExchangePermissionsError2

The story goes as follows:

At some point before we had upgraded to Exchange 2010, we had delegated some permissions for the Help Desk so that they could reset user’s passwords. There were some users, people in Accounting, HR, and Executives who’s passwords we felt the Help Desk should not be able to reset. The delegated permissions had been set on an OU that the user’s department OUs were sub-OUs of. In the above example, the North America OU would be where the delegated permissions for the Help Desk had been set. The sub-OU’s (Executives, Marketing, IT, Etc.) would inherit those permissions unless inheritance was disabled in their security settings.

In the end, I concluded that disabling inheritance to the affected user’s OU, prevented the application of new permissions to that user’s account that would have been set when we updated to Exchange 2010. To resolve the issue, I had to go ahead and re-enable inheritance on the department OU of the user who’s mailbox quota I couldn’t change. This caused the necessary permissions which had changed or been added with the upgrade to Exchange 2010, to be applied to the user’s account.

I still wanted to prevent the Help Desk from being able to reset the user’s passwords, so I disabled inheritance on the OU in question and manually removed the permissions that I didn’t want applied to the users. I think that the delegation of rights to the Help Desk maybe should have been applied differently but that’s the moral of this story: The reality of IT is that very rarely if ever,  is any configuration ideal for all uses and situations. Tread carefully, it’s a jungle out there.

Further reading:
Technet 
Advertisements

Office 2010 GPO Nincompoopery

Whilst configuring group policy for Office 2010, I came across an interesting bug. The “Options” option in the file menu of all Office programs will be grayed out if you set the following policy to “Enabled” and place a checkmark next to “Office Center”:

 User Configuration\Policies\Administrative Templates\Microsoft Office 2010\Disable Items in User Interface\Disable commands under File tab | Help

 Group Policy for Office 2010 causes Options in the file menu to be grayed out.

Looking for an AD account that is associated with an email address?

From time to time I find myself looking for an account that is associated with a specific email address. If the email address in question is an alias, a simple search in Exchange won’t turn up any results. Running a query in Active Directory Users and Computers can locate the information easily.

To run this query, take the following steps:

  1. Open the Active Directory Users and Computers mmc.
  2. Right-click on the domain and select the “Find” option.
  3. Select the “Custom Search” option from the “Find:” drop down menu.
  4. Click on the “Advanced” tab.
  5. In the field under “Enter LDAP query:” type the following: “(proxyAddresses=smtp:example@example.com)”.
  6. Hit the “Find Now” button and prepare for win.
I really have to find better examples to support my instructions.

Further Reading: