>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.

No, my app didn't need to get the AD account name, it just needed to ensure the user was authorized i.e. a member of an AD security group which had been granted appropriate permissions.

>>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.

If that's true then WAuth isn't working, or the request context isn't what you think it is. If WAuth is working it should pass in the context of the browser making the request to your app. I've asked a couple of times if you've checked your WAuth settings - have you gone through them in detail? Do you have a resource on how they should be properly set, or a troubleshooter?

Referring to https://richhewlett.com/2011/02/15/getting-a-users-username-in-asp-net/ , scenarios 2 and 4, can you post the results you're getting for:

HttpContext.Current.Request.LogonUserIdentity.Name
HttpContext.Current.User.Identity.Name
Security.Principal.WindowsIdentity.GetCurrent().Name

*
Speaking generally, using WAuth on corporate intranets must be widely used. If it was broken as you seem to be finding there should be lots of forum posts to that effect.

One thing that's come out of this discussion is it looks like the only way you can have a hope of getting what you need in your ASP.NET app is by using WAuth. Only scenarios 2 and 4 at the link above can give you what you want, and they both require WAuth on IIS. To test that WAuth is working I suggest setting up its security and testing that unauthorized users can't get in.

Right from the very start this whole thing has looked to me like a misconfiguration somewhere. Something you'll find, fix and shout "Eureka!" e.g.

- company IT made some change to IIS or AD/security

- when doing extensive troubleshooting it's easy to forget what changes you make and how to get back to the default

- triple-check that the context of the web request is as expected so it gets properly passed into your ASP.NET app via WAuth

I can't think of anything else to add.