You said, when you used "it", was it a ASP.NET web application? Are you sure that your ASP.NET app could get the user login ID (username currently logged in the PC)? I have tried all possible scenarios and so far no good.

My other answers below your questions.

>It still surprises me it's this difficult. When I used it years ago it "just worked". I didn't need to determine or store the user's AD account but I'm pretty sure I tested it with accounts which were and were not allowed to access the app, and the app allowed or denied access appropriately. So the app clearly "knew" who was logging in.
>
>A few random things to check:
>
>1. Did you test the scenarios in the link the other day which should return "DomainName\UserName"?

The DomainName\UserName returned is ALWAYS the Identity under which the page runs. That is, it is either IUSER or whatever username you impersonate. For example, if you impersonate your username, then the ASP.NET page shows your username no matter who is logged into the PC when opening the page. I tested it myself and with the customer project manager.

>2. Has IT made any changes to IIS's permissions e.g. is it able to query AD? Are IIS permissions at the default?

The thing is that ASP.NET CAN indeed query the AD. That is, if I manually enter any username of the company AD, I can connect to AD get all the information from AD; displayname, email, SID, employeeID, etc. So connecting and extracting the data from AD is not a problem. It is KNOWING how is currently logged into the PC is the problem.

>3. Have you checked 1,000% that all settings in IIS and your ASP.NET app to support WAuth are correct?
>

The above question is not clear. But believe me I checked many settings. And all works; except the ASP.NET page not seeing the username (again, who is currently logged into the PC)

>4. Have you tested your app using IE? I'm wondering if newer browsers are "private by default" or you might be browsing in private/incognito mode which might have an impact on what's provided to your app. Are there any browser extensions or AV which might be interfering?
>

I am user Chrome and IE on my computer and IE on the customer computer.

And I don't think the browser makes a difference. The reason is that, if you remember, when I called a small VFP 9 program I get the same "wrong" username. The reason is that when I call VFP 9 program I use the Process class of the .NET. Which, I believe, runs in the same workspace as the page.

I am going to search a way to call the VFP 9 EXE not from the Process class but like RUN does in VFP. That way, maybe, the VFP EXE will get the "real" user name (which it does when runs stand alone).

Thank you.


>>The IT guy made this domain account (he created for me) an admin on the server (to which I connect from SecureLink). And IT guy said he can even log into the server with this "test" account. I simply don't know what to ask him any more.
>>
>>But I did another test last night, after I posted this message. I connected to the VM of another customer who has a very similar environment. And I have an old account and a password that this other customer granted me a while back. This is also a Domain account. I was able to impersonate it without any problem.
>>
>>But the result, after impersonation, is that the User ID (or UserName) that my page sees is NOT the AD username of whoever logged into PC. But simply the account name (username) impersonated in the ASP.NET application.
>>
>>My conclusion for now is that it is impossible for an ASP.NET application to "get" (to obtain) the AD username of a person who is logged into PC. But the ASP.NET application can only get the username which it (this application) identifies. Either default username IUSER or the username impersonated.
>>
>>I will tell the customer tomorrow that want they want cannot be done.
>>
>>Thank you very much!
>>
>>
>>>I don't know the configuration details of your test environment, but it might be that the domain account you're using may not be allowed to log on to the server computer (non-admins can't, by default). If you're trying to start and run a process on the server computer as an unprivileged user, that could explain what you're seeing.
>>>
>>>If you can RDP into a workstation on that same network, and put some debug code in your ASP.NET app you could hit your app from the workstation and see what happens.
>>>
>>>>Some of you may have seen a couple of threads I created where I am trying to make my ASP.NET page to read the domain username who is currently logged into PC. It does not work by default.
>>>>
>>>>So, I asked the customer IT guy to create a domain account and give me credentials so that I can impersonate this account and make my ASP.NET page run with the credentials of this account. The IT guy did that and I set up impersonation (in web.config file). He created account TestAcct. I impersonate that account as DomainName\TestAcct and entered password. But then when I run the page, I get an error:
>>>>

>>>>Could not created Windows user token for the credentials specified in the configuration file.  
>>>>The referenced account is currently locked out and may not be logged on to
>>>>

>>>>
>>>>Then I tried to set up impersonation for a couple of other valid domain usernames/accounts that this organization has. And the same error message. So, I am doubtful the the account is really locked.
>>>>
>>>>Any ideas of where I should look for? Or tell the IT guy to look for?
>>>>
>>>>TIA for any input.