How Can I Add Local and Network Drive Letters to MSIE Trusted Sites Security Zone?

[Will]

I'm looking for the correct syntax for adding two types of drive letters to
the Internet Explorer Trusted Sites security zone.

1) A local file system, such as e:\

2) A network share that is accessed by a drive letter, such as when mapped
to z:\ through net use z: \\server\sharename

I see that the Trusted Sites list can take a URL that includes the directive
file:\\ directive. References such as this one work:

file:\\server\sharename

But unfortunately MSIE is too dumb to understand that a drive letter can
reference the same authorized share, so attempts to execute application
shortcuts on the desktop that point to an application on the share through
z: (for example) fail the MSIE security checks.

I see from the command line that I can reference a drive letter through the
obscure syntax:

dir \\.\e:\

but I did not find a way to get this syntax accepted in MSIE through file:\\

This doesn't appear to be well documented, and adding a local or network
share into a Trusted Sites zone has to be a very basic activity. Otherwise
how can you authorize execution of applications from a trusted file share?!

--
Will

 

[jwgoerlich@gmail.com]

Hello Will,

I am curious, why would you add local and network drive letters into
Trusted Sites? Content on local drives are automatically in the My
Computer zone. (This is normally hidden and can be displayed, see link
below). Content on network drives are automatically in the Intranet
zone. Is there something that these two zones are not providing that
Trusted zones would provide?

Regards,

J Wolfgang Goerlich


Microsoft Article 315933, How to Enable the My Computer Security Zone
in Internet Options
http://support.microsoft.com/kb/315933

On Oct 15, 12:40 am, "Will" <westes-...@noemail.nospam> wrote:
> This doesn't appear to be well documented, and adding a local or network
> share into a Trusted Sites zone has to be a very basic activity. Otherwise
> how can you authorize execution of applications from a trusted file share?!
>
> --
> Will

 

[Will]

Sorry, I did mean Intranet, but the principal difficult is the same for both
Intranet and Trusted Sites. On the Intranet Advanced tab, you get a place
you can add URLs in a list. The same problem I am citing applies to that
list.

To repeat the original question: How can I get MSIE 7 to authorize the
execution of applications from a file share that is referenced by a drive
letter, such as when a share is mapped to z:\ through net use z:
\\server\sharename.

I can add this to the Intranet Advanced sites list:

file:\\server\sharename

But if you have this referenced by the drive letter Z:, MSIE 7 cannot figure
out that z: should also be treated as part of Intranet zone. Attempts to
execute an application shortcut on the desktop that points to an application
on the share through z: (for example) fail the MSIE security checks.

You could almost make an argument that this behavior is a bug. Once I
authorize executions of programs on an explicit share via
file:\\server\sharename, MSIE should not care whether that path is aliased
to a drive letter or not. MSIE should see the explicit server\share file
path and a file path that uses z: as being identical.

--
Will

<jwgoerlich@gmail.com> wrote in message
news:1192559415.815224.115810@e34g2000pro.googlegroups.com...
> Hello Will,
>
> I am curious, why would you add local and network drive letters into
> Trusted Sites? Content on local drives are automatically in the My
> Computer zone. (This is normally hidden and can be displayed, see link
> below). Content on network drives are automatically in the Intranet
> zone. Is there something that these two zones are not providing that
> Trusted zones would provide?
>
> Regards,
>
> J Wolfgang Goerlich
>
>
> Microsoft Article 315933, How to Enable the My Computer Security Zone
> in Internet Options
> http://support.microsoft.com/kb/315933
>
> On Oct 15, 12:40 am, "Will" <westes-...@noemail.nospam> wrote:
> > This doesn't appear to be well documented, and adding a local or network
> > share into a Trusted Sites zone has to be a very basic activity.
Otherwise
> > how can you authorize execution of applications from a trusted file
share?!
> >
> > --
> > Will
>
>

 

[jwgoerlich@gmail.com]

