LMHOSTS

LMHOSTS is found in the %SystemRoot%/system32/drivers/etc directory.

Este archivo contiene las direcciones de IP asociadas con nombres (NetBIOS) de recursos.

Windows NT recognizes names instead of IP addresses for network requests and a name discovery process is used to correctly route network requests with TCP/IP.

LMHOSTS is only used by the NBT (NetBIOS over TCP/IP) interface.

Estructura:

Cada entrada debería encontrarse en una línea individual. La dirección de IP debería colocarse en la primera columna seguida del nombre de equipo correspondiente. La dirección de IP y el nombre de equipo deberían estar separados como mínimo por un espacio o tabulador. El carácter "#" se usa generalmente para indicar el principio de un comentario (consulte las excepciones más adelante).

Este archivo es compatible con los archivos lmhosts de TCP/IP de Microsoft LAN Manager 2.x y ofrece las siguientes extensiones:
    #PRE
    #DOM:<dominio>
    #INCLUDE <nombre_de_archivo>
    #BEGIN_ALTERNATE
    #END_ALTERNATE
    \0xnn (permite caracteres no imprimibles)

Cualquier entrada iniciada con "#PRE" provoca que la entrada se cargue en la caché, hasta un máximo de 100 (MaxPreload). Las entradas normales del fichero no son cargadas directamente, sino que se consultan sólo cuando la resolución dinámica de nombres falla.

Cualquier entrada iniciada con "#DOM:<dominio>" asocia la entrada con el dominio especificado en <dominio>. Esto influye en cómo los servicios Examinador e Inicio de sesión actúa en entornos TCP/IP. Para cargar una entrada #DOM es necesario agregar #PRE a la línea.

Especificando "#INCLUDE <nombre_de_archivo>" obliga al software RFC NetBIOS (NBT) a buscar y tratar el <nombre_de_archivo> como si fuera local. <nombre_de_archivo> es generalmente un nombre basado en UNC, permitiendo que un lmhosts central sea mantenido en un servidor. Si el servidor se encuentra fuera del  rea de difusión, probablemente será necesario proporcionar al servidor información sobre direcciones de servidores antes de #INCLUDE.

#BEGIN_ y #END_ALTERNATE permiten agrupar múltiples sentencias #INCLUDE. Cualquier éxito individual se considera éxito del grupo.

Finalmente, caracteres no imprimibles pueden ser incluidos en este tipo de archivos, primero se ponen entre comillas los nombre NetBIOS y después se utiliza la notación \0xnn para especificar un valor hexadecimal para un carácter no imprimible.

To add an entry to the LMHOSTS file, enter the line in the following form:

IPaddress    Name     #PRE      #DOMAIN:Domainname

Note: Some users have reported problems with the LMHOSTS unless the entries are seperated by at least 3 spaces.

After you make changes to the LMHOSTS file, it is necessary to force the system to re-read the file to load the database into memory. You can do this by resetting the system or by going to the Command Prompt and entering the command nbtstat -A.

Ejemplo de fichero LMHOSTS
# Copyright (c) 1993-1995 Microsoft Corp.
#
#
# Este es un archivo LMHOSTS de ejemplo utilizado por TCP/IP de Microsoft para Windows NT.
#
#
# El siguiente ejemplo ilustra todas estas extensiones:
#
# 102.54.94.97      rino                                #PRE   #DOM:conectividad  #red DC de grupo
# 102.54.94.102    "nombreap  \0x14"         #servidor ap especial
# 102.54.94.123    popular                          #PRE   #servidor origen
#
# #BEGIN_ALTERNATE
# #INCLUDE \\localsrv\public\lmhosts
# #INCLUDE \\rino\public\lmhosts
# #END_ALTERNATE
#
# En el ejemplo anterior, el servidor "nombreap" contiene un carácter
# especial en su nombre, el nombre de servidor "popular" es cargado, y
# el nombre de servidor "rino" es especificado, por lo que puede ser
# utilizado para un posterior #INCLUDE de archivo lmhosts central si
# el sistema "localsrv" no está disponible.
#
 

Domain Browsing with LMHOSTS
In TCP/IP-based networks involving routers and multiple segments, it is generally recommended that you implement WINS for name resolution and browsing support. However, as an alternative to WINS, it is possible to have full domain browsing by using only LMHOSTS files on all computers, although there are some limitations that will be discussed later.

