I have an application set up in IIS that has Windows Authentication enabled. When I browse to this site in IE11 it prompts me for login credentials (which is strange because I'm logged on to the domain)
However, when I open up Fiddler it starts working perfectly fine, no prompts for authentication. When I close Fiddler again, it starts prompting me again. Any idea what could cause this? I'm trying to narrow down what exactly Fiddler is doing so I can figure out what I need to do to make the prompts on my app go away.
I cover many possible culprits in my post Help, Running Fiddler Fixes My App. My guess here, though, is that maybe your server is trying to use Kerberos authentication when going direct and NTLM when you go through a proxy.
To better debug this, a few things we need to know: Which browser? What's the hostname of the target server? Is it hosted on your current machine? If you disable Tools > Internet Options > Advanced > Use Windows Integrated Authentication (and restart) does it make a difference? What Zone (Right-click the page in IE, choose Properties) does the target run in?
Related
My website is working with some ISP while it is not working with others. Also not working from other countries.
The app is hosted at our company. Developed using sharepoint asp.net.
The app works at my home.
But if I visit the website at my brother's home who is registered to different ISP, the website opens and a login dialog appears. When entering correct username and password then submit , textboxs cleared and dialog come again.
The problem is happening with many visitors.
I just want to know what would be the problem! Does anyone faced such problem before?
I checked all IIS restrictions. There is no restrictions made.
I created a new app using sharepoint with login page and it works great.
somebody said that users with public ip can access the site while others with dhcp cannot. Can somebody explain that !
Some ISPs have transparent proxies in use. And some of them are accidentally (or even intentionally) broken and cache more, than they should. You can check whether that's the problem:
Set up your server to also allow https and then use that. You should move to https for privacy reasons anyways, so just do it now ;)
This way, the proxy can't do anything but to pass the data between client and server unmodified.
If that is not an option: Use tcpdump/wireshark/other-sniffer on both - client and server - at the same time and compare the logs. Did the second access even make it to the server?
Do you have a laptop/tablet/smartphone with which you can access the web server? Try moving that laptop from one location to the other and check, whether it works with that one laptop using one ISP and fails with the same laptop on the other ISP.
This should be a comment, but I do not have enough to post it as such.
Are sure that it is not a browser issue?
Is the login dialog from SharePoint, your app or the browser itself?
If it is from your app, can you debug it or write the log-in attempts in a log?
Accessing an application manually works fine, creating a manual script with web_add_header works fine, but when just hitting record in vugen with the http protocol the webpage gets "page cannot be displayed".
What can cause this? I assume it has something to do with security?
Can I change some settings in vugen to make this work?
I don't know that this will solve your problem, but I have seen somewhat similar behavior when dealing with security certificates on SSL enable pages. Try installing or re-installing the security certificate for the site in IE before you try recording the script.
Take a look at your credentials in the system and your browser vendor/version. Make sure that you have admin rights and that you are using a 32 bit browser (VUGEN is a 32 bit application) is one supported for your version of LoadRunner
I've created an intranet site that uses windows authentication
In chrome I can access the site instantly, and in FF it requires Active Directory login.
But with IE7 I'm getting the following error:
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
Im unsure as to why its okay in other browsers but not IE?
Any help appreciated.
Thanks
Solution:
IE is using Kerberos and not falling back on NTLM like Chrome and Firefox. You must force NTLM authentication in IIS7.5 by following these steps:
Select your site.
Double click authentication.
Select "Windows Authentication" (ensuring that it is enabled).
Click "Providers..." in the right hand column.
Select NTLM and click "Move Up".
Link: windows authentication not working in ie7
I'm not familiar with IIS, but in the past few weeks I've had lots of hand-on experience in integrating AD login into web applications. As is quite logical - every Microsoft product would be better integrated with another such, and Internet Explorer (should be valid for all versions, not just 7) automatically passes your AD login credentials as long as you use Active Directory for your Windows login authentication method.
Every other browser will either need to be configured to do so, ask you to type them in manually or will not support it at all. Which explains why Firefox asks you for a username and a password. Under Opera, you'll most likely get the same error message.
My guess about Chrome is that it's your default browser of choice and at some point in time, you've typed in your login creditenials and that session is still active.
All of this would mean (if my assumptions are correct) that you need to use a different AD account to login into this application than Windows and the latter (being automatically passed by IE) is not authorized.
It sounds like your environment is not setup properly for Kerberos authentication to take place. There are many things that can cause Kerberos authentication failure. E.g. Clock skew on the server or client, missing SPN on the web server, etc.
Normally, when you configure to use Windows authentication, you are asking to use SPNEGO, which means using Kerberos whenever possible and then fall back to NTLM if Kerberos fails. However, this post pointed out that this is no longer true. IE7 stops at Kerberos in certain cases but not falling back to NTLM.
You can try to disable the "Enable Integrated Windows Authentication" as the post suggested. It looks odd but it actually just turns off the SPNEGO, you will still use the NTLM.
I guess Firefox and Chrome works because they are using NTLM but not Kerberos. From my experience, non-Microsoft browser doesn't do Kerberos out-of-box. You need to do some configuration work to make it happens. For example, in FireFox, you need to set the network.negotiate-auth.trusted-uris parameter. See here
Once you confirm the NTLM for IE7 is still working fine. Then, you can post another question to ask how to fix the Kerberos authentication problem for IIS.
start off by looking here and getting a more detailed error description. I had some crazy problems with CRM and it all came down to the order of settings in IIS the answer to the problem ended up being as simple as ;
going into iis and then the authentication setting
clicking on windows authentication and selecting advanced
make sure kernel mode is on
click on providers and ensure negotiate is above NTLM.
Our web application uses Windows Integrated Authentication (aka NTLM Auth) for security.
It's working fine for both IE and Firefox users, but Safari users are seeing intermittent problems. Browsing the site will work fine, but every once in a while there will be problems loading elements of a page (e.g. CSS or JS files). Reload and the problem will go away.
If we use a debugging proxy (Fiddler) we can see that there is a lot of extra 401 requests happening with Safari. Every once in a while a request for a resource will get stuck in a 401 request loop, and eventually fail.
I can't see anything that we're doing to cause this, and it would appear that it's a bug in Safari. Has anyone ran across this issue before, and have any suggestions for a resolution?
Thanks,
Darren.
Some web sites http://www.musteat.org/nodes/show/151 indicate this is an issue with negotiated authentication.
You can turn off Negotiate in favor of pure NTLM in IIS via the NTAuthenticationProviders Metabase setting, and the following ADSUTIL command.
cscript adsutil.vbs set w3svc/WebSite/<SiteID>/NTAuthenticationProviders "NTLM"
Change < SiteID > to the appropriate ID, typically 1.
I have an Intranet http application running on several machines in our Windows domain; everything works when using IE 7 because I can configure it to use Kerberos authentication and I've figured out how to get one of the intermediate machines to be Trusted for Delegation.
I have researched and tried to get Firefox 3.0.10 to use Kerberos:
navigate to about:config
filter to network.negotiate
update network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris
with the following entries(separated by comma): http://jupiter2000/trimbrokerclient,http://johnxp/fileservicedemo
I have done this and even restarted Firefox and when I browse to the above sites on our LAN, I still get prompted for username and password and even when I supply them and the web page is loaded, I have some code in the app which displays the authentication method in effect and it is still NTLM, not Kerberos as when IE is used.
Can someone comment on how to get Firefox usable on this Intranet application of mine? Thank you.
p.s. while the names above are different, the app is the same. JUPITER2000 is IIS 6.0; JOHNXP is IIS 5.1.
From what I have done myself, you will only want to input the domain, and not the http:// or path.
There are 5 settings that need to be changed in FireFox.
Only the domain is necessary.
See them all here:
FireFox settings for Integrated Windows Authentication
you must use just the server name:
jupiter2000,johnxp