The publisher could not be verified???

  • Thread starter Thread starter Jim Horvath
  • Start date Start date
J

Jim Horvath

I have installed a client/server application on two WinXP Pro SP2
machines. The client machine maps a network drive to a shared folder on
the server and runs executable programs from the mapped folder.

Everything was fine while I tested the installation with both client and
server on the same subnet, but when I moved the client to a different
physical location (still in the same building, but across a router on a
different subnet) I began getting a security warning message upon
starting the program:

"The publisher could not be verified. Are you sure you want to run this
software?". [RUN] [CANCEL]

I don't want this warning confusing the users. This is not downloaded
software, it was installed from a CD and is fully licensed.

After searching the web, I've found several ways to bypass the warning.
These are:

1. Use the group policy editor to put .exe files in the low-risk category.
2. In Internet Explorer options, change the Internet Zone settings to
allow .exe files to run.
3. Run the program from a command line, i.e. "cmd /c X:application.exe"

I have verified that all three of these work, but #1 and #2 clearly put
the machine at risk and are therefore unacceptable. #3 is a clever
workaround, but it leaves a command window cluttering the desktop until
the application exits, and I suspect that eventually Microsoft will kill
this method in some future Windows Update (i.e. running exe's from a
command window bypasses security checks).

My question is why does WinXP consider the mapped drive to be in the
Internet Zone? So far I have found no way to convince it otherwise.

I have tried adding the server IP address to the list of trusted
websites in Internet Explorer. I tried explicitly listing it in the
"Local Intranet" advanced settings. Neither of these worked. I checked
all executable files on the server for the alternate data stream
"Zone.Identifier". I found no ADS on any of the files.

Can anybody tell me what I am missing?

Jim Horvath
jhorvath at keithley (the standard commercial suffix)
 
What is the exact statement used on the client to map the drive,
please?

J Wolfgang Goerlich
 
What is the exact statement used on the client to map the drive,
please?

J Wolfgang Goerlich
Click to expand...

It is mapped with Windows Explorer Tools -> Map Network Drive...

Our network (which I do not administer) does not use WINS, and so I must
enter the IP address of the server when mapping from a different subnet,
for example:

\\192.168.0.17\sharename

I can also map from a command line:

net use X: \\192.168.0.17\sharename

When I try to enter this network share explicitly as a Local Intranet
sites (in Internet Explorer Tool -> Options Security tab), it appears as
"file://192.168.0.17". However, this "trusted" setting has no effect on
the security warning when I try to start applications from the server.

Jim H
 
Jim said:
It is mapped with Windows Explorer Tools -> Map Network Drive...

Our network (which I do not administer) does not use WINS, and so I must
enter the IP address of the server when mapping from a different subnet,
for example:

\\192.168.0.17\sharename
Click to expand...

While writing the above, it occurred to me to try putting an entry in
LMHOSTS so that I could refer to the server by name. I did so, and after
rebooting and mapping the drive as \\servername\sharename, the security
warning message disappeared.

I don't fully understand why this should work when the other things I've
tried failed (does this mean that ANY server in LMHOSTS is considered
Intranet Zone?) but at least for now I have a solution.

See my original post for a full description of the problem.

Jim H.
 
Hello Jim H.,

You got it. By default, all computers in the local LAN are assumed to
be in the Intranet Zone ("Include all network paths (UNC)"). The IP
address is not recognized by this filter. The computer name -- found
with either via Lmhosts/Wins or Hosts/Dns -- is and therefore the
security warning goes away.

If the server and the workstation are in the same domain, then the
name resolution should be over Dns. I know you mentioned that you do
not administer the domain. You might pass this along, however, to the
administrator. A well-oiled Dns infrastructure will avoid all sorts of
odd errors.

Regards,

J Wolfgang Goerlich
 
Back
Top