In my last post, I described some of the security considerations that influence an administrator’s response to event log clutter generated by DCOM errors. There are known remedial steps for most of these errors, but the impact of fixing them is often poorly understood, so I tried to clear some of that up. In this post, I’ll review how I’ve responded to the User Profile Synchronisation Service’s DCOM 10016 errors and the corollary MsiInstaller warnings with these security considerations in mind.
Failed Detection of PeopleILM Components
According to Microsoft KB article 2473430, these events occur, “while attempting to manage a User Profile Service Application”. To be more specific, the symptoms are described as:
When you attempt to manage the User Profile Service Application via Central Admin on a SharePoint Server 2010 with the User Profile Synchronization service started after an IISReset, the following warnings are logged in the application log of the SharePoint server…
Personally, I’ve never been able to pin down a firm cause of these events, so I’m happy to go with this Microsoft description, although I struggled to replicate this recently. Regardless, I’ve certainly seen the events in a large number, if not all User Profile Synchronisation Service instances I’ve encountered/built. One thing I find interesting is that these MsiInstaller warnings are accompanied by DCOM 10016 errors on the Windows Installer Service (DCOM component {000C101C-0000-0000-C000-000000000046}) and a few MsiInstaller warnings that closely resemble the Product Version Job DCOM permission errors I’ve spoken to before. This is what we’re looking at:
You’ll be able to identify that these DCOM 10016 errors come from SharePoint 2010’s embedded FIM instance because of the MsiInstaller warning messages that correlate with these errors. In the warning messages below you’ll note that each component is a part of the PeopleILM feature. ILM (Identity Lifecycle Manager) was the Forefront product that FIM (Forefront Identity Manager) grew out of. In my single server SharePoint development environment I get six MsiInstaller warnings in my application event logs to go with these two DCOM errors.
The top two DCOM 10016 errors occur because the NETWORK SERVICE account does not have permissions to Launch and Activate the Windows Installer Service, and the trigger for the errors appears to be something very similar to SharePoint’s Product Version Job. This is a set of events that call the Windows Installer Service to interrogate the install state of the FIM stuff that is the heart of the SharePoint 2010 User Profile Synchronisation Service. To that end, our response to the Product Version Job errors/warnings should help us figure out what to do with these ones.
How to Get Rid of These Events
The Microsoft KB article above suggests that the MsiInstaller warnings can be resolved by granting, “the Network Service account read access to the %programfiles%Microsoft Office Servers14.0 folder“. While this will definitely do the trick, I’m not sure it isn’t slightly overshooting the mark. There are a number of examples in the community – such as in this TechNet thread that dates back to the SharePoint 2010 Beta and this post from Benoit Hamet – where the rights have only been granted on these folders:
- %programfiles%Microsoft Office Servers14.0Service
- %programfiles%Microsoft Office Servers14.0Sql
- %programfiles%Microsoft Office Servers14.0Tools
In my testing this was sufficient as well. Whether you grant the Read/Execute access at this lower level or above (where Microsoft recommends), is a trade off between potentially tighter security and full, known support. Personally, I don’t see a huge difference in attack surface here and in either case it seems pretty clear that the rights were intended to be there originally, so I don’t really have any discomfort with these Microsoft-recommended changes.
As for the DCOM 10016 events, the KB article doesn’t speak to them. They can be cleared by granting the NETWORK SERVICE account Launch and Activation rights to DCOM component {000C101C-0000-0000-C000-000000000046} – just as I recommend for the Farm account when considering the Product Version Job’s deluge of these errors.
Once both fixes are in place, the application event logs will look like this:
Is it a Good Idea to Grant These Rights?
To stick with the Product Version Job comparison, for the Farm account, it is already highly-privileged on these servers, so there are some pretty compelling mitigations for the risks. For the NETWORK SERVICE account we’re thinking about a local account that has a very specific permission profile by default. That level of privilege is its whole raison d’être; it’s available specifically to differentiate itself from other higher-privileged accounts like Local Service and Local System, in order to reduce excess privileges. Whether granting Windows Installer Service privileges to this account is sensible will depend on how the account is used throughout the system:
- If this machine is only running the SharePoint User Profile Synchronisation Service then adding these rights might be acceptable.
- If the entire farm has been set up using NETWORK SERVICE as the farm account then we will have already granted these rights per the Product Version Job errors.
- This gets murkier if the system is otherwise quite restrictive and if it uses the NETWORK SERVICE account for other, non-SharePoint things. For instance, the SharePoint farm might be least-privileged but some other software like an agent or another technology altogether on the server might be running under NETWORK SERVICE. In those cases the decision to grant access to the Windows Installer Service should be made with some prudence, as the risks are probably more a factor of the other uses of the account than those of the SharePoint FIM instance, which is just checking version information.
- Whatever processes govern change in the SharePoint environment should be updated to include information about the greater access rights the NETWORK SERVICE will have, as it could influence how new components are deployed.
What this hopefully illustrates is that the remedial approach to one set of warnings or errors may be less suitable in another context. This should all be evaluated for each specific system, yet the depth of these discussions tends to focus purely on ticking the box. We should always be thinking about the effects of permission changes like these – especially when it comes to components that are available to the entire system and default accounts that most administrators would expect to have a level of privilege similar to the default system permissions.