Is there a way to get the logged in user from a vb.net web application? IE, if someone logged in as "foo"/"bar" on their local machine accesses the site, I need code to get me "foo"/"bar". This is for a passthrough on our intranet, where everyone uses the same Active Directory.
Essentially, I need to harvest the username of the logged in user and check it against our ActiveDirectory instance. If that fails, I need to check for Request variables and check those (that part is fairly easy). Then if THAT fails, I need to show a login screen (I also have a handle on this).
I've already come across and discarded a couple solutions for the part I'm having trouble with:
request.serverVariables("LOGON_USER") - This only works if you have anonymous access turned off in IIS, and that must be on to use forms authentication (which I'm using).
http://www.thescarms.com/dotnet/IsInRole.aspx - This solution does not seem to work for some reason. I suspect the line AppDomain.CurrentDomain.SetPrincipalPolicy( Principal.PrincipalPolicy.WindowsPrincipal) is the issue, but the meaning of this line is buried so far I can't figure out what it's actually trying to do.
HttpRequest.LogonUserIdentity?
if you're using Forms Authentication, have you tried System.Web.HttpContext.Current.User.Identity.Name?
The web browser will not send the user's local credentials to the web server unless two things are true:
The web server asks for them (i.e. Anonymous Access is disabled, and Windows Integrated Authentication is enabled).
The web browser has been configured to send local credentials if asked (an Internet Explorer option, available in FireFox via plugin, not sure about other browsers). If the browser has not been configured to send the information and the web server asks, the user will be prompted within a pop-up login screen.
Related
My application uses a Angular frontend paired with a C# backend.
For determining who's currently sitting in front of the pc, I use C#/ASP.NET's Current.User.Identity .
Now, there is not a coding issue, my problem is that windows keeps handing out the wrong Identity. This happens since yesterday. My website keeps telling me I am IISAdmin, instead of my User Account that I am using right now.
I am guessing this probably stands in some relation to me adding a couple of network shares (quick access to the servers) using the credentials of IISAdmin and ticking the checkbox "Save Credentials".
Normally when I deploy patches I just connect to the server manually via explorer, and enter the credentials by hand. I have done this multiple times, this has never been an issue.
This is where it gets a little odd. I have tried starting Chrome explicitly as my User, and it just merged the window into the existing Chrome window I had already. Opened my web-app, IISAdmin.
I closed Chrome entirely, started it explicitly as my user again, IISAdmin.
Starting Chrome as a dummy account that I have access to, Chrome correctly opens a new Chrome window, and User.Identity confirms that I am logged in as said Dummy.
Internet Explorer behaves exactly the same way, so this is not browser-specific.
Even after a complete reboot this keeps remaining an issue. The network shares were removed after the restart, I am assuming they were temporary.
Windows should hand out my standard issue user account auth, not a highly powered super admin that's just saved somewhere.
After talking to some colleagues, they pointed me towards the solution.
If this happens to you:
Go to System Control / Credential Manager / Windows Credentials
(Golden Safe)
Delete the conflicting credentials
I was not aware of this at first, but when you create a network share and save the credentials, it saves them here.
What I didn't expect was that windows maps the file path to the server to the server's actual IP / DNS adress.
So whenever you connect to said server, Windows uses the saved creds it has, and because of the way Kerberos works, your existing token just get's handed around.
Hence making things a little mushy, even if you explicitly start Chrome as your normal user.
Our ASP.NET application is hosted in IIS 7.5 and has the following setup:
main site is hosted under root IIS folder accessible with http://siteurl (1)
we have a separate app in the same AppPool hosted under http://siteurl/Intranet (2)
Main app (1) has Anonymous Authentication enabled along side Forms Authentication (url: siteurl/loginform).
Second app (2) has Integrated Authentication (NTLM).
The login procedure works as following:
User goes to siteurl first
User gets redirected to /Intranet to check integrated auth
If integrated is accepted user gets redirected back with proper auth cookies to siteurl and gets access to the site
If integrated fails user gets redirected to siteurl/loginForm to manually fill in credentials
We have some issues with Internet Explorer (8, 9, 10) that refuses to submit the form data at step 4. It appears to be a known behavior that IE will not POST content to an unauthenticated site once the NTLM negotiation started for that session. I have considered some workarounds for this:
store credentials in a cookie (with JS) and on the server if the POST content has 0 length try to check the cookie values. delete the cookie afterwards
send credentials using GET instead of POST (ugly as we need to make sure the user does not see his just posted password in the browser address bar)
Provide a link to the user to open a new tab and continue the auth process in a separate browser session (this seems to work as IE will happily send POST data from a second tab)
Are there any other options we might have to get around this issue?
From the above 3 which one would be preferable and what unconsidered pitfalls we might encounter?
I wrote about this issue here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Your question omits important information which makes it hard to troubleshoot. You should never see the problem described with the literal URLs you've used, because IE uses protection spaces to decide whether a site is going to demand credentials via a HTTP/401 and example.com/ and example.com/foo/ are different protection spaces.
It would be very helpful if you could share a Fiddler log of this scenario for better troubleshooting.
I have a diagnostic web application hosted in IIS7 that has Windows Authentication enabled and Anonymous auth disabled. This application generated some kind of a report where it includes information about what kind of authentication was used to view the site. Every time I browse to this site I get a message that I connected using Anonymous authentication which for me is unbelievable. The report works fine (tested on other machine) and the fact is that I do not get a credentials popup. How is this possible and how can I fix this?
First, i'm not knocking your diagnostic application, but it may be worth looking at the IIS logs (or indeed switching them on for your site) to see what IIS thinks is going on. If you're not familiar with IIS logs, I'd suggest writing them in Microsoft format (at least while you're sorting this problem). One of the key fields you get is the user id. If you really are hitting the pages anonymously, this id will be the id you configured to field anonymous requests. Otherwise, it will normally be the calling user's id (at least in a simple scenario).
Second, how many sites are you running? Are you sure you're going in through the expected site? Or maybe you're hitting the default site instead?
Third, bear in mind that authentication can be set at the site level but anso at the page level. Are you sure one isn't overriding the other?
What are the steps required to get smart-cards authentication working in ASP.net?
Smart-card reader is installed and works properly on the client's machine
user navigates to Login.aspx page and is prompted to swipe his access card
how do i authenticate the user
thanks.
The only way that I know to access a hardware device on a client machine through ASP.Net is by writing an ActiveX control. Doing this will render the site useless to anyone not running Internet Explorer. Based on my experience, you can say that IE is your standard, but there will be people attempting to use other browsers. And that's fine as long as you have the support of your App Admin team to say, "Sorry, use IE or don't use it at all".
Assuming you already know how to access the Smart Card reader's API, and you can successfully read and decode that data, your next step is Authenticating that data.
Again, you haven't given me any information here, so I'll assume that you have a database, against which you will need to validate the data you got from the smart card.
If the above returns true then it's simply a case of calling FormsAuthentication.RedirectFromLoginPage, or if you want a more granular control of the Authentication Cookie, then you can create your own FormsAuthenticationTicket
If this is a plug and play device and your clients are part of an AD domain then by simply enabling windows authentication allows you to enable smart card authentication without needing to resort to custom ActiveX controls and browser plugins.
A couple of pointers in that direction:
IIS supports client certificates
IIS Forum thread: Configuring IIS 7.5 to read certificates from a smart card
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx