After migrating from IIS6 to IIS7, all sites using a WCF oData service would prompt for credentials when attempting to make Post/Put/Patch/Delete request. The user would be continually prompted for credentials until the cancelled the request. After cancelling the request, they would receive a 401.3 response from the server.
If a user is granted modify permission on the folder containing the *.svc file for the WCF oData service they are then authorized to make requests with those verbs. Asp.Net impersonation is not turned on.
The AppPool is running Integrated .Net 4 under a service account with modify permissions to the site's folders/files.
Update:
It seems this is as designed. GrantingServerName\Users modify access to the *.svc, does resolve the issue. Addendum: Specifically, it looks like Domain Users or Authenticated Users needs modify rights to the *.svc.
Final update: changed the wording to make the question more general/easy to find for others
This is by design. If you disable impersonation, then NTFS ACLs are used to secure the resource. I know it seems odd at first, but some thought will lead you to an understanding that it is a reasonable approach given the constraints of this particular configuration. This behaviour is documented on MSDN.