RMS Publishing Permissions for SharePoint 2010 Application Pool Identities

In the previous posts in this series about SharePoint 2010 with Rights Management, I’ve been looking at the user information requirements to successfully bridge gaps between SharePoint and RMS. In this post I will focus on a poorly documented RMS configuration requirement that is often overlooked and seems to cause many deployment headaches. This is the point of contact where SharePoint first requests RMS.

Posts in this Series

SharePoint 2010 On-Premises with AD RMS:

• Part 1 – Protecting SharePoint 2010 with Information Rights Management
• Part 2 – How SharePoint 2010 Finds and Updates a User’s Work E-mail Address
• Part 3 – How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Values
• Part 4 – Inspecting an AD RMS Request from SharePoint 2010
• Part 5 – RMS Publishing Permissions for SharePoint 2010 Application Pool Identities
• Part 6 – RMS AD Caching for SharePoint 2010 Users
• Part 7 – RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010
• Part 8 – SharePoint 2010 with AD RMS Process Diagram and Summary

Planned posts, covering newer versions and new twists:

• SharePoint 2010 with Windows Server 2012 AD RMS
• SharePoint 2013 with AD RMS
• SharePoint On-Premises with AADRM
• SharePoint Online with AD RMS
• SharePoint Online with AADRM
• SharePoint with RMS Trusts including ADFS
• Search, Rehydrated Users and RMS

 

Context

Before SharePoint can successfully request RMS protection, it must first be configured to publish documents to AD RMS. The encryption process itself should work without taking any special steps within SharePoint (this is more or less a black box), but SharePoint won’t have the rights to publish RMS-protected documents to a user until RMS explicitly allows it. Remember, when a document is saved to an RMS-protected SharePoint list it is stored without encryption in the SQL Server database, just like items in unprotected SharePoint lists. This is why Search can work with RMS-protected data. Also, remember from the last post, it is the SharePoint Web Application’s Worker Process (as the Application Pool Identity) that publishes the requested content to RMS. This post is concerned with the rights that must be granted to these SharePoint Application Pool Identities on the RMS web servers in order for the publishing process to succeed.

I only speak to this configuration step here because the documentation is a muddle and you’ll probably only ever learn of the requirement after you find that something isn’t working. Then, depending on what you find first, you’ll see recommendations to grant… some level of permission to… something… in the %systemdrive%\Inetpub\wwwroot\_wmcs\Certification folder on the RMS web server(s). You will often see something like Read & Execute rights for the Machine account + Farm account + Application Pool Identities – but like I say, it depends what you’re reading. Some examples:

• http://technet.microsoft.com/en-us/library/cc560955(v=office.12).aspx
• http://technet.microsoft.com/en-us/library/cc560968(v=office.12).aspx
• http://technet.microsoft.com/en-us/library/cc561043(v=office.12).aspx
• http://technet.microsoft.com/en-us/library/cc561091(v=office.12).aspx
• http://support.microsoft.com/kb/979511
• http://social.technet.microsoft.com/Forums/en-MY/sharepoint2010setup/thread/9a3a5438-99cd-4f89-83e2-111200ba4f3d

Whatever these specific permission requirements may be, if they have not been granted, RMS will fail to encrypt documents successfully. This has nothing to do with a user’s rights to a SharePoint document library, nor that user’s rights to decrypt RMS-protected content, but you may not notice this issue until a user requests an RMS-protected document because of the way the RMS protection process works in SharePoint. In fact, if the SharePoint farm account doesn’t have these rights, we won’t even have the option to enable RMS in SharePoint document libraries. This is (for lack of a better description) the first SharePoint/RMS integration point.

One View of the Problem

Almost all of the articles above suggests errors (5086, 5056, 5133 or others) will appear in the Application Event Logs when access is denied. This isn’t always the case, although when those errors appear, they may indicate the same root cause. The article at http://technet.microsoft.com/en-us/library/cc560955(v=office.12).aspx speaks to this with reasonable clarity (where not all of them do):

To configure the RMS server to accept requests from Windows SharePoint Services 3.0 installed in a farm

1. On the RMS server, navigate to the folder containing the ServerCertification.asmx file. This file is typically located in the %systemdrive%\Inetpub\wwwroot\_wmcs\Certification folder.
2. Add each service account assigned to an application pool for the Web application on the server that cannot access the RMS server to the ACL of the ServerCertification.asmx file, and assign it the Read & Execute permission.
   

