Link to home
Start Free TrialLog in
Avatar of sonus
sonus

asked on

Retrieving Windows Authenticated UserID from ASP.NET

I've asked a similar question to this before, and essentially the answer was to use Environment.Username.  That works from a desktop application environment, but when I run the component through IIS with ASP.NET, the Username always comes back as "ASPNET" and the UserDomainName always comes back as my computer name.

I have tried using Request.ServerVariables, but it doesn't seem to have the User's authenticated name.  This web app I'm using is only used by users Authenticated on the local network.

My question is, how do I retrieve the username/domain from an asp.net web page?

Thanks
ASKER CERTIFIED SOLUTION
Avatar of naveenkohli
naveenkohli

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of naveenkohli
naveenkohli

Use WindowsIdentity class to get the current logged in WIndows user and then get the name of that user.

WindowsIdentity.GetCurrent().Name;

Or you can use Request object to get authenticated user
I've had exactly the same problem.  The aspnet_wp service runs as a special user, which seems to block authenticated access.  I've tried:

1.  Changing the user that aspnet_wp runs as.  This breaks the debug environment.
2.  Changing the security setting in IIS to deny anonymous users (and turn on "integrated security"), and modifying web.config by adding the line:
<identify impersonate="true" />

Neither seems to work.  WindowsIdentity.GetCurrent().Name is just another path to Request.ServerVariables("LOGIN_NAME") and returns an empty string.

So I'd be interested to know if you can make it work, sonus :-)
"WindowsIdentity.GetCurrent().Name is just another path to Request.ServerVariables("LOGIN_NAME") "

These two are two totally different concepts. Every ASP.Net thread impersonates as a windows user. For ASP.Net (default) it is the ASPNET account.
Request.ServerVariables("LOGIN_NAME") is not Windows.Identity. The other way could be true. So don't confuse the 2 identities.

"Changing the user that aspnet_wp runs as.  This breaks the debug environment"
There could be some other reasons for this. ASPNET user is not member of Debugger Users and VS Developer Users. This could prevent you from debugging any application on your system.
>> There could be some other reasons for this. ASPNET user is not member of Debugger Users and VS Developer Users. This could prevent you from debugging any application on your system.

That's exactly the error I get...  I have to admit, I find the new .NET security settings a bit confusing - I was used to the ol' IIS settings, but a lot of the IIS stuff seems to get overridden by the various .config files?  

Sorry for hijacking your question sonus, but hopefully we can both get a resolution this way :)
I tried (again) to use WindowsIdentity.GetCurrent().Name to get the authenticated user (with debug.print lines) and got the correct user - verified this by connecting from a different machine, with a different login (because I have had the problem of the debug environment returning "my" username in all cases - VB6 days).

Do you have an explanation of why WindowsIdentity.GetCurrent().Name works, and Request("LOGON_USER") doesn't?  (Well, I can see why WindowsIdentity.GetCurrent().Name works, I'm just interested in why Request("LOGON_USER") doesn't? )
Finally MS is making things more tight as far as the security goes. A lot of old mistakes are being fixed. I don't know if you know this or not, but setting those isolation levels in IIS have no effect in ASP.Net applicatin. You can set it to wahtever you want. ASP.Net framework is going to spawn new process for your call.
Wait till you see IIS6.0 A lot of implementation has been moved into kenerl mode and a new user account "Network Service" is coming into play :-)
When you make a call into ASP.NEt application, it has to spaw aspnet_wp.exe process. And this process is spawned under a windows user identity. The user is decided by 2 settings. IIS authentication and web.config setting. So when you have set <impersonate> to true, then IIS is going to spawn the process under the identity of IUser_<machinename> [for anonymous] or currently logged in user. But if you have <impersonate> set to false, then it is always going to use ASPNET user account for runing the porcess. Therefore when you call WindowsIndentity.GetCurent , you get the windows authenticated user.
Try getting Reques("AUTH_USER"). It should give you the logged on user. LOGON_USER may or maynot give you information.
Thanks for the explanation.  Request("AUTH_USER") doesn't work either...

I don't have any problem with MS changing things around, but they *should* make it so that the IIS snap-in configuration settings have an effect on your virtual dir, or disable them entirely (i.e. they should have shipped a new IIS config snap-in with the framework).  Developers and admins alike are likely to find it very confusing to have settings sitting there that don't do anything.  That said, WindowsIdentity.GetCurrent().Name solves the problem, it's just a pity the Request ServerVariables are not being populated correctly.

In Windows.Net Server (IIS6) nothing is enabled out of the box. Even IIS is not installed. You will have to install it. And when you install it, it only allows HTML pages to run only by default. You will have to turn on every thing manually now. Everything is locked down. This way you don't have to worry about any server option being run without you knowing it. Now web server admins will be responsible for turning on the options. Even ASP.Net security behaves slightly differently than the current configuration.
Avatar of sonus

ASKER

Thanks naveenkohli, you are the man.