I've been working on this Silverlight app for quite a while now. I have two dev machines. One has windows 7 and the other has windows 8. The SL app implements authentication through WCF and an implementation of MS membership engine. All was working well until I installed win8 on the other machine. Now, when I authenticate from this machine I get the cookie information back but any further request to the server is sent without the cookie information. It doesn't matter which browser I use and what my internet settings are (privacy/security levels all set to lowest... still same issue).
I looked at the requests on fiddler and compared between the two machines. They both send the same requests when logging in and the both receive similar data including the "Set-Cookie" header. The next request however, isn't similar. One machine sends this .ASPXAUTH cookie along with the ASP.NET_SessionId one and the other sends only the ASP.NET_SessionId. It's like it ignored the Set-Cookie command.
Any ideas how to solve this? I tried everything on my internet settings and nothing seems to make a difference.
Thanks,
Eyal
Related
Every aspnet web application I try to run locally just doesn't keep sessions anymore.
Somehow, this happens on both VS 2013 & 2015 with different projects. I haven't touched anything, one morning I found out that after a redirect every session data is lost.
These applications are still working on production and dev environments.
A proxy server or firewall on the web server side is stripping out the
cookie. It may be that the user is correctly storing and sending the
session cookie, but that the hardware on the web server's side is
stripping out the cookie before it can be read by the ASP or ASP.NET
engine, causing the server to generate a new SessionID and a new
cookie for the user on each request.
I have some JS that is on some intranet application that's running on HTTP (this server/service is out of my control, run by the customer). I operate the internet application and it must run on HTTPS for security purposes.
I'm attempting to use XDomain but I'm finding that the cookies aren't being sent. Is the problem that I'm going intranet to internet or that I'm going HTTP to HTTPS or some configuration problem?
I keep getting 401 when checking authentication of the user even after they have logged in.
I've verified the backend/internet service works as expected via a jsfiddle (i.e. Access-Control-Allow-Origin, etc. are all correct).
Thanks!
There are some security related issues with XDomain that makes it strip any cookies according to no 5 in this msdn blog. However there also exist a workaround using proxy with example project on Github. I think everything you need to make it work are described in those two pages.
We have several IIS6 .NET 4.0 web applications within an enterprise environment that leverage Windows Integrated Authentication on an Intranet Zone. All applications were working correctly and as expected until recently. After a "rebuild" of several user accounts that necessitated a username change (don't ask why, I have no idea), users with the "new" accounts are unable to access some of the Integrated Auth applications, but not all.
What we are seeing now for users with workstations not joined to the domain is:
User request results in 401 as expected, which opens the NTLM Dialog
Fiddler reports valid request and response that includes default 401 message
Request is logged in IIS log file as 401 User enters proper credentials (domain\username + password)
Successive request hangs and browser (IE, FF, Safari, and Chrome tested) status just spins
Fiddler reports value GET Request, but no response ever occurs
IIS Does not log the GET after auth and we never see the 200 response that we see on the functioning applications.
As I said, this is only affecting the newly created accounts.
This is impacting 2 of 4 integrated auth applications, all in a first level Virtual Directory from the root. The other two are still functioning as expected. We've moved into dedicated app pool and that does not resolve. We even have 1 impacted application using the same app pool as a still functioning application, and still there is no function. The Web Root does not and cannot use Integrated Auth.
I need to get the Windows domain name from Internet Explorer using classic asp (I could try it in another way if with classic asp it's not possible).
I need to do this in order to insert the domain name into a database row.
So again, in summary, I need to retrieve the Windows computer domain name from the Internet Explorer that is accessing to a particular webpage.
Any idea where I could find and example in order to do that?, is it possible?
Web browsers by default use the web protocols (think Http, Html, Ssl, etc.). By your username I know that you are familiar with the RFCs that define these protocols.
Windows networks use a different protocols. The Domain is a logical security boundary in Windows networks. Yes, in modern versions of Windows Domain security uses standard protocols like Kerberos.
The problem you'll have is that a web browser doesn't normally send extra information to a web server about the client. That would be a huge security problem. So, by default a web browser (even IE) would not volunteer any network security information in an Http request.
When your web server requires client authentication, the web browser then must provide more security information to the server. Depending on the type of authentication your web server requires, your browser will send different information. For instance, in Http Basic authentication, the browser will send a username and password.
To my knowledge, the best way to get Windows Network Domain information from a web browser is to force the browser to authenticate using Windows Authentication. This is a special authentication mode that Microsoft built that pushes Microsoft network security information over the standard Http protocol. However, in order for this to work:
Users must be running IE on Windows
Web server must be IIS on Windows
The client and server must have a Windows security relationship
IIS must be enabled for Windows Auth
There are many restrictions about the network path between the client and the server. Proxies and firewalls will typically prevent the IE Client from using windows authentication with IIS.
If you can live with this checklist, I think you will find the domain info in the one of the http headers. You may have to parse it out of the username which will be domain\user. But I'm sorry I don't remember the specifics. This should work even in classic ASP. More info on Windows Authentication is available at http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication
http://msdn.microsoft.com/en-us/magazine/cc301387.aspx is about ASP.NET, but it says:
For a user authenticated using Windows
authentication, the name is of the
form domainname\username, where
domainname is the name of the domain
in which the user is registered (or
machine name if it's a local account
instead of a domain account), and
username is the user's name.
In Classic ASP, try Request.ServerVariables ("AUTH_USER") or Request.ServerVariables ("LOGON_USER")
One alternative to Windows Authentication is to use Basic Auth and force the user to login with their windows credentials as domain\user. This however presents other security issues and you should do this only over SSL. However, this technique will work over the Internet and doesn't require a security relationship between the client PC and the server. This would also work for non-IE browsers.
In case anyone happens to get the same problem, here is the solution I've implemented (pretty much what Michael Levy said).
You have to activate Integrated Windows Authentication in IIS: http://en.wikipedia.org/wiki/Integrated_Windows_Authentication.
You can read here how to do it: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5f8fe119-4095-4094-bba5-7dec361c7afe.mspx?mfr=true
After that you can use:
In Classic ASP Request.ServerVariables
("AUTH_USER") or
Request.ServerVariables ("LOGON_USER")
It seems to work also with other browsers, not only with IE.
Thanks again to Michael Levy to point me in the right direction.
Background (just the relevant pieces):
We have a large intranet asp.net 2.0/3.5 app.
Web servers are Windows Server 2003 on an AD domain.
Clients are on Windows, IE 6-8.
Windows Authentication, with a custom principal created from the Windows Identity.
Web servers sit behind an F5 NLB which forwards the user to a specific web server. (The reason for this is a limitation w/ our company's F5 dealing w/ kerberos).
There are no system wide problems like dropping sessions, or timeouts, or overloaded servers, everything's running fine in general.
One piece of functionality requires delegation - we are connecting to a network file share as the authenticated user, using the Kerberos token given to us by the domain/web server.
SPNs, ACLs, etc, seem to be set up properly.
99.x percent of the time, it all works. The problem we're seeing is every now and again, on a refresh, the token drops from kerberos down to ntlm. I can see the login on the web server's event log showing one call getting this:
Logon Process: Kerberos
Authentication Package: Kerberos
And a subsequent call (usually after 10 or 20 page loads) getting this:
Logon Process: NtLmSsp
Authentication Package: NTLM
Anyone have any insight as to what might be making a subsequent postback sometimes go NTLM?
Thanks!
All the tools and techniques you need to identify the issue are in Troubleshooting Kerberos Errors. That document never failed me.
NTLM Fallback
You might find that the
security log recorded an event in
which logon occurred using NTLM when
it should have occurred using Kerberos
authentication.
Problem
There are two
situations in which this might happen:
- The first situation is where the
system attempts authentication using
the Kerberos protocol but it fails. As
a result, the system attempts to
authenticate using NTLM. Windows
Server 2003, Windows XP, and Windows
2000 use an algorithm called Negotiate
(SPNEGO) to negotiate which
authentication protocol is used.
Although the Kerberos protocol is the
default, if the default fails,
Negotiate will try NTLM.
- The second
situation is one in which a call to
Negotiate returns NTLM as the only
protocol available.
Confirmation
The
first situation will result in a
failed Kerberos authentication that
you can investigate by examining
errors in the event log or data
packets captured by Network Monitor.
Both investigation methods are
discussed later in this document...