Note: If the server farm uses multiple application pools, each application pool’s service account must be added to the RMS server ServerCertification.asmx file.

So far, so clear, but then the article suggests:

If the front-end Web server has not been configured on the RMS server, an error message appears that states that the computer running Windows SharePoint Services 3.0 could not authenticate against the RMS server. In this error message, the FQDN or NetBIOS name of the server or the service account that you must register with the RMS server will appear.

Note: if you are using multiple application pools that use different service accounts, only the service account for the SharePoint Central Administration site will appear.

This second part of the description also reads clearly, but unfortunately it is not universally true (today at least).

1. The error does not manifest itself as an authentication error, in my experience. It is an authorisation failure at ServerCertification.asmx.
2. The last bit of the note is unclear. Where will the service account for Central Administration appear? How does it get there?

Having spent a substantial amount of time searching for clear guidance about these specific requirements I’m reasonably confident it doesn’t exist. Nearly all of this content suggests a higher set of privileges than I can see a need for. Why would the SharePoint server(s)’ machine account(s) need access? Although I can see cases where those rights might be necessary (maybe with a Simple installation) I wouldn’t think they are typically applicable for SharePoint Server farms these days. However, all of this incomplete guidance at least clarifies that the missing RMS permissions need to be granted on ServerCertification.asmx. Even File Server and Exchange content talks about granting permission there. Basically, everything says you need to do something here. So… what else can we find out about these specific permission requirements?

Evidence for a Least-Privileged Model

In SharePoint 2010 on Windows Server 2008 R2 servers, with a Windows Server 2008 R2 AD RMS server, I’m seeing these patterns of events:

1. As seen in the last post, viewing an RMS-protected document as an owner confirms that the Application Pool Identity has full control (which suggests that it is the publisher).  In SharePoint 2010 and earlier, the only two accounts with RMS rights to the offline document are the Application Pool Identity and the requester.
2. The ServerCertification.asmx file is specified in many of the documents linked above and in other guidance (although the accounts that require these rights remain unclear). Additionally, we know that this file deploys with unique permissions when RMS is created. By default it is locked down to SYSTEM, which is precisely why this configuration step is required.
3. We also know that the process of requesting an RMS-protected document stops here, since the user never gets prompted to log on to RMS. The user does get prompted to log on to SharePoint from the Office client, but that is effectively the initiation of the process and should not be confused with the logon prompt from RMS that occurs after the encrypted document is opened (see my last post for more detail).
4. In the Windows Security event logs on the RMS Server, we will always find event 4624 when a user requests RMS-protected content. This event provides reasonably strong evidence that the Application Pool Identity for the w3wp.exe is signing on to RMS from the SharePoint server. This only demonstrates authentication and does not log what resource is accessed, but these events clearly correlate with a user’s request for RMS-protected content.
5. In my environments, if I request RMS-protected content with a valid, authorised user from a SharePoint Web Application whose Application Pool Identity does not have Read & Execute permissions on ServerCertification.asmx, the user gets a “Could not open <document>” message and I see a very revealing Informational event (1314) in the  Application event logs on the RMS server (screenshots below). This event clearly establishes that the Application Pool Identity is denied access to ServerCertification.asmx when it tries to sign on from the SharePoint server and is tightly correlated with the 4624 Security events we see in point #4 above. I interpret this to mean that the account signs on successfully (4624), but doesn’t have permission to access this file (1314).

Could not open <document>

Informational Event 1314

The message in event 1314 reveals a few things.

• The Event message is “File authorization failed for the request”. This couldn’t be more clear.
• The “Request Information” spells out the ServerCertification.asmx path.
• The “User host address” is the SharePoint server.
• The requesting user (“Thread account name”) is SP2010\RMSBadAppPool (the Application Pool Identity that doesn’t have rights to ServerCertification.asmx), again, correlating with the 4624 logon events described above.

All of this leads me to believe that the only rights required are Read & Execute for each SharePoint Application Pool Identity that will initiate requests to RMS.

Note: this view of things oversimplifies what permissions the ServerCertification.asmx file should have in any given infrastructure. Most organisations with RMS will often have introduced it for the File Server role’s File Classification Infrastructure or Exchange before SharePoint, and those scenarios suggest similar permission requirements here, although interestingly, the guidance for how those servers should be granted access has a similar lack of uniformity.

Assumed Permissions and Permission Inheritance

