What Would Deactivate Hosts File?

On one of our Windows 2003 servers, the HOSTS file is not active. No
changes made to the c:\windows\system32\drivers\etc\hosts file are ever
active, even after a reboot. Is there some registry setting or group
policy that would be deactivating that feature?

--
Will

Why do you want to use HOSTS? By default the server search for the HOSTS first. Have you saved the hosts without extension?

Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
"Will" <westes-(E-Mail Removed)> wrote in message news:(E-Mail Removed) ...
On one of our Windows 2003 servers, the HOSTS file is not active. No
changes made to the c:\windows\system32\drivers\etc\hosts file are ever
active, even after a reboot. Is there some registry setting or group
policy that would be deactivating that feature?

--
Will

"Robert L [MVP - Networking]" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
<Why do you want to use HOSTS? By default the server search for the HOSTS
first. Have you saved the hosts without extension?

The HOSTS file is being used in our case for program testing, to redirect
some code between different versions of a server.

I have used HOSTS files for years, and I know how to use it. I would never
give it an extension. It already existed on the system without any
extension, and I modified it in place.

On the system I inquired about, it's like there is a group policy or
registry setting in effect that is disabling it entirely.

--
Will



"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
On one of our Windows 2003 servers, the HOSTS file is not active. No
changes made to the c:\windows\system32\drivers\etc\hosts file are ever
active, even after a reboot. Is there some registry setting or group
policy that would be deactivating that feature?

--
Will

Will,

Have you flushed your local DNS cache to make sure that your server is
still not resolving to that rather than to the entries in the HOSTS file?

What happens if you then put a bogus DNS server into your NIC's DNS
properties, so that there's no way that another server could provide the
name resolution to override the HOSTS entries?

Yours,
Brad Dinerman


_______________________________________________
Bradley J. Dinerman, MVP - Windows Server Networking
President, New England Information Security Group
http://www.neisg.org





Will wrote:
> On one of our Windows 2003 servers, the HOSTS file is not active. No
> changes made to the c:\windows\system32\drivers\etc\hosts file are ever
> active, even after a reboot. Is there some registry setting or group
> policy that would be deactivating that feature?
>

I don't know about the policy but you could check the ntfs permissions
to make sure they didn't get changed somehow.

Joe


Brad Dinerman [MVP - Windows Server Networking] wrote:
> Will,
>
> Have you flushed your local DNS cache to make sure that your server is
> still not resolving to that rather than to the entries in the HOSTS file?
>
> What happens if you then put a bogus DNS server into your NIC's DNS
> properties, so that there's no way that another server could provide the
> name resolution to override the HOSTS entries?
>
> Yours,
> Brad Dinerman
>
>
> _______________________________________________
> Bradley J. Dinerman, MVP - Windows Server Networking
> President, New England Information Security Group
> http://www.neisg.org
>
>
>
>
>
> Will wrote:
> > On one of our Windows 2003 servers, the HOSTS file is not active. No
> > changes made to the c:\windows\system32\drivers\etc\hosts file are ever
> > active, even after a reboot. Is there some registry setting or group
> > policy that would be deactivating that feature?
> >

"Brad Dinerman [MVP - Windows Server Networking]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> Have you flushed your local DNS cache to make sure that your server is
> still not resolving to that rather than to the entries in the HOSTS file?

Yes, tried that, and it did not affect the result. Used ipconfig /flushdns
to do it.


> What happens if you then put a bogus DNS server into your NIC's DNS
> properties, so that there's no way that another server could provide the
> name resolution to override the HOSTS entries?

No DNS resolves when I do this, including the entry in the hosts file.

I'm thinking at this point that maybe we have a permissions issue. What
service would be using the hosts file? I guess it must be SYSTEM since
this is a driver in the kernel that implements TCP?

In the short term, I have had to resort to some outrageous hack to give the
programmer the ability to switch between two systems with a single hostname,
and I very much need to get the original functionality with HOSTS file back.

--
Will

I solved this problem, and I'll post how for posterity, but I would be
interested in anyone's theories about why this works. It almost looks like
a bug or misfeature to me.

We had modified the default ACL on c:\windows\system32\drivers\etc to
exclude the Users group. If you give Users read and execute access, and
then reboot (it will not work until you reboot), then hosts mysteriously
starts working. Note that before and after the reboot I am logged in as
local administrator. And the folder always had Full Control access for
Administrators and SYSTEM, so it cannot be the case that giving Users access
suddenly gave applications in my user context access, since they must have
had read access to HOSTS before the ACL change.

What surprises me about this is that I would have thought HOSTS was
implemented in the driver or somewhere in the kernel, not in each individual
user application. If that is the case, then why would read access to the
Users group affect this feature, which should be implemented by a SYSTEM
entity? It's almost like the code that runs at SYSTEM level did an ACL
check, and after it saw that Users did not have access, it bypassed the
feature. That seems like wrong behavior.

Note that the local Users group did NOT have Authenticated Users in it, just
Domain Users.

--
Will


"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On one of our Windows 2003 servers, the HOSTS file is not active. No
> changes made to the c:\windows\system32\drivers\etc\hosts file are ever
> active, even after a reboot. Is there some registry setting or group
> policy that would be deactivating that feature?
>
> --
> Will
>
>

In my default install of Windows 2003 server the permissions on the
hosts file are

Administrators: Full Control
System: Full Control
Server Operaters: everything short of Full Control
Authenticated Users: Read & Excecute and Read
The file is owned by the administrators group.

Joe


Will wrote:
> I solved this problem, and I'll post how for posterity, but I would be
> interested in anyone's theories about why this works. It almost looks like
> a bug or misfeature to me.
>
> We had modified the default ACL on c:\windows\system32\drivers\etc to
> exclude the Users group. If you give Users read and execute access, and
> then reboot (it will not work until you reboot), then hosts mysteriously
> starts working. Note that before and after the reboot I am logged in as
> local administrator. And the folder always had Full Control access for
> Administrators and SYSTEM, so it cannot be the case that giving Users access
> suddenly gave applications in my user context access, since they must have
> had read access to HOSTS before the ACL change.
>
> What surprises me about this is that I would have thought HOSTS was
> implemented in the driver or somewhere in the kernel, not in each individual
> user application. If that is the case, then why would read access to the
> Users group affect this feature, which should be implemented by a SYSTEM
> entity? It's almost like the code that runs at SYSTEM level did an ACL
> check, and after it saw that Users did not have access, it bypassed the
> feature. That seems like wrong behavior.
>
> Note that the local Users group did NOT have Authenticated Users in it, just
> Domain Users.
>
> --
> Will
>
>
> "Will" <westes-(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ...
> > On one of our Windows 2003 servers, the HOSTS file is not active. No
> > changes made to the c:\windows\system32\drivers\etc\hosts file are ever
> > active, even after a reboot. Is there some registry setting or group
> > policy that would be deactivating that feature?
> >
> > --
> > Will
> >
> >

"CoolHandJoe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> In my default install of Windows 2003 server the permissions on the
> hosts file are
>
> Administrators: Full Control
> System: Full Control
> Server Operaters: everything short of Full Control
> Authenticated Users: Read & Excecute and Read
> The file is owned by the administrators group.

Authenticated Users is more permissive than Users alone. Try to remove
Authenticated Users and Server Operators, reboot, and login as
administrator. HOSTS file functionality won't work.

To make it work again, add them back, reboot.

The mystery here isn't about Users versus Authenticated Users. The mystery
is why anything other than SYSTEM and Administrators would be required
against that file. I would like to understand in detail how Windows is
implementing the HOSTS file functionality. Apparently either some non
SYSTEM entity is reading that file, or alternately some of the code is
checking for permissions and refusing to work if the permissions are not set
the way it wants to see them.

--
Will



> Will wrote:
> > I solved this problem, and I'll post how for posterity, but I would be
> > interested in anyone's theories about why this works. It almost looks
like
> > a bug or misfeature to me.
> >
> > We had modified the default ACL on c:\windows\system32\drivers\etc to
> > exclude the Users group. If you give Users read and execute access,
and
> > then reboot (it will not work until you reboot), then hosts mysteriously
> > starts working. Note that before and after the reboot I am logged in
as
> > local administrator. And the folder always had Full Control access for
> > Administrators and SYSTEM, so it cannot be the case that giving Users
access
> > suddenly gave applications in my user context access, since they must
have
> > had read access to HOSTS before the ACL change.
> >
> > What surprises me about this is that I would have thought HOSTS was
> > implemented in the driver or somewhere in the kernel, not in each
individual
> > user application. If that is the case, then why would read access to
the
> > Users group affect this feature, which should be implemented by a SYSTEM
> > entity? It's almost like the code that runs at SYSTEM level did an
ACL
> > check, and after it saw that Users did not have access, it bypassed the
> > feature. That seems like wrong behavior.
> >
> > Note that the local Users group did NOT have Authenticated Users in it,
just
> > Domain Users.
> >
> > --
> > Will
> >
> >
> > "Will" <westes-(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed) ...
> > > On one of our Windows 2003 servers, the HOSTS file is not active. No
> > > changes made to the c:\windows\system32\drivers\etc\hosts file are
ever
> > > active, even after a reboot. Is there some registry setting or
group
> > > policy that would be deactivating that feature?
> > >
> > > --
> > > Will
> > >
> > >
>