All that you say makes sense.
I do set the web site to run in the Windows authenticated mode. The web server is in the domain. But it could be that the default account under which the web page runs does not have the authority to get the username.
So, I asked the customer IT - maybe they will reply on Monday, maybe not :) - to set up an account with the elevated privileges. Then I can impersonate this account in the web app and see if it works.

If it does not work, I decided that I will offer the customer the approach where the user will be prompted - when he/she loads the main page of the app - to enter his/her username; without password. Then, once my app has the username, I can get all other info about the user (name, email, employee ID) from the AD. I already tested and I know how to do it.

>This is a context issue. If you're running your code in ASP.NET on a web server, the result you get will be the web server's context. The web server usually runs as a service, so its "logon" account (i.e. context) will typically be a local (to the server) service account, such as the "NT AUTHORITY\NETWORK SERVICE" result you're seeing.
>
>I don't know much about IIS but I believe it spawns separate "worker processes" (w3wp) to run code. I suspect those worker processes are also running under some kind of service account.
>
>If you run a VFP process (or C#, or anything else) from within your web server, that process's context will be a service account, either for the web server itself or one of its worker processes. So the results you're seeing, while frustrating, are exactly as expected.
>
>A web server serves up content to a client browser, which may be running on almost anything e.g. MacOS, Linux, Windows etc. Using IIS as an example web server, it runs in its own "world" (context) on the server box or VM. It has no insight into the user's account name on his Mac or Linux machine. The only way it could would be if the Mac or Linux machine explicitly gave that information to IIS, which they never would for security purposes. So IIS has no way of knowing who's accessing the page (i.e. "anonymous" access).
>
>One exception which may apply in your case is what used to be called an ASP.NET application using Windows Authentication. I don't know if the terminology has changed or been replaced with something else. I remember using it for the one ASP.NET 1.1 app I wrote many years ago but just to authenticate users (i.e. let them in if they belonged to the proper AD security group), I don't recall needing to record the user's logon name from within the app itself.
>
>An overview of how things used to work is at https://support.microsoft.com/en-ca/help/323176/how-to-implement-windows-authentication-and-authorization-in-asp-net . Basically, the web server needs to be IIS in an AD environment, your ASP.NET app needs to have Windows Authentication configured, and the user needs to be logged on to an AD domain account on the same domain as the IIS server. It seems that under those conditions the user's web browser somehow provides enough AD account information to IIS for it to authenticate the user and "know who it is".
>
>Once all those pieces are in place you should be able to get user info directly i.e. https://richhewlett.com/2011/02/15/getting-a-users-username-in-asp-net/ .
>
>Again, all this is old information and may have been replaced by newer MS tech.
>
>>I get the same result that you get when I use System.Security.Principal...
>>I see - on my computer - my ComputerName/username.
>>But,
>>this value - on the customer server - returns NT AUTHORITY\NETWORK SERVICE
>>
>>I think one of the reasons is that neither you no I have our PCs on AD; and the customer server does.
>>And their could be another setting that effects it. I tried many, many and so far the same result.