You should explain in more detail what worked when running under which credentials, mostly what makes #1 tick and #4 fail.

#3 is something I expect and hope for if code running under the credentials of a remote web serveris called

At the moment my visualization points more to capabilities of a web server (correctly!) forbidden to read out local information from the user calling the site, so you are trying to find/run "local" machine code to get something blocked by security / basic machine setup, falling into the trap described in#7.

I would be very uncomfortable if an approach described in #5 - some web server (possibly in China or Soviet Union) could read out some security related items of the instance of my OS running on the machine I access the server with. In the same thought - if that is the problem - #6 is testing wrong setup.

If anybody can "call" the asp page, assuming it opens a web page hosted on/served by a remote machine, but possibly in their security zone, either that web page reads out internal info offered by the browser (which a user can block/modify/fudge in the same browser, might use another browser offering same info under other path or even security hardened browser), info of the server instance and credentials of the server process or some local info offered by "dangerous" practices allowed in Windoze.

If a user (program) reads out local info BEFORE calling the web page and passes that info in URL, all should work

local lcUser
lcUser = sys(0)
lcUser = subst(lcUser, at("'#", lcUser))
lcCall = "http://servername/testad.aspx? usr=" + m.lcUser + ";pwd=I_used_to_describe_scenarios_better"
! .....

Anything using Windoze tricks to allow the server some access under the specific Windoze policies MIGHT work (for the moment), but IMO is making yourself depend on current patch level and coding against basic system responsibilities.
Doctor, it hurts when I do this.... Then don't do this

----------------------------------------------------
1
>Here is how I do it (and I have used this approach, in ASP.NET app, before quite successfully):
>1. I created a small VFP 9 program that get the username (either GETENV() or SYS(0) and stores this user name into a text file.
>2. ASP.NET call this VFP exe using Process class. Then ASP.NET opens the text file and reads the value of the username.
>
----------------------------------
2
>>run from user machine via tiny loader, which gets username locally and calls the server with username as parameter in URL ?
----------------------------------
3
>>>>>Therefore, somehow, when the call is made from the ASP.NET page, the username is the computer name. That is, it does not work.
>>>>>
>>>>>3 hour of work wasted. But 3 hours of code that would not work, saved.
>>>>>
--------------------------------------------
4
>>>>>UPDATE: What setting (in web.config) could be affecting the above? I use Windows Authentication in web.config.
>>>>>
>>>>>>I agree that for some people some settings work. But for me, on the customer server, so far, not one worked.
>>>>>>Note that I cannot have "Run as" for my project since my ASP.NET page will be opened by anybody in the organization. And my goal is that the code of the page "knows" the username of whoever opened it.
-----------------------------------
5
>>>>>>My page runs on their web server. I created a web site MyApp and run the page as :
>>>>>>

>>>>>>http://servername/testad.aspx 
>>>>>>

>>>>>>
----------------------------------------
6
>>>>>>I may have to learn to create Console application in the VS (I have done it many years ago and of course forgot how to). And then I will test various values from a console app instead of a web app.
>>>>>>
-----------------------------------------
7
>>>>>>>- some methods depend on the context of the process trying to get the username
>>>>>>>- some people are trying to get it when they're "Run as..."ing under other credentials
>>>>>>>- some are trying from a process running on a web server
>>>>>>>- some are connecting via VPN or Remote Desktop Services
>>>>>>>