• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1283
  • Last Modified:

Intranet Zone: authentication not possible

Situation:

Datacenter:
2008 AD
IIS 7
Website with 'Windows Authentication' enabled (e.g. https://intranet.fqdn.something)

Clients:
HP 6730b laptops
Domain member
Windows XP SP3
IE 7
Intranet zone: https://intranet.fqdn.something

The clients access the servers through a static IPSEC connection while in the office, and through a Citrix Secure Access Client while 'on the road'.

Problem:
When the clients try to access the Intranet website while on the road (e.g. at home) when they're not connected through the VPN client, they cannot access the Intranet website:

"Cannot find server" is displayed in IE.

The Evenlog on the client show the reason:
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
"The Security System detected an attempted downgrade attack for server HTTP/intranet.fqdn.something.  The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request.  (0xc000005e)".

The failure reason itself is correct: when the client's not connected through VPN there is no server (=domain controller) to service the logon request. It looks like this behaviour is related to Security Bulletin MS04-011: http://support.microsoft.com/default.aspx/kb/891559/en-us 

The problem I'm facing is that IE does not offer an alternative way to authenticate the user (for example a password prompt). When I remove the URL from the Intranet zone in IE, the browser correctly displays a username/password prompt.
The client however likes to have 'single sign-on', which works only when the URL is placed in the Intranet zone.

Thanks in advance for your feedback!
0
pistole
Asked:
pistole
1 Solution
 
grayeCommented:
Pardon my confusion, but isn't that the way it's supposed to work?
If you were at home, and NOT using VPN, then you shouldn't have access to any Intranet website
0
 
pistoleAuthor Commented:
Hi graye,

thanks for your response. I'm not 100% sure whether that behaviour is 'by design' in IE, if you have a link to a Microsoft document that clearly states it, I would be pleased.
0
 
tyronenoelCommented:
when on the road you cant access intranet. the reason for this is that your computer needs to be on a local network with a local dns server to access the site. the vpn creates the illusion that you are on the network when in fact you are not. when you are not on the network and not on a VPN internet browsers will look at the DNS server allocated to them by each individuals isp and find no records. thus giving you the error you receive. The only way to get around this is to turn your intranet into a website and apply for a domain. the downside is that it is then accessible by members of the public
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
pistoleAuthor Commented:
Tyronenoel;

it's an (externally available) extranet with a public FQDN. The problem is pure authentication: when I remove the URL from the Intranet Zone, the browser shows a username+password pop-up, and all is well.
0
 
tyronenoelCommented:
oh ok well then sorted :)
0
 
pistoleAuthor Commented:
Well, not really, since my customer would like to use 'single sign-on' where possible...

I already read something about Kerberos, delegation, etc (see: http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx) so I guess my solution should be found there. To be continued?
0
 
tyronenoelCommented:
where have you set the computer to look up the ip address when on a local network/intranet?have you set it up in the "hosts" file or on your local dns server??
0
 
pistoleAuthor Commented:
Hi,

sorry, I guess I didn't explain well the first time.
The "intranet" resides on a server that's accessible via a public ip-addres. Resolving works fine.

The problem is that when the clients are not connected through VPN, they cannot authenticate (because domain controller is not reachable), and give up.

Clients can be anywhere: at home, at another client's office, mobile, etc.
0
 
tyronenoelCommented:
ok so when the staff are in your office they use the same FQDN?
0
 
pistoleAuthor Commented:
That's correct. And the site will open up, automatically authenticating using the credentials with which the staff logs into the laptop.

I managed to reproduce this exact behaviour in a different environment, also using IIS7.
0
 
tyronenoelCommented:
ok like you said it just cannot connect to the domain controller. the other option is to give the domain controller a FQDN and set that up in each machine as the domain controller but i do not suggest this as it will open up to many security risks and create a very slow network as everything has to be done via the internet...... i Think the best thing is to keep the vpn running and work like that
0
 
pistoleAuthor Commented:
tyronenoel,

thanks for thinking along, but this is not a real solution to the problem.
Next week I'll read all articles about Kerberos and delegation* -- I expect (and hope!) to find a solution there.

I will of course update this topic.

* http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx
0
 
tyronenoelCommented:
cool thanks let me know as i am also interested to set our intranet to be publically available
0
 
pistoleAuthor Commented:
Well, it took quite some time to find a relatively simple solution: I turned off the feature 'Enable Integrated Windows Authentication' in Internet Explorer,  which basically means that IE will not try to use Kerberos based authentication (at all). It will then fall back to NTLM authentication, which works perfectly across the internet.

Thanks all for your time :)
0
 
agileblowfishCommented:
pistoles solution worked for me as well.  This is in Internet Options in the Advanced tab.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now