Featured Post

How the Sumatra Double-Booking cmdlet works

Free trial if you qualify and contact us . First: you can always get help at the PowerShell prompt with: get-help Get-suDoubleBookedMeeti...

Saturday, May 26, 2012

Exchange 2010 Permissions summary and debugging

Depending on the situation there are four permissions your service account must have to function successfully in either a migration or using Sumatra calendar tools:

1.       Impersonation
2.       Full access
3.       Read access to the GC
4.       Other details: Allow Log On Locally

In which situations are these permissions used?

This summarizes the types of permissions you must use when using Sumatra calendar technology.
Use Permission
Migrating Calendar Data into Exchange

Resource mailboxes are Disabled accounts by default, so in a full-state calendar migration they are ENABLED temporarily so that the Sumatra process can populate data correctly.
“Faster simpler” ICS calendar migration to Exchange

Using the SuHoliday cmdlet or the Sumatra Pump on users
Putting holidays into user calendars requires only impersonation
Using the SuHoliday cmdlet or Sumatra Pump on resources
Full access
Why Full access in this case?  Impersonation will not work unless you enable the accounts.  In a migration there are many reasons for doing this, but for holidays that is a wasteful extra step.  Use Full access.
Terminating an Existing User
It’s basically a migration in reverse, so you use the same permissions as a migration
Removing broken meetings from resource or user calendars
Full access
Don’t mess around in this case.  You’re trying to scrub out bad data, don’t let low permissions get in the way of a fast job.


Impersonation grants the service account permission to ‘send-as’, and ‘receive-as’ the user account.   Note, however, that impersonation works only when the account is enabled.  For disabled accounts you will need full access.
To impersonate in Exchange 2010, create a new ManagementRoleAssignment (called “_suImp8”) for your service account (called “exsu”.)

Full Access, Send-as, Receive-as

Full Access grants the service account permission to access the user account.   Full access allows you to read from and write to folders in both enabled and disabled accounts.   If you are just cancelling meetings from the conference room, full access is sufficient.  If you want to send mail on behalf of a disabled user/room, you will also have to grant send-as receive-as (see the next section)
To grant your service account (called “exsu”,)  full access for a room (“crar210q”), use the add-mailboxpermission cmdlet.
    -Identity: crar210q
    -User: exsu@cod.sumatra.local
    -AccessRights: FullAccess
    -InheritanceType: All

Note that group policies sometimes prevent permissions from being inherited.  Please use Active Directory Users and Computers (ADUC) to ensure the permissions were set!  Find the account (crar210q) and right-hand click to obtain properties.  Select the security tab, then advanced. (If the security tab is missing, select Advanced Features under View.)   You can check the permissions, or the effective permissions.  You should not see deny checked!

Add Send-as, Receive-as

If you have to add send-as receive-as, here is the commandlet
    “CR 101B”
    -user: exsu
    -AccessRights:  genericall
    -ExtendedRights: "receive as","send as",
    -InheritanceType: All      

Read access to the Global Catalog

Many enterprises grant access to the global catalog if the user is a member of the domain.  If login is failing, anonymous access is probably disabled (since Windows 2000 DCs).  Make sure you are an authenticated user.

Other Details: Allow log on locally                       

Make sure your service account is allowed to log on locally (as in the Local security policy, or if you have multiple machines, set via Group Management Policy, screen shot below.) Otherwise you will generate a 401 error.
Note that in the example above we have both a specific service account and a Group of Service accounts.  Using groups in this way is an effective means of managing several accounts if you need to segment them for Exchange data insertion.

Debugging Exchange 2010 Permissions Problems

Setting permissions correctly is one of the largest stumbling blocks in the process.    Here is a list of the HTTP errors, and ways to debug (and fix) permissions.

Most Likely Issue
Service account not allow to “log on locally”
Grant permission to “log on locally” via group or local security policy
The CAS and Mailbox servers are not members of Windows Authorization Access Group.
Add all computers as members to “Windows Authorization Access Group” in ADU&C.
BASIC authentication is not enabled for the EWS virtual directory in IIS
Set Basic authentication in IIS; remember to restart IIS
The "SERVICE ACCOUNT" is not authorized to submit requests to the CAS Server
Create a new-ManagementRoleAssignment, and grant ApplicationImpersonation rights  to the service account.  Also remember to check the service account creds to ensure they password is correct. Paste the "ews url" into a browser. Enter the service account creds, when prompted. Do you see a EWS WSDL page? (Note: this could show up as a 500 error in some instances.)
The "test user" does not exist in Exchange
is not mailbox enabled
Verify account exists in the domain, it is enabled, a mailbox user (try to access the account in OWA using the service account credentials).  If the account is disabled, did you grant “fullAccess” to the service account?
The "SERVICE ACCOUNT" cannot impersonate the "test user"
Verity there is a management_role assignment "ApplicationImpersonation" (Ex10) or ExtendedRights:"ms-Exch-EPI-Impersonation","ms-Exch-EPI-May-Impersonate" (ex07) for the SERVICE ACCOUNT that is applied to the server or the user you are attempting to test.
Start with IIS Basic authentication on the EWSvirtual directory. It’s the easiest to see / fix.

Basic debugging protocol – 401 error

Open a browser window, and try to open you EWS url.  If you typically point to the load balancer, point to one CAS server instead.  Try to open the ews url e.g., http://ex10/ews/exchange.asmx.   You should be prompted for credentials.  Enter the service account credentials.  If the credentials are rejected, your service account may not be allowed to log on locally.  If you can login, try to insert a “test” appointment using suExchange.  If you see a 401, it will be due to basic authentication not set OR the CAS/MBX server(s) are not members of windows authorization access group.

Issue: Service account not allowed to log on locally.

Here’s an easy way to confirm you cannot log on locally.  Go to the cas server you pointed to in the EWS url, and open up the Security event log.  Search for event ID 4625, keyword Audit Failure.  You’ll know you have to grant log on locally if you see your service account, with failure information “the user has not been grated the requested logon type at this machine”.   If so, allow the service account to log on locally via a group policy or local security policy.

Issue: Basic Authentication not set

Look in the IIS logs.  If you see a 401 error, check IIS.  If basic authentication is disabled, enable it. Remember to cycle IIS:  “iisreset /noforce.”

Issue: Computers are not members of Windows Authorization Access Group

If you are still getting a 401 error, ensure that ALL exchange computers and domain controllers are members of windows authorization access group.

Basic debugging protocol – 500 error

Issue: Service account does not have impersonation permissions or full access

If you are still getting a 401 error, try logging into an active end user’s mailbox via OWA (like your own!) using the service account credentials.  If you see an error in OWA:
Check the Application event logs on the CAS server for Event ID 17. If you do, then create a “New-ManagementRoleAssignment” to grant the service account ApplicationImpersonation permissions (see “Impersonation,” above.)

No comments: