Thursday, August 30, 2007

Exchange 2007 Impersonation - Debugging Protocol

We've hit on many different reasons why service account fail to have Impersonation and Send-As, Receive-As rights set correctly. Here are some areas to check as you create a service-account and grant it Impersonation rights:

  1. Create a service account (in this example: Ex2007)
    The Ex2007 account should NOT be a member of any of the Exchange Administrative Groups. Set your permissions in Default Domain Security Settings-User Rights Assignment-"Allow logon locally" for this user
    Note: Exchange explicitly denies Impersonation for all accounts in those groups
  2. All Exchange Servers should be members of Windows Authorization Access Group
  3. Determine if your users SMTP address is alias@FQDN. If it isn’t, you’ll have to impersonate using the User Principal Name (UPN). This should be defined as alias@FQDN.
  4. Set these five rights by running these commands in Exchange Management Shell

    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity Ex2007 ¦ select-object).identity -AccessRights GenericAll -InheritanceType Descendents
    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName - User (Get-User -Identity Ex2007 ¦ select-object).identity -ExtendedRight ms-Exch-EPI-Impersonation
    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName - User (Get-User -Identity Ex2007 ¦ select-object).identity -ExtendedRight ms-Exch-EPI-May-Impersonate
    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName - User (Get-User -Identity Ex2007 ¦ select-object).identity -ExtendedRights Send-As
    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName - User (Get-User -Identity Ex2007 ¦ select-object).identity -ExtendedRights Receive-As

    Note One: These grant permissions at the SERVER level. You can also grant permissions at the database, user, and contact-levels.

    Note Two: If you have multiple servers, you must grant Impersonation at each server (or database). Exchange 2007 does not have any system-wide Impersonation permission capability.
  5. If your CAS server sits behind a load-balancer, give the ms-Exch-EPI-Impersonation rights to the Ex2007 account for ALL CAS boxes behind the load-balancer. If your mailbox servers are on a machine other than the CAS servers, give ms-Exch-EPI-Impersonation rights for the Ex2007 account for ALL mailbox servers.
  6. Verify that the Ex2007 account has rights you've just granted:
    Open Active Directory Sites and Services.
    In the console tree, right-click Active Directory Sites and Services, point to View, and then click Show Services Node.
    Expand the service node (e.g. Services/MS Exchange/First Organization/Admin Group/Exchange Admin Group/Servers.
    You should see your CAS server(s) there. View “properties” for each CAS server, ensuring your service account is there, and under the privileges exchange Impersonation is checked (and not grayed out). See Figure 1.
    If the permissions or account is not present, add it, and make sure the Impersonation, and Send-As, Receive-As boxes are checked.

    Figure 1-Exchange service account impersonation properties

    (Source: http://technet2.microsoft.com/windowsserver/en/library/d4e342bc-2e26-4bd1-ba9b-b5bf58b562081033.mspx?mfr=true)
  7. Make sure you do not have accounts where permissions are not inherited (this often happens for accounts that are members of the "IT" group). If so, you’re going to need to explicitly grant permissions to members of that group or OU.)
  8. Strange things happen if you are trying to impersonate cross-forest. This suggests that the account doesn’t have sufficient rights to read AD.
  9. Verify that the service account (e.g., Ex2007) has those permissions set (Allow impersonation to Exchange Personal Information, send-as, receive-as) on the storage group and the mailbox store (see Figure 2 below.)

    Figure 2– Verify permissions at the Mailbox store
  10. If you are on a test-server and are using the default security certificate, is that certificate put in the 'trusted root'?
    Launch any secure page: e.g. for the server striper: https://striper/ews/exchange.asmx. When the certificate warning page appears, "Trust" the certificate, "View" the certificate, and use the "Install Certificate" wizard to "Place all certificates in the following store" (the store is the Trusted Root Certification Authorities). See Figure 2.


    Figure 3–Placing the Certificate in the Trusted Root Cert Authority

    Most sane human beings would try to verify all these permissions using Outlook Web Access. If you try this and get an error "You do not have permission to open this mailbox" check out KB Article 940846.
Need some Exchange Calendar applications or utilities developed for your enterprise-sized organization?  Contact us.

4 comments:

Anonymous said...

Thanks a lot Sumatra, the screenshots in the part about verifying the account settings really helped me in troubleshooting a "The server to which the application is connected cannot impersonate the requested user due to insufficient permission." error.

Anonymous said...

Hallo.
great article, but I can't resize the screenshots, so they are to small, to recognize its exactly,

regards
Rf

zyg said...

If you need the larger screen shots send zyg AT sumatra DOTCOM a message and we'll send them to you.

J Zafar said...

Hi there,

Great information. It really solved my problem for which I, along with the Dev Team member, have been trying hard. However, I should say that the size of the screens should be such that one could easily re-size them

Great work and keep it up