Compartir a través de

When is the Local Intranet not the Local Intranet?

  • Artículo

When it's in another zone, of course.

One of the recommendations we give for setting policy on VSTO projects is to sign your assembly (either with an Authenticode certificate or a strongname) and then trust that key only for a specific computer (eg, your deployment server) or for a specific Zone (typically My Computer or Local Intranet). So people go ahead and they do this, and sometimes it works and sometimes it doesn't. They scratch their head for a while, and then they e-mail me and ask what's up :-)

Almost always, the problem is that although the person thinks the computer is in the Local Intranet zone, IE has a different opinion on the matter for one of two reasons:

1) You have previously added the web site to the "Trusted Zone" for some particular reason

2) You are using a dotted IP address (\192.168.1.1) or a FQDN (\computername.company.com) name instead of a NETBIOS name (\computername)

The first one fails for obvious reasons -- you moved the site from the Local Intranet Zone to the Trusted Sites Zone, and the CLR is simply obeying your command. Fixing it is as easy as moving the site back to Local Intranet (if that makes sense for you) or changing your policy to trust the key inside the Trusted Sites Zone instead.

The second one is a bit less obvious. Basically (and I'm by no means a network protocol expert, so feel free correct me if I get the details wrong) IE knows that NETBIOS names (names without dots in them) can't be routed across the internet, so if it sees a name without a dot it knows it is a local name. If IE sees a name with dots in it (whether numeric or DNS) then it assumes it is coming from across the internet, and so it falls into the Internet Zone. One tricky thing here is that since an IP address is really just four bytes, you can represent an IP address as a single 32-bit number such as \12345678, and this could indeed come from across the internet. So there is a special check to see if it is this kind of address in addition to the simple "does it have dots in it" check.

Fixing this is also quite easy; just add the computer's address to your Local Intranet Zone by going to Tools -> Internet Options -> Security -> Local Intranet Zone -> Sites -> Advanced and typing it in.

Note that the cause of this problem (but not the solution) is easily deducible by following my previous debugging tip to find out how the CLR is resolving your policy rules.

Comments

  • Anonymous
    July 15, 2004
    Thanks Peter for answering that email the other day... it worked beautifully once I added the IP. I ended up having an additional problem with a win exe that was using one of the assemblies located in that directory...said assembly was shared by both the VSTO assemblies and it... but I actually ended up figuring out my own security problem and thought you'd be quite proud of me (I had to use codebase to point it to the proper location).
  • Anonymous
    July 16, 2004
    Heh, you're not the only one who asks ;-)
  • Anonymous
    July 19, 2004
    thanks for this.
    if this is the solution for one machine:

    'Fixing this is also quite easy; just add the computer's address to your Local Intranet Zone by going to Tools -> Internet Options -> Security -> Local Intranet Zone -> Sites -> Advanced and typing it in.'

    Is there a way to distribute this setting to a mixed environment NT/XP so that all machines add the site to the Local Intranet Zone?

    Thanks
    Jon
  • Anonymous
    July 19, 2004
    The registry layout for the zones is listed at:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;182569

    There is more information on this problem at:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;303650

    You can use a logon script or SMS or (probably) Group Policy to push out these changes.
  • Anonymous
    March 05, 2006
    I have more money than bill gates coz im related to harnek who won the lottery!