On my Intranet Web Application, I have enabled Windows Authentication. For the first time when I take the App, it asks for Windows Authentication. From there it will never ask. How can I know whether the authentication is happening on each refresh of my page after first attempt?
For example, if I tried to change my Windows password while the app is running, will the app prompt for password again on refresh?
The authentication happens when you first connect. The server knows who the user is and is able to keep them logged in. If the user changes the password it will not ask them to re-authenticate until they close out the browser. This is due to the fact they already have an authentication and that will stay there until their session is done, usually by closing all instances of a browser (multiple windows of the same browser can share the same memory for things like cookies and authentication)
Think of it this way. You go into your home after you unlock the front door. You don't have to do this again until you leave your home. You can change your lock while you are home and still be in your home without having to unlock it again until you come back.
Related
I'm afraid I cannot get through this problem on my own. It is weird that this issue seems to be unique for my installation.
On my WordPress-based website users are having trouble with the login, especially when using their mobile phones to authenticate: they are being logged out (even when checking "Remember me") and will have to re-enter their credentials (after which they're logged out again). From what I figured, it is most likely the fact that their respective mobile Internet Service Providers dynamically assign new IP addresses to their devices all the time, causing the authentication to fail.
When I'm using my desktop to login, everything will work just fine. However, say, I have successfully logged in to the site with Google Chrome, and I open an instance of Mozilla Firefox (or any other browser) to log in simultaneously, Chrome's user "session" will be shut down immediately (I know that because an asynchronous script is requesting whether or not the user is logged in and it prompts me to log in once I sign in using the other browser). Therefore I believe that the whole WordPress authentication has got something to do with the user agent, too.
Albeit I highly appreciate the extra amount of security provided by automatically voiding a running session when accessing the site from a different IP or browser, my users do not. Even for myself it is remarkably cumbersome, using three different machines plus tablet and phone to access the site from any possible place (eventually I stopped bothering to log in and just waited to get home).
Since WordPress authentication uses cookies, I looked into how these are generated. The wp_generate_auth_cookie() method uses the user name, parts of their hashed password, the expiration time and a salt (a constant salt defined in wp-config.php), but neither does it use the IP address nor the user agent.
I literally searched the whole WordPress folder for "user agent" or "IP address" occurrences but there is no login-related script containing the terms (merely a handful of plugins that don't affect the user session at all).
That puzzles me. How does WordPress even realize that I am logged in with a different browser / computer if it doesn't store that data with the authentication cookie? And where does the check happen that logs me and my users out?
Do you have any further ideas on how to troubleshoot the issue?
Thank you very much in advance!!
Harti
Cookies are stored by browsers and different browsers on the same machine don't share that storage. Thus when you login with Chrome, WP sends a login cookie to Chrome, starting a new session. When you then access the site with Firefox, FF doesn't have a login cookie so WP prompts you to login and then sends a login cookie to FF, also starting a new session. The next time you access the site with Chrome, it gets Chrome's login cookie, which doesn't match the last one sent out that's associated with your username, so everything starts all over again.
This doesn't directly explain the problem with mobile devices; it sounds like for some reason they aren't storing the cookies properly.
We have an ASP.net app running on a pair of hosted servers. Access to the app is controlled by IIS using integrated Windows security. ASP code files are in one iis site while static content is served from another. The files sit on a UNC share \\10.x.x.1\mySites and are accessed by users running IE8 and 9.
In the last fortnight or so, the application users are finding it difficult to access the site. Now, when they request the URI they get presented with the standard login box which reappears after every single attempt at gaining access. After a half a dozen attempts the process ends with a '401 Not Authorized' error.
This is odd enough, but after getting one of our network guys to take a look at it, it turns out that the credentials the user typed into the IIS password prompt are not being transmitted to IIS - rather its the credentials (Windows login Id & password) of the current user that are.
Can anyone shed any light on what is happening?
I think IIS holds user account credentials separately in order that it can proces anon access. If this gets out of sync with the corresponding system credentials for the anonymous account, this sort of thing can happen. Have a poke around, I think there is a way to reset IIS.
I have a MVC3 mobile intranet site targeted, among others, towards tablet devices (iPad).
When I open the site on an iPad, I get a pop-up screen asking for logon credentials. I cannot in any way cache these credentials, so every time this application is opened the user is prompted for their credentials.
Since it's not possible to include an iPad in a Windows Domain (as far as I know), is there any way at all to get a login screen using Windows Authentication, making it possible to cache credentials and maybe maintain the session over longer periods of time so that the user will not have to re-enter their credentials when opening the site ?
It's definitely possible as that's what Exchange OWA does. These articles may be of use: http://helios.ca/2009/05/04/aspnet-mvc-forms-authentication-with-active-directory/ & http://msdn.microsoft.com/en-us/library/ff650308.aspx
Once authenticated via the form you can just add a session/cookie to maintain the session.
I am working on an application that uses windows authentication. Within this application, we give the user the ability to change their password.
The user can change the password just fine. However, after they change their password, that is when things get weird.
Sometimes they can navigate through the application just fine.
Other times, they click on a link and are immediately prompted to supply credentials.
Occasionly they can click on a link but upon a second click they are prompted to supply credentials.
Does the browser keep a token to the original credentials and use this when they request the next page? If this is the case, why can i continue using the site sometimes? Can I change the password and then assign that token to the request?
Does anyone have suggestions?
It's a caching issue. If the user connects to an ASP.NET app using Windows auth, the connection will linger for a while for performance reasons (you really don't want to do a complete re-auth on every page request!) - even then the password change has to travel from the PC, to the domain controller and then to the ASP.NET server, so there is often a small delay. My recommendation would be to drop the browser and wait 30secs before reconnecting.
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.