SharePoint 2013: Built-in accounts are used as application pool or service identities

Problem

You find the following entry in the SharePoint 2013 Central Administration, Review problems and solutions, All Reports listing:

Title	Built-in accounts are used as application pool or service identities.
Severity	2 - Warning
Category	Configuration
Explanation	Using built-in accounts like Network Service or Local System as application pool or as service identities is not supported in a farm configuration.  The following services are currently running as built-in identities on one or more servers: c2wts(Windows Service)
Remedy	Browse to  .../_admin/FarmCredentialManagement.aspx and change the account used for the services listed in the explanation. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=142699".
Failing Servers
Failing Services	SPTimerService (SPTimerV4)
Rule Settings	View

  
Solution

1. Determine the SharePoint service account that you want to use as the identity for the Claims to Windows Token Service.
1. This service account should be a domain account with standard user privileges. 

   For my environments, I generally use the services account (eg, spService) as the identity for C2WTS.

2. If your environment is locked down, ensure that the network GPO is modified to grant the service account the Impersonate a client after authentication and Log on as a service local user rights assignments.
3. Using the SharePoint Setup/Administrator account (eg, spadmin), launch Central Administration, and then navigate to Security > Configure service accounts.
4. From the upper dropdown, select Windows Service - Claims to Windows Token Service.
5. From the lower dropdown, select the desired service account.
6. Click OK.
7. Check the Events log on the server on which the service is started to ensure that this account re-assignment did not generate any errors.

References

1. Claims to Windows Token Service (c2WTS)
2. c2wts - Windows Service account SharePoint Server 2010
3. Built-in accounts are used as application pool or service identities (SharePoint Foundation 2010)
4. How to configure the Claims to Windows Token Service (C2WTS) for SharePoint 2013
5. Local Policy Settings
6. SharePoint 2013: Service Account Configurations and Permissions

Notes

• Remarkably, the SharePoint 2013 Health Analyzer rules reference does not include an entry for this issue, though the 2010 rules reference does.  A link to the appropriate rule reference for this issue is provided in the References section.
• Reference 4 indicates that the C2WTS service account should have the Act as part of the operating system user right assignment in local policy.  However, in its Local Policy Settings reference, Microsoft states that,

  This user right is extremely powerful; anyone with this right can take complete control of the computer and erase virtually any evidence of their activities.
  
  Limit the Act as part of the operating system user right to as few accounts as possible—it should not even be assigned to the Administrators group under normal circumstances. When a service requires this user right, configure the service to log on by using the local System account, which has this user right inherently. Do not create a separate account and assign this user right to it.
  
  This user right is rarely needed by any accounts other than the local System account.

  Thus, it's not clear to me that the C2WTS service account actually requires this user right assignment.  The other two rights assignments, Impersonate a client after authentication and Log on as a service, are common assignments made to service accounts by the SharePoint Products Configuration Wizard, and thus I have no difficulty with these.  More conclusively, I have set a domain account to run C2WTS that does not have the Act as part of the operating system user right assignment, and the service ran just fine without generating any events on the server.