I recently was working on a customer implementation of our PeopleProvision solution and I needed to create a new Exchange mailbox for new user accounts in Active Directory. Our customer uses Exchange 2007 and, after installing the Exchange Management Shell that includes PowerShell cmdlets used to create mailboxes, the system seemed ready to go. I kept running into the following error, though, when trying to create the Exchange mailbox using the PeopleProvision web application and the New-Mailbox cmdlet.
Database "my-exchange-server\First Storage Group\Mailbox Database" was not found. Please make sure you have typed it correctly.
PeopleProvision runs on the ASP.NET 4 framework on IIS, in this case IIS 7.5 on Windows Server 2008 R2. Considering the fact that I could run the exact same mailbox command via a PowerShell command shell and successfully create a new mailbox, I knew this was a permissions issue with the process identity executing PowerShell on behalf of PeopleProvision. Figuring out the exact permissions required to allow the ASP.NET web application to work, though, took some time to figure out. My solution and approach follows.
Our Solution
Note: Be aware that this approach exposes significant security vulnerabilities in the case where the application pool identity is compromised. For this particular instance, our customer is running a completely internal web application that has no public internet exposure outside the DMZ firewall. The only real security risk is from internal users who might be savvy enough to compromise an IIS 7.5 process but the security vulnerability is very low in this case. The discussion at http://forums.asp.net/t/1272317.aspx/1/10 has some very good insight into this issue and actually proposes a slick approach using Microsoft WCF or WF to minimize the exposure of a privileged account.The first thing to understand is which account is actually executing the Exchange Management Shell’s New-Mailbox cmdlet. In our case, we were using the built-in Network Service account (I prefer the application pool identity normally but we had some other issues that required Network Service) to run the application pool. After futzing around with lots of privilege elevation for the web server’s machine account (the way Windows identifies the Network Service account between two different machines), the Exchange commands still weren’t working.
Since impersonation is impossible with the Exchange 2007 cmdlets (you *can* impersonate in Exchange 2010 using remote PowerShell), the only way to change the execution context is to change the account running the PowerShell process. With an ASP.NET application on IIS 7.5, the execution context is the application pool identity. I created a dedicated service account to use to run the application pool for the web application, then added the service account to the local web server’s IIS_IUSRS group to allow it to properly run ASP.NET apps. I then added the service account to the AD domain’s Exchange Recipient Administrators group. This allows the account to create new mailbox recipients in Exchange 2007.
After a quick IIS restart, the solution allowed for creation of a new mailbox in Exchange using PowerShell running under an IIS application pool identity. In summary, be aware of your security context when working with web applications and work from the bottom up to determine how to apply the proper permissions for your application. Also make sure you restart IIS after changing app pool accounts or adding an app pool account to an AD group. Otherwise, the changes you made may not apply because of IIS and PowerShell caching.
