Beware of IIS authentication settings when deploying SharePoint 2013

Recently I worked on an interesting case during one that was blocking deployment of one of the SharePoint 2013 projects I was working for.
Basically what happened was that although deployment of SharePoint went well, some of the Service Applications like Managed Metadata, User Profile Service, Business Connectivity Services, and Search did not work properly. The symptoms varies, but a common error message in the ULS logs stated:

02/27/2013 09:58:52.07 w3wp.exe (0x1910) 0x2428 SharePoint Server Taxonomy ca42 Medium Exception returned from back end service. System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
AccessDeniedEx:The current user has insufficient permissions to perform this operation. (FaultDetail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: AccessDenied Ex:The current user has insufficient permissions to perform this operation. at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication.GetServiceSettings(GuidrawPartitionId) at SyncInvokeGetServiceSettings(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.In... 5510ed21-c1ef- 4b6f-8305-33afc4200a76

Also after doing some WCF tracing I found that there was an interesting claim in the SAML token (as part of Service Application authentication; Remember... Everything in the Service app world is claims):
<saml:Attribute AttributeName="isauthenticated" AttributeNamespace="https://sharepoint.microsoft.com/claims/2009/08" a:OriginalIssuer="SecurityTokenService" xmlns:a="https://schemas.xmlsoap.org/ws/2009/09/identity/claims">
<saml:AttributeValue>False</saml:AttributeValue>

Clearly there is something fishy going on here J.

After working on this for most part of a week, even with help of my colleagues at Premier Support, we were not able to nail this one down. Fortunately someone at the customer remembered running into similar issues with a SharePoint 2010 project they did years back.
The solution for that problem was to set the advanced Anonymous Authentication settings of the IIS root node to IUSR:

https://technet.microsoft.com/en-us/library/cc770966(v=WS.10).aspx

Using a default Windows deployment will not require you to do this, but this customer in particular followed a "customize if possible" strategy for their Windows build images, and changing this setting (among many others) to a non-default setting of "Application Pool identity".

I have tried to find out why this breaks SharePoint functionality so severely, but was unable to. (If you know, please post to the comments!).

Fortunately we were able to move forward with the project. I hope I can help at least one of you peeps out there, by posting this!