There are two things that come into play here:
1. Kerberos. By default, you're not able to perform double-hop using Kerberos. So, if you have setup Ansible using kinit and the kerberos changes that are in a PR, you're basically connecting from the control node to the managed windows node using Kerberos. You will not be able to use those same credentials to authenticate against a file server to pick up a file (this would be double-hop). There are ways around this: You can set the managed node to be trusted for delegation (which is set on the computer object in AD).
2. The actual Windows Account you've setup Ansible with: If this is a local account, that account only has the local windows computer (managed node) as its realm, and is not able to authenticate against a file server.
If you're using a domain account but not Kerberos in Ansible, and that account actually has access to the file, then it should work (given that win_Get_url actually supports file servers, I'm as confused as Michael on that).
What we need to build, is a module for copying files and folders from file servers onto the managed node, and have that module take arguments for forming a credential (these could be stored as encrypted variables in Ansible).
My "upcoming" win_package has support for file servers, I just haven't "activated" the credentials support yet. Maybe I should do that before I PR it.
I hope that sheds some light on it. I'll do some testing on this on my own and report back.
I wouldnt start mucking with the WinRM group. Administrators already have the required winrm access, and most of what you would do thru Ansible requires Administrative access anyways, since we're deploying/configuring/installing stuff on the systems. The user Ansible uses to connect to the managed windows node needs to be member of the "Administrators" local group on the target computer (either directly or indirectly), its as simple as that.
-Trond