If my assumptions about these permission requirements are correct, and the Application Pool Identities are in the Domain Users group, we may be able to simplify operations by re-inheriting permissions from the parent “Certification” directory rather than granting explicit permissions on ServerCertification.asmx. This approach should provide the permissions necessary for SharePoint, for instance when new Web Applications are created in isolated Application Pools. This effectively applies the same permissions to ServerCertification.asmx as to the other files in this directory (save MobileDeviceCertification.asmx and MacCertification.asmx which I will revisit later). Indeed, this permission inheritance approach is precisely what some RMS configuration articles suggest. Whether this is a good idea is an open question that should be answered by any given organisation’s approach to hardening (which I will also revisit later). For now I will inspect whether a lesser set of privileges is possible and then revisit the comparative advantages versus establishing inheritance.

What permissions are applied when inheritance is established?

If we change the permissions on ServerCertification.asmx to inherit from the Certification directory, these permissions will be granted by default:

• SYSTEM = Full Control
• Local Administrators = Full Control
• Local AD RMS Service Group = Read & Execute
• Local Users = Read & Execute

First of all, I’m not going to consider changes to SYSTEM and Local Administrator Full Control rights on this file. I don’t think this will be controversial.

However, the AD RMS Service Group is very important. Without granting access to this group (which contains the AD RMS Service account), the same 1314 Information events will appear and SharePoint will not be able to protect content with RMS. In fact, SharePoint won’t even get past the RMS configuration page in Central Administration. Failing to grant these permissions is the RMS equivalent of removing WSS_* permissions on the SharePoint file system. It won’t work.

With this in mind, we should take these permission requirements as a baseline for any workload (not just SharePoint):

• SYSTEM = Full Control
• Local Administrators = Full Control
• AD RMS Service Group = Read & Execute

The final account that gets added when inheriting permission from the ServerCertification.asmx parent, is Local Users. By default, Local Users will have Domain Users included as members, so in effect, this will grant all Domain Users access to ServerCertification.asmx. Of course, in many environments Local Users has a more restrictive membership, especially on servers.

Rather than accepting the membership we’re given, we could selectively grant access to Local Users, but typically that will be a broader consideration than something as specific as rights to one file. I wouldn’t advise distorting membership of Local Users for these requirements, although in some cases these permissions may be sufficient (and probably overly so). In short, this approach may grant the required rights but it’s likely to open things up excessively.

This leaves one open question. What “User” Read & Execute rights should be granted to this file for SharePoint, if we decide not to establish inheritance with the Certification directory? Because I can see no evidence that the Server accounts are actually required in my configuration (NETWORK SERVICE is not used as an Application Pool Identity), I attempted to configure RMS without these rights.

Farm Account Permission

When RMS only has the baseline rights described above, the Information Rights Management page in Central Administration will display a big red exclamation that RMS won’t allow our server to communicate with it.

This message is clear about the problem, but very misleading about the condition that causes it. In this case, SharePoint is able to communicate with the server that it finds in the Active Directory Service Connection Point for RMS (or a specific RMS server), but RMS refuses to grant SharePoint access. This is all accurate, but the machine account that’s cited in the remainder of the message is a red herring as far as I can tell. The first clue is a 1314 Information event for the Farm account.

When I grant the farm account access, the red error goes away. If I roll my machines back to a point where that access has never been granted, and instead grant access to the machine account, nothing changes. I still get the same misleading message. All available evidence suggests that:

1. SharePoint needs the farm account to have access in order to “activate” IRM in SharePoint. It also validates the availability of the service to SharePoint.
2. Granting the machine account access to ServerCertification.asmx does nothing to help this part of the process along (unless Central Admin is running as NETWORK SERVICE, I assume).

In short, the “Domain account name used” appears to be a fiction. All available evidence suggests the farm account is the first, necessary requirement. In fact, until the farm account can successfully communicate with the RMS infrastructure, we won’t have the option to enable IRM on SharePoint document libraries; the option will not appear in List Settings until this is working. With all of this considered, I’m comfortable assuming the Farm account needs to have Read & Execute permission on ServerCertification.asmx.

Other Application Pool Identities

Based on these first tests, we can be reasonably sure that granting the machine account access to ServerCertification.asmx has no effect on establishing communication between SharePoint and RMS (unless SharePoint runs as NETWORK SERVICE). To this end, my next step was to test accessing an RMS-protected document library with these basic permissions in place, to ensure that the Farm account alone is insufficient. Indeed, requests for RMS-protected content in this configuration generate the same “Could not open <document>” message and event 1314 as in point #4 in my evidence above.

The obvious next step is to grant our first Worker Process Application Pool Identity Read & Execute rights to ServerCertification.asmx. This works, and I believe it confirms the least-privileged approach. I’ve repeated the process with multiple Worker Processes with distinct identities. In each case the “Could not open” messages and the 1314 events disappear as soon as the rights are granted to the Application Pool Identity that’s publishing to RMS, and RMS starts to move through the rest of the protection process. In my testing an IISRESET is not required at SharePoint nor RMS when changing these permissions. The same thing happens when adding the Farm account in the preceding step. In short, this seems to be how it works.

To make the test double-blind, I reverted to a snapshot taken before making this change, and I granted the machine account Read & Execute rights to ServerCertification.asmx. This had no effect. The “Could not open” messages persisted and the 1314 events were logged until I granted the Worker Process Application Pool Identity Read & Execute access to ServerCertification.asmx, which then solves the problem exactly as above. The machine account rights appear to do nothing unless a Worker Process runs as NETWORK SERVICE.

Assuming I’ve not got anything wrong here, and there isn’t anything peculiar about my environments, the least privileges required to ServerCertification.asmx are:

• SYSTEM = Full Control
• Local Administrators = Full Control
• AD RMS Service Group = Read & Execute
• SharePoint Farm account = Read & Execute
• Application Pool Identities for Web Applications with IRM enabled content = Read & Execute

…noting that the Farm account and the Application Pool Identities could in fact all be NETWORK SERVICE, in which case one would grant Read & Execute permissions to the machine account.

Simplifying the Approach

It may be desirable to create a Local Group on RMS servers called “WSS_WPG” or “SharePoint Application Pool Identities” in order to simplify administration in complex environments. In this scenario, the Application Pool Identities would become members of this group, and the group would have Read & Execute rights on ServerCertification.asmx. This is purely an operational consideration which has no effect on the actual permissions granted.

MobileDeviceCertification.asmx and MacCertification.asmx

Earlier in this post I mentioned that two other files in the Certification directory ship with incomplete permissions. While I don’t intend to cover the breadth of mobile device and Mac access requirements for RMS, I would suggest thinking about these configuration requirements while considering the ServerCertification.asmx requirements. This is unrelated to SharePoint configuration requirements per se, and does not pertain to the publishing process, but I mention it here since these files are also locked down by default. Unfortunately this is also not terribly well documented, but this link and this link may prove helpful as a start.

Why Harden ServerCertification.asmx?

Lastly, I have to ask why we would want to restrict RMS publishing permissions to a limited set of accounts. Specifically, I am pondering the benefits of declaring low privileges on ServerCertification.asmx rather than establishing inheritance from the Certification directory. The fact that the product ships without these privileges is a strong clue that the RMS team thought it was a good idea to force us to think about restricting these rights. Some documentation says so explicitly.

But to play Devil’s Advocate for a moment, would allowing wider access be so bad? Surely it depends on the scenario. If the Active Directory teams aren’t massively concerned with the strictness of their server file system permissions, it may not be worth fretting about this too much – but in my experience this is rarely the case. To align this thought with other work we might carry out, I would struggle to recommend opening this up widely if we are otherwise undertaking to harden the environment with the Security Configuration Wizard and other tools. Along those lines, I might also reconsider who should be a Local User of my RMS infrastructure, which has the effect of reducing permissions on ServerCertification.asmx if permission inheritance is established , although as I mention above, I would struggle to recommend making changes to Local User group membership on the basis of SharePoint Application Pool Identity access requirements alone. However, it may be sensible to assemble those wider requirements with these least-privileged permissions in mind.

In terms of the machine accounts, I think it’s good to disclude them if they don’t require this access. Operationally, it means that machine accounts don’t need to be granted and revoked access as topologies and farms change. From a security perspective, it presents less risk to the RMS infrastructure should a server be compromised. Since we can assume RMS-protected content is probably sensitive (otherwise, why bother with it???), it’s worth discluding these accounts where they don’t strictly need this access. Also keep in mind, these web services might be published outside the firewall. And remember that networks are getting compromised left and right these days. If we’re even thinking about RMS protections, surely it makes sense to be judicious with access to the RMS web services.