Let us suppose the server name is FS. In Internet Explorer, you add
file://fs to the Local Intranet sites list. It should now evaluate FS
as Local Intranet, whether or not you access it over mapped drive or
straight UNC. Now if you have a large environment, you might map all
drives using FQDNs. Say it is Fs.domain.local. Add file://*.domain.local
to the Intranet zone. This then adds all servers in the domain into
the Intranet zone.

J Wolfgang Goerlich

On Oct 16, 3:55 pm, "Will" <westes-...@noemail.nospam> wrote:
> Sorry, I did mean Intranet, but the principal difficult is the same for both
> Intranet and Trusted Sites. On the Intranet Advanced tab, you get a place
> you can add URLs in a list. The same problem I am citing applies to that
> list.
>
> To repeat the original question: How can I get MSIE 7 to authorize the
> execution of applications from a file share that is referenced by a drive
> letter, such as when a share is mapped to z:\ through net use z:
> \\server\sharename.
>
> I can add this to the Intranet Advanced sites list:
>
> file:\\server\sharename
>
> But if you have this referenced by the drive letter Z:, MSIE 7 cannot figure
> out that z: should also be treated as part of Intranet zone. Attempts to
> execute an application shortcut on the desktop that points to an application
> on the share through z: (for example) fail the MSIE security checks.
>
> You could almost make an argument that this behavior is a bug. Once I
> authorize executions of programs on an explicit share via
> file:\\server\sharename, MSIE should not care whether that path is aliased
> to a drive letter or not. MSIE should see the explicit server\share file
> path and a file path that uses z: as being identical.
>
> --
> Will

 

[jwgoerlich@gmail.com]

Hello Will,

As a side note, Internet Explorer 6/7 have checkboxes to Include all
network paths (UNCs). I generally find this works properly in most
environments. Internet Explorer Enhanced Security Configuration
removes that checkbox.

The following whitepaper discusses some strategies for managing the
UNC paths in the Intranet zone. It might give you some ideas, whether
you have Enhanced Security enabled or not.

Managing Internet Explorer Enhanced Security Configuration
http://www.microsoft.com/downloads/...6C-E2E1-4960-99BB-9757F7E9E31B&displaylang=en

Regards,

J Wolfgang Goerlich

On Oct 17, 10:25 am, jwgoerl...@gmail.com wrote:
> Let us suppose the server name is FS. In Internet Explorer, you add
> file://fs to the Local Intranet sites list. It should now evaluate FS
> as Local Intranet, whether or not you access it over mapped drive or
> straight UNC. Now if you have a large environment, you might map all
> drives using FQDNs. Say it is Fs.domain.local. Add file://*.domain.local
> to the Intranet zone. This then adds all servers in the domain into
> the Intranet zone.
>
> J Wolfgang Goerlich
>
> On Oct 16, 3:55 pm, "Will" <westes-...@noemail.nospam> wrote:
>
>
>
> > Sorry, I did mean Intranet, but the principal difficult is the same for both
> > Intranet and Trusted Sites. On the Intranet Advanced tab, you get a place
> > you can add URLs in a list. The same problem I am citing applies to that
> > list.
>
> > To repeat the original question: How can I get MSIE 7 to authorize the
> > execution of applications from a file share that is referenced by a drive
> > letter, such as when a share is mapped to z:\ through net use z:
> > \\server\sharename.
>
> > I can add this to the Intranet Advanced sites list:
>
> > file:\\server\sharename
>
> > But if you have this referenced by the drive letter Z:, MSIE 7 cannot figure
> > out that z: should also be treated as part of Intranet zone. Attempts to
> > execute an application shortcut on the desktop that points to an application
> > on the share through z: (for example) fail the MSIE security checks.
>
> > You could almost make an argument that this behavior is a bug. Once I
> > authorize executions of programs on an explicit share via
> > file:\\server\sharename, MSIE should not care whether that path is aliased
> > to a drive letter or not. MSIE should see the explicit server\share file
> > path and a file path that uses z: as being identical.
>
> > --
> > Will- Hide quoted text -
>
> - Show quoted text -

 

[Will]

<jwgoerlich@gmail.com> wrote in message
news:1192631129.065307.202670@k35g2000prh.googlegroups.com...
> Let us suppose the server name is FS. In Internet Explorer, you add
> file://fs to the Local Intranet sites list. It should now evaluate FS
> as Local Intranet, whether or not you access it over mapped drive or
> straight UNC. Now if you have a large environment, you might map all
> drives using FQDNs. Say it is Fs.domain.local. Add file://*.domain.local
> to the Intranet zone. This then adds all servers in the domain into
> the Intranet zone.

Yes, you would think that would work. But what I was trying to report was
that we did add both:

file://fs
file://fs.fqdn.com

and the security settings are NOT working against mapped drives that use
those servers.

--
Will

 

[jwgoerlich@gmail.com]

Ok, let's get back to basics because this is something that I have not
seen. What is the OS and IE version on the client machines? What is
the OS on the file server? How are you determining what security zone
is being used.

J Wolfgang Goerlich

On Oct 17, 3:53 pm, "Will" <westes-...@noemail.nospam> wrote:
> Yes, you would think that would work. But what I was trying to report was
> that we did add both:
>
> file://fs
> file://fs.fqdn.com
>
> and the security settings are NOT working against mapped drives that use
> those servers.
>
> --
> Will

 

[Will]

<jwgoerlich@gmail.com> wrote in message
news:1192653071.762723.68360@k35g2000prh.googlegroups.com...
> Ok, let's get back to basics because this is something that I have not
> seen. What is the OS and IE version on the client machines? What is
> the OS on the file server? How are you determining what security zone
> is being used.

OS is Windows 2003 Web Edition, which is a member server in a domain in a
one-domain forest. Browser is MSIE 7, and all Windows updates are applied
to OS and MSIE.

Security Zone is accessed by:

1) Double click on Internet icon on bottom right corner of open MSIE 7
window or desktop Explorer window. Optionally, in MSIE 7, go to Tools |
Options, and select Security tab.

2) Select Local intranet security zone.

3) Press Sites button and Advanced interface.

4) Add the following into Websites list:

file://fs
file://fs.fqdn.com
file://192.168.99.99

where 192.168.99.99 is the IP address of the file server.

I think I have located the problem, and I think this is a clear bug. If
you define the mapped file share with:

net use z: \\192.168.99.99\sharename

the drive will map correctly, but MSIE 7 is NOT able to process the security
zone information properly using the IP address directly. If you now change
the above to reference either NetBIOS or FQDN, the security zone information
will process correctly when accessing a program from Explorer using the
drive letter mapping.

The above should contain enough information for you to duplicate the bug,
but I would caution you to not redefine any existing drive mappings,
because in my testing just now I saw some kind of caching of the original
definition that affected the test result. Map your file server's IP to a
*NEW* drive letter, then try to execute a program using that drive letter,
and the security zone will show as Internet even as you browse the drive's
file tree in Explorer.

I cannot think of any reason why this behavior would be a feature or desired
behavior, particularly not when I am adding file:// with an explicit IP
address and it still doesn't take the security zone settings for that IP.

--
Will


> On Oct 17, 3:53 pm, "Will" <westes-...@noemail.nospam> wrote:
>> Yes, you would think that would work. But what I was trying to report
>> was
>> that we did add both:
>>
>> file://fs
>> file://fs.fqdn.com
>>
>> and the security settings are NOT working against mapped drives that use
>> those servers.
>>
>> --
>> Will

 

[Will]

It appears that this is the article that discusses the problem I am seeing:

http://support.microsoft.com/kb/303650

With reference to IP addresses in the UNC, it's extremely unclear after
reading that article when does it work, not work, can you work around it, or
not. All in all, a complete mess.

--
Will

<jwgoerlich@gmail.com> wrote in message
news:1192653071.762723.68360@k35g2000prh.googlegroups.com...
> Ok, let's get back to basics because this is something that I have not
> seen. What is the OS and IE version on the client machines? What is
> the OS on the file server? How are you determining what security zone
> is being used.
>
> J Wolfgang Goerlich
>
> On Oct 17, 3:53 pm, "Will" <westes-...@noemail.nospam> wrote:
>> Yes, you would think that would work. But what I was trying to report
>> was
>> that we did add both:
>>
>> file://fs
>> file://fs.fqdn.com
>>
>> and the security settings are NOT working against mapped drives that use
>> those servers.
>>
>> --
>> Will

 

[jwgoerlich@gmail.com]

Hello Will,

Duplicated. Windows 2003 Standard Server using IE 7. My test network
as 10.5.0.0/16.

I added the following into IE's Intranet Zone the site file://10.5.*.*.
If I browse to the UNC \\10.5.13.32\Share using Windows Explorer, the
status bar shows it as Local Intranet. I then map the share (net use
z: \\10.5.13.32\Share). Browse to Z:\ using Windows Explorer, the
status bar shows it as Internet.

This happens whether or not Internet Explorer Enhanced Security
Configuration is installed.

Very interesting. I will do some more digging on this.

J Wolfgang Goerlich

On Oct 17, 10:45 pm, "Will" <westes-...@noemail.nospam> wrote:
> It appears that this is the article that discusses the problem I am seeing:
>
> http://support.microsoft.com/kb/303650
>
> With reference to IP addresses in the UNC, it's extremely unclear after
> reading that article when does it work, not work, can you work around it, or
> not. All in all, a complete mess.
>
> --
> Will
>
> <jwgoerl...@gmail.com> wrote in message
>
> news:1192653071.762723.68360@k35g2000prh.googlegroups.com...
>
>
>
> > Ok, let's get back to basics because this is something that I have not
> > seen. What is the OS and IE version on the client machines? What is
> > the OS on the file server? How are you determining what security zone
> > is being used.
>
> > J Wolfgang Goerlich
>
> > On Oct 17, 3:53 pm, "Will" <westes-...@noemail.nospam> wrote:
> >> Yes, you would think that would work. But what I was trying to report
> >> was
> >> that we did add both:
>
> >> file://fs
> >> file://fs.fqdn.com
>
> >> and the security settings are NOT working against mapped drives that use
> >> those servers.
>
> >> --
> >> Will- Hide quoted text -
>
> - Show quoted text -

 

[jwgoerlich@gmail.com]

Microsoft has a hotfix.

Microsoft Article 929798, Windows Internet Explorer 7 may not
correctly recognize the zone to which a network resource belongs when
you access the resource by using a mapped drive
http://support.microsoft.com/kb/929798

Applies To:
- Windows Internet Explorer 7 in Windows Vista
- Windows Internet Explorer 7 for Windows Server 2003
- Windows Internet Explorer 7 for Windows XP

On Oct 18, 7:49 am, jwgoerl...@gmail.com wrote:
> Hello Will,
>
> Duplicated. Windows 2003 Standard Server using IE 7. My test network
> as 10.5.0.0/16.
>
> I added the following into IE's Intranet Zone the site file://10.5.*.*.
> If I browse to the UNC \\10.5.13.32\Share using Windows Explorer, the
> status bar shows it as Local Intranet. I then map the share (net use
> z: \\10.5.13.32\Share). Browse to Z:\ using Windows Explorer, the
> status bar shows it as Internet.
>
> This happens whether or not Internet Explorer Enhanced Security
> Configuration is installed.
>
> Very interesting. I will do some more digging on this.
>
> J Wolfgang Goerlich
>

 

[Will]

<jwgoerlich@gmail.com> wrote in message
news:1192708604.248260.172850@v29g2000prd.googlegroups.com...
> Microsoft has a hotfix.
>
> Microsoft Article 929798, Windows Internet Explorer 7 may not
> correctly recognize the zone to which a network resource belongs when
> you access the resource by using a mapped drive
> http://support.microsoft.com/kb/929798
>
> Applies To:
> - Windows Internet Explorer 7 in Windows Vista
> - Windows Internet Explorer 7 for Windows Server 2003
> - Windows Internet Explorer 7 for Windows XP

Is there an intention to roll out this fix in the next service pack?

If I install it and still find some manifestation or trace of the problem
remains, is there a process for me to get that information to development so
they might have an opportunity to resolve that before the service pack is
finalized? Or probably at this point the fix is frozen?

--
Will


> On Oct 18, 7:49 am, jwgoerl...@gmail.com wrote:
> > Hello Will,
> >
> > Duplicated. Windows 2003 Standard Server using IE 7. My test network
> > as 10.5.0.0/16.
> >
> > I added the following into IE's Intranet Zone the site file://10.5.*.*.
> > If I browse to the UNC \\10.5.13.32\Share using Windows Explorer, the
> > status bar shows it as Local Intranet. I then map the share (net use
> > z: \\10.5.13.32\Share). Browse to Z:\ using Windows Explorer, the
> > status bar shows it as Internet.
> >
> > This happens whether or not Internet Explorer Enhanced Security
> > Configuration is installed.
> >
> > Very interesting. I will do some more digging on this.
> >
> > J Wolfgang Goerlich

 

[Will]

<jwgoerlich@gmail.com> wrote in message
news:1192708197.496171.183520@q3g2000prf.googlegroups.com...
> Hello Will,
>
> Duplicated. Windows 2003 Standard Server using IE 7. My test network
> as 10.5.0.0/16.
>
> I added the following into IE's Intranet Zone the site file://10.5.*.*.
> If I browse to the UNC \\10.5.13.32\Share using Windows Explorer, the
> status bar shows it as Local Intranet. I then map the share (net use
> z: \\10.5.13.32\Share). Browse to Z:\ using Windows Explorer, the
> status bar shows it as Internet.
>
> This happens whether or not Internet Explorer Enhanced Security
> Configuration is installed.
>
> Very interesting. I will do some more digging on this.

By the way, the reason this problem was so important to us is that we
discovered that shares mapped to IPs or the FQDN are *much* faster than
shares resolved to NetBIOS names. The client side code is going through
some additional paths for name resolution when you use the shorter NetBIOS
name. On our older Windows 2000 boxes the performance was sometimes
awful. Using FQDN in the drive mapping performance is great. Using the
IP in the drive mapping performance is also great, and the bonus for using
IP is that when domain controller is rebooting the client is still able to
reach the file server even when the DNS client cache is expired.

--
Will


> J Wolfgang Goerlich
>
> On Oct 17, 10:45 pm, "Will" <westes-...@noemail.nospam> wrote:
> > It appears that this is the article that discusses the problem I am
seeing:
> >
> > http://support.microsoft.com/kb/303650
> >
> > With reference to IP addresses in the UNC, it's extremely unclear after
> > reading that article when does it work, not work, can you work around
it, or
> > not. All in all, a complete mess.
> >
> > --
> > Will
> >
> > <jwgoerl...@gmail.com> wrote in message
> >
> > news:1192653071.762723.68360@k35g2000prh.googlegroups.com...
> >
> >
> >
> > > Ok, let's get back to basics because this is something that I have not
> > > seen. What is the OS and IE version on the client machines? What is
> > > the OS on the file server? How are you determining what security zone
> > > is being used.
> >
> > > J Wolfgang Goerlich
> >
> > > On Oct 17, 3:53 pm, "Will" <westes-...@noemail.nospam> wrote:
> > >> Yes, you would think that would work. But what I was trying to
report
> > >> was
> > >> that we did add both:
> >
> > >> file://fs
> > >> file://fs.fqdn.com
> >
> > >> and the security settings are NOT working against mapped drives that
use
> > >> those servers.
> >
> > >> --
> > >> Will- Hide quoted text -
> >
> > - Show quoted text -

 

[jwgoerlich@gmail.com]

Hello Will,

> Is there an intention to roll out this fix in the next service pack?

Microsoft's really the one to answer these questions. Given the patch
is relatively new and that it replaces Urlmon.dll, I wager KB929798
will make its way into a patch Tuesday cumulative IE update.

> By the way, the reason this problem was so important to us is that we
> discovered that shares mapped to IPs or the FQDN are *much* faster than
> shares resolved to NetBIOS names.

Well worth knowing, thank you. I'll keep that in my bag of performance-
tuning tricks.

Enjoy the weekend,

J Wolfgang Goerlich