We have a website to which we have now added Windows authenication. Now when I release my changes to the server,IIS asks for Authenication, and after trying with right credentials for 3 times, I get Not autorized error.
If I try to access the website from within the server using localhost, it works fine. It also works fine if accessed remotely using IP address instead of hostname.
http://localhost/mysite works fine from within the server EXSER002.
http://IPADDRESS/mysite works fine
http://EXSER002/mysite fails with authentication.
The site use to work with the hostname prior to Windows authentication.
Even tried ping from local machine to the server and I can ping both the hostname as well as the IP address. Error I get is: You are not authorized to view this page
Do you have a proxy? If so, make sure that bypass is on for local addresses.
Check this link.
http://support.microsoft.com/kb/896861 .
The issue occurs due to the loopback check security feature .you need to make registry setting changes (as mentioned in the link) to get rid of the authentication failures.
Related
I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.
I have written an asp.net application and validated the logged in user with Active Directory.
It works perfectly in my local machine IDE. But when hosted in my production server, it couldnt communicate with the AD Server.
I have windows authentication enabled in my IIS in server as well has put identity impersonate in my web.config.
The error is get is
Error Trace :System.Runtime.InteropServices.COMException (0x8007054B): The specified
domain either does not exist or could not be contacted.
Any suggestions is appreciated.
That error usually means exactly what it says - that it cannot find a DC to authenticate against for the specified domain. Are you sure the production box can hit the domain via DNS? You can use nslookup if the server is Windows. This will confirm you can actually hit it. You usually see a different error if it's a security/rights issue.
If it is a windows box try using nslookup domain_name and see if any IP addresses are returned. If they aren't, then that's your issue. You may need to manually configure the IP address if that's the case or resolve the potential routing issue if you can't hit it by IP.
I have an IIS7 site that works fine while on the server, however refuses to work from anywhere on the network.
When logged onto the IIS Server itself (with remote desktop) then the website shows fine, as per this link (I used port 801 for this site):
http://localhost:801/
However when attempting to access this site from the network, it refuses to work, giving the generic 'cannot display the webpage' message, while using the following link:
http://<<my IIS server>>:801/
Another thing I have noticed however is that on the network the default page (port 80) of the IIS server DOES work. I.E this following link shows the standard IIS7 page:
http://<<my IIS server>>:80/
Most of the help topics I've read point to it being a firewall issue, however as a test I disabled all firewall settings on the IIS Server, yet it still refused to show.
Does anyone have any other suggestions?
Many thanks
Did you tried with computer name and / or IP Address
e.g: http://192.168.1.105:80/
http://DELL_PC:80/
Run the following tests:
Check connectivity from both computers.
Firewall settings, temporary disable the firewall from all profiles (private, domain, public) if this works, try adding a Port Rule to your firewall allowing incoming connections to port 80.
Also, it'd be important to check the bindings configuration of your website, bindings specify the address the server should listen to for incoming connections, make sure you have 'All Unassigned'.
Reference : Click Here !!
I have an an intranet website running under IIS6 (under a specific port, not the default one) with a integrated windows authentication enabled and uses an application pool configured with a service account. the issue is, if I access the website using the server name with a fully qualified domain in the URL, it throws a login prompt (doesn't work even if enter my windows login credentials), but if I use the IP address of the server then it works fine. Please let me know what I need to do to get the URL with server name working.
for example http://servername:8080/default.aspx throws login prompt, but http://ip address:8080/default.aspx works fine
I am experiencing the same problem. I believe it is something to do with Kerberos authentication mechanism. If it resorts to NTLM it will work (which it does when using an IP address). Kerberos requires an SPN registered on Active Directory for it to work. Kerberos also won't allow you to have application pools running under different accounts but with the same server name. In these situations you should have an alternate name for the site and register that with Kerberos. However, I haven't actually resolved the issue yet so these are just suggestions.
Two possible problems come to my mind:
The DNS server in your network is not resolving servername to an IP
Run Ping servername from the command line to check if the name brings the IP expected
edit the C:\Windows\System32\drivers\etc\hosts file and add the server name and IP address
The Bindings in IIS6 does not expect servername
Make sure that servername is included in the list or the Host Header Name field is empty
I had exactly these symptoms when the web server had its IP address changed due to a new internal IP addressing scheme. Pass through authentication worked from the webserver itself but not from any other system. From other systems, using the host name in the URL caused IE to prompt for credentials which were always rejected, using the IP address in the URL caused IE to prompt for credentials which were accepted. After chasing a lot of red herrings we suspected that the server was caching credentials against the old IP address, so we rebooted the server and it all came right.
Try this. I had exactly same problem and it fixed it for me (I'm the linked thread)
I set my AuthenticationProvider for my website to "NTLM, Negotiate"
Following these instructions:
http://support.microsoft.com/kb/215383
With a slight change to their instruction to set provider of course
mine:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "**NTLM, Negotiate**"
You can get the Website ID by clicking on the "Web Sites" folder on the left in IIS. This should list all your website with their ID
Thanks to Nick's answer that lead me to it
I'm setting up a (ASP.NET) website to be used internally at my company. In IIS, I've turned on Integrated Windows authentication and turned off anonymous access. Once I've done this, the website pops up the "enter your username/password" box whenever you visit the site, but won't log you in even if the username/password are correct. This happens even if you're logged in to your computer with a domain account as opposed to a local account.
However, if I enter the IP of the site in my hosts file, the site works perfectly (logs the user in without the additional challenge).
I guess I have two questions.
1) Why does the hosts entry have this affect?
2) How can I get the site to succeed without a) forcing everyone to edit their hosts file or b) the site challenging them and failing to log them in?
EDIT: I checked, and we do have our DNS server set up to point those URLs to the correct servers. That's why pinging the URL displays the right IP. However, it appears that in addition to having that DNS entry, we also have to have the hosts file entry for the site to work.
You probably are having an issue with Kerberos authentication.
Since you're using a url of Site.DomainName.com, I'm assuming DomainName.com is your AD's name also.
On the server that's running IIS, copy SetSPN.EXE from the resource kit tools and run the following:
setspn -A http/site.domainname.com IISServerName
Where SITE is your URL and IISServerName is the name of the server.
This sure sounds like a dns problem. Does the dns server know about the hostname you are using? Sounds like the dns server does not know the forward lookup (hostname to ip) for the host you are trying to connect to.
We recently set up an intranet site with windows authentication here. The network guys setup a group policy and pushed changed to IE and Firefox.
For IE, it added the site to "Intranet Sites" and for Firefox it modified the configuration file so that our intranet..com would be trusted.
So... we got it to work. Here's what happened.
While looking around at the DNS Manager on test.DOMAINNAME.com, my coworker noticed that a different site on the same server was set up as a "Host (A)" entry, whereas the site we were working on was set up as an "Alias (CNAME)" entry. Several other sites on that computer were also set up as Alias entries, and he mentioned that the one site with the Host entry was "rock-solid", and he'd had sporadic issues with at least one other site that was set up as an Alias.
We talked to the AD/DNS admin, and as a test, he switched our entries from Alias to Host, and once we cleared our local DNS caches, it worked perfectly (without requiring entries in our .hosts file).
So the question still sorta stands. This was a Win2k3 box serving as one of three internal DNS servers, and making this modification fixed our problem. If anyone can add any additional information, we'd be very grateful, but in the meantime, we're debating going back and fixing all our other sites.