In either case, it is important to note that a client will only participate in domain browsing when the client is using a workgroup name that is equivalent to the domain name (WorkgroupName = DomainName). Windows NT computers can also "join" the domain to gain this functionality, instead of being in a workgroup.

This functionality of LMHOSTS-based domain browsing (over routers) has not been formally documented or tested by Microsoft, and may not be available in future versions of the client and server operating systems. Use this information with discretion.

"Browsing" in a Microsoft network should be considered a distributed service provided by one or more computers. Each computer can fall into several browser roles; however, this article will focus on the two most important ones:

Segment master browser (SegMB): This can be any Windows NT Server, Workstation, or domain controller. It can also be a Windows 95 or Windows for Workgroups 3.11 computer. It is responsible for maintaining a browse list of the computers on its local segment, forwarding that list to the domain master browser, and requesting the domain browse list from the domain master browser. The SegMB will merge the domain list with its local list, and make that list available to any local client that requests it.
Domain master browser (DomMB): This is the Windows NT primary domain controller (PDC). It is responsible for maintaining the browse list on its local segment (like a SegMB), as well as collecting browse lists from other (remote) segment master browsers with the same domain name (or WorkgroupName = DomainName). The DomMB will merge the lists it collects, along with its local list, then redistribute the combined list back to all the remote SegMBs. Thus it is the central hub for maintaining the domain-wide browse list.

In order for this distributed browse service to work, the SegMBs need a way to determine exactly who the DomMB is. They can determine this by locating the computer that has registered the NetBIOS name "Domain<1b>", because that is only registered by the PDC (which will also be the DomMB, as noted above).

In certain networks it may not be valuable to use WINS; this can only be determined on a case-by-case basis. You can then use either LMHOSTS or DNS to resolve computer names; however, LMHOSTS will be required for domain browsing, as well as other domain management issues such as database replication and domain secure channels.

Without WINS, you will need special LMHOSTS entries that designate who all the domain controllers are. This is done in the following convention:

 199.199.199.1  ComputerName   #PRE  #DOM:DomainName

When a computer is booted, it will read these entries and store them permanently in the NetBIOS name cache until the computer is powered down. (Because of this, it is best that these entries are last in the LMHOSTS file, for subsequent LMHOSTS parsing efficiency.) All computers in the domain will need one of these entries for each domain controller (in the local domain), as well as one for the PDC. Also note the exact order of #PRE #DOM, and that they are capitalized. The other names are not case sensitive.
 

Windows NT Segment Master Browsers
Having the above entries will be sufficient for a Windows NT computer: Upon becoming a Segment Master Browser, a Windows NT computer determines who the PDC is by sending a query (using the NetGetDcName API) to all LMHOSTS entries with the #DOM:<localdomain> designation. Only the PDC will respond. The Windows NT computer then contacts the PDC, informs the PDC that it is a master browser, then continues the process of getting the domain browse list. The PDC then contacts the Windows NT computer to get its local segment browse list. This process repeats every 12 to 15 minutes.

Windows 95 and Windows for Workgroups Segment Master Browsers
These do not perform the NetGetDcName API, so they need entries in the LMHOSTS file that indicate who the PDC is. Assuming the example above is the PDC of the domain, you would have two entries for a Windows 95 or Windows for Workgroups client:

 199.199.199.1  controller1   #PRE  #DOM:domainname
 199.199.199.1  "domainname,,,,,\0x1b"  #PRE

The first entry allows the PDC to act as a logon domain controller for the client, the second entry allows the client browser service to explicitly find the PDC. Remember you will probably have multiple lines similar to the first line (for multiple domain controllers), but only one line with the \0x1b directive (to designate the PDC). Note that the domain name must be in quotes, and padded with spaces for a total of 15 characters before the \0x1b portion. (The example above shows commas for visual placeholders, however in a real LMHOSTS file these commas would be replaced with spaces). Also be aware that moving the PDC role to another Windows NT Server (via promotion) will cause your \0x1b entry to be invalid. Options to fix this:

LMHOSTS Example
Your domain name is "Globe", your PDC NetBIOS name is "Mongo", and you have other various backup domain controllers. Your LMHOSTS file would look like this:

199.199.199.1   "globe          \0x1b"  #PRE
199.199.199.1   mongo      #PRE  #DOM:globe
199.199.199.2   otherdc1   #PRE  #DOM:globe
199.199.199.3   otherdc2   #PRE  #DOM:globe

To verify that you've entered these correctly, open a command window (DOS prompt) and look at your NetBIOS cache:

 c:\> nbtstat -c

 NetBIOS Remote Cache Name Table

     Name              Type       Host Address    Life [sec]
 ------------------------------------------------------------
 globe          <1B>  UNIQUE      199.199.199.1       -1
 MONGO          <03>  UNIQUE      199.199.199.1       -1
 MONGO          <00>  UNIQUE      199.199.199.1       -1
 MONGO          <20>  UNIQUE      199.199.199.1       -1
 OTHERDC1       <03>  UNIQUE      199.199.199.2       -1
 OTHERDC1       <00>  UNIQUE      199.199.199.2       -1
 OTHERDC1       <20>  UNIQUE      199.199.199.2       -1
 OTHERDC2       <03>  UNIQUE      199.199.199.3       -1
 OTHERDC2       <00>  UNIQUE      199.199.199.3       -1
 OTHERDC2       <20>  UNIQUE      199.199.199.3       -1

TIP: the <1B> entry will not show up if you do not have exactly 15 characters in the name, or if you do not use quotes, or if you enter the forward slash "/0x1b" (as opposed to "\0x1b").
 

Multi-Domain Browsing with LMHOSTS
It is important to note that the main drawback to LMHOSTS browsing is that it does not provide the automatic ability of multi-domain browsing. As previously mentioned, the PDC will query WINS for a list of remote domains and include that information in its browse list. However, the PDC will not parse the LMHOSTS file for the same information, nor will it include other \0x1b entries with the #PRE (cache) directive. Effectively, if your PDC does not query WINS, you will not see other domains through File Manager or Network Neighborhood. However, you can still browse other domains manually, (provided that you know the domain name and that you have special entries in your LMHOSTS file), and there is still a chance that you may browse remote domains based on broadcasts.

Manual Method: this is accomplished by including a \0x1b entry for the PDC of any remote domain you want to browse. This technique applies to Windows NT, Windows 95, and Windows for Workgroups. It is effective because of the following sequence of events, necessary for remote domain browsing:

  1. The client determines who the PDC is of the remote domain via the domain<1b> name (for LMHOSTS this is done by having the \0x1b entry; for WINS it would be via query).
  2. The client sends a GetBackupList API request to the remote PDC
  3. The remote PDC responds with a list of up to three master browsers, potentially including itself.
  4. The client sends a NetServerEnum API request to one of the master browsers
  5. The master browser responds with his domain-wide browse list. The "manual way" of getting this browse list is via a command window:

    6. c:\net view  /domain:<domainname>
Broadcast Method: This works in the case of any network segment that has members of multiple domains. There will be a SegMB of each domain on the "mutual" segment, and each SegMB will announce its domain via broadcast to a special NetBIOS name <01><02>_MSBROWSE_<02><01>. This broadcast packet includes the domain name and the computer name of the SegMB that announced it.
The SegMBs of other domains (on this mutual segment) will listen for this information, and add it to their local browse list. A SegMB on this segment has now "discovered" other domains, and will send the discovered information to: the DomMB of his domain, and to local clients (in his domain) that request a browse list.

A client will request the local domain browse list (from a local SegMB) and see the discovered domains in File Manager and Network Neighborhood. When the client selects the discovered domain, he will actually request a browse list directly from the SegMB that made the announcement in the <01><02>_MSBROWSE_<02><01> packet. Furthermore, since this information was also sent to the client's DomMB, it will be propagated to SegMB's on other segments that are part of this domain.

Clients on a remote segment can now leverage this information, and browse the remote domain even though there is no remote domain member on their segment. However, this process is very volatile using LMHOSTS files, because you are dependent on the "discovered remote SegMB's" still being active. In a WINS environment, this remote browsing feature is much more stable because WINS provides information about the remote domains to your PDC.

Things to consider:

For domain logon and domain browsing to work via LMHOSTS, all computers will require an LMHOSTS file that includes entries for all domain controllers and proper \0x1b entries, and the PDC will require an entry for each remote segment master browser (if they are not already listed).
Most likely every WAN computer will be listed. This could be done most efficiently by having one common LMHOSTS file that is distributed to all clients and servers; however, you must keep it updated with all proper IP address changes, and that could become an administrative burden.
Seeing a computer in the browse list does not imply you can connect to it. If it is on your local segment, you can connect via broadcast; if it is on a remote segment, you will need an LMHOSTS entry for it.
 

Referencias