Discussion

All MS Windows networking uses SMB-based messaging. SMB messaging may be imple- mented with or without NetBIOS. MS Windows 200x supports NetBIOS over TCP/IP for backwards compatibility. Microsoft appears intent on phasing out NetBIOS support.

9.3.1

NetBIOS over TCP/IP

Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP. NetBIOS-based networking uses broadcast messaging to effect browse list man- agement. When running NetBIOS over TCP/IP, this uses UDP-based messaging. UDP messages can be broadcast or unicast.

Normally, only unicast UDP messaging can be forwarded by routers. Theremote announce

parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the remote browse sync parameter of smb.conf implements browse list collation using unicast UDP.

The methods used by MS Windows to perform name lookup requests (name resolution) is determined by a configuration parameter called the NetBIOS node-type. There are four basic NetBIOS node types:

118 Network Browsing Chapter 9

• b-node (type 0x01): The Windows client will use only NetBIOS broadcast requests using UDP broadcast.

• p-node (type 0x02): The Windows client will use point-to-point (NetBIOS unicast) requests using UDP unicast directed to a WINS server.

• m-node (type 0x04): The Windows client will first use NetBIOS broadcast requests using UDP broadcast, then it will use (NetBIOS unicast) requests using UDP unicast directed to a WINS server.

• h-node (type 0x08): The Windows client will use (NetBIOS unicast) requests using UDP unicast directed to a WINS server, then it will use NetBIOS broadcast requests using UDP broadcast.

The default Windows network client (or server) network configuration enables NetBIOS over TCP/IP and b-node configuration. The use of WINS makes most sense with h-node (hybrid mode) operation so that in the event of a WINS breakdown or non-availability, the client can use broadcast-based name resolution.

In those networks where Samba is the only SMB server technology, wherever possiblenmbd

should be configured on one machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with its own Samba WINS server, then the only way to get cross-segment browsing to work is by using the remote announce and theremote browse sync parameters to yoursmb.conffile.

If only one WINS server is used for an entire multisegment network, then the use of the

remote announce and theremote browse sync parameters should not be necessary.

As of Samba-3, WINS replication is being worked on. The bulk of the code has been committed, but it still needs maturation. This is not a supported feature of the Samba- 3.0.20 release. Hopefully, this will become a supported feature of one of the Samba-3 release series. The delay is caused by the fact that this feature has not been of sufficient significance to inspire someone to pay a developer to complete it.

Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS server, there must only be onenmbdconfigured as a WINS server on the network. Some sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then usedremote browse syncandremote announce to effect browse list collation across all segments. Note that this means clients will only resolve local names and must be configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers they can see on other subnets. This setup is not recommended but is mentioned as a practical consideration (i.e., an “if all else fails” scenario). NetBIOS over TCP/IP is an ugly and difficult to manage protocol. Its replacement, NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOS based networking is a life of compromise and trade-offs. WINS stores information that cannot be stored in DNS; consequently, DNS is a poor substitute for WINS given that when NetBIOS over TCP/IP is used, Windows clients are designed to use WINS.

Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time

Section9.3. Discussion 119

to establish a browse list, and it can take up to 45 minutes to stabilize, particularly across network segments.

When an MS Windows 200x/XP system attempts to resolve a host name to an IP address, it follows a defined path:

1. Checks thehostsfile. It is located in%SystemRoot%\System32\Drivers\etc. 2. Does a DNS lookup.

3. Checks the NetBIOS name cache. 4. Queries the WINS server.

5. Does a broadcast name lookup over UDP.

6. Looks up entries in LMHOSTS, located in%SystemRoot%\System32\Drivers\etc. Given the nature of how the NetBIOS over TCP/IP protocol is implemented, only WINS is capable of resolving with any reliability name lookups for service-oriented names such as TEMPTATION<1C>— a NetBIOS name query that seeks to find network logon servers. DNS has no concept of service-oriented names such as this. In fact, the Microsoft ADS implementation specifically manages a whole range of extended service-oriented DNS entries. This type of facility is not implemented and is not supported for the NetBIOS over TCP/IP protocol namespace.

9.3.2

TCP/IP without NetBIOS

All TCP/IP-enabled systems use various forms of hostname resolution. The primary meth- ods for TCP/IP hostname resolution involve either a static file (/etc/hosts) or the Domain Name System (DNS). DNS is the technology that makes the Internet usable. DNS-based hostname resolution is supported by nearly all TCP/IP-enabled systems. Only a few em- bedded TCP/IP systems do not support DNS.

Windows 200x/XP can register its hostname with a Dynamic DNS server (DDNS). It is possible to force register with a dynamic DNS server in Windows 200x/XP usingipconfig /registerdns.

With Active Directory, a correctly functioning DNS server is absolutely essential. In the absence of a working DNS server that has been correctly configured, MS Windows clients and servers will be unable to locate each other, so network services consequently will be severely impaired.

Use of raw SMB over TCP/IP (No NetBIOS layer) can be done only with Active Directory domains. Samba is not an Active Directory domain controller: ergo, it is not possible to run Samba as a domain controller and at the same timenot use NetBIOS. Where Samba is used as an Active Directory domain member server (DMS) it is possible to configure Samba to not use NetBIOS over TCP/IP. A Samba DMS can integrate fully into an Active Directory domain, however, if NetBIOS over TCP/IP is disabled, it is necessary to manually create appropriate DNS entries for the Samba DMS because they will not be automatically generated either by Samba, or by the ADS environment.

120 Network Browsing Chapter 9

9.3.3

DNS and Active Directory

Occasionally we hear from UNIX network administrators who want to use a UNIX-based DDNS server in place of the Microsoft DNS server. While this might be desirable to some, the MS Windows 200x DNS server is autoconfigured to work with Active Directory. It is possible to use BIND version 8 or 9, but it will almost certainly be necessary to create service records (SRV records) so MS Active Directory clients can resolve hostnames to locate essential network services. The following are some of the default service records that Active Directory requires:

The use of DDNS is highly recommended with Active Directory, in which case the use of BIND9 is preferred for its ability to adequately support the SRV (service) records that are needed for Active Directory. Of course, when running ADS, it makes sense to use Microsoft’s own DDNS server because of the natural affinity between ADS and MS DNS.

ldap. tcp.pdc. msdcs.Domain This provides the address of the Windows NT PDC for the domain.

ldap. tcp.pdc. msdcs.DomainTree Resolves the addresses of global catalog servers in the domain.

ldap. tcp.site.sites.writable. msdcs.Domain Provides list of domain controllers based on sites.

ldap. tcp.writable. msdcs.Domain Enumerates list of domain controllers that have the writable copies of the Active Directory data store.

ldap. tcp.GUID.domains. msdcs.DomainTree Entry used by MS Windows clients to locate machines using the global unique identifier.

ldap. tcp.Site.gc. msdcs.DomainTree Used by Microsoft Windows clients to locate the site configuration-dependent global catalog server.

Specific entries used by Microsoft clients to locate essential services for an example domain calledquenya.org include:

• kerberos. udp.quenya.org — Used to contact the KDC server via UDP. This entry must list port 88 for each KDC.

• kpasswd. udp.quenya.org — Used to locate thekpasswdserver when a user password change must be processed. This record must list port 464 on the master KDC.

• kerberos. tcp.quenya.org — Used to locate the KDC server via TCP. This entry must list port 88 for each KDC.

• ldap. tcp.quenya.org — Used to locate the LDAP service on the PDC. This record must list port 389 for the PDC.

Section9.3. Discussion 121

• kpasswd. tcp.quenya.org — Used to locate thekpasswd server to permit user pass- word changes to be processed. This must list port 464.

• gc. tcp.quenya.org — Used to locate the global catalog server for the top of the domain. This must list port 3268.

The following records are also used by the Windows domain member client to locate vital services on the Windows ADS domain controllers.

• ldap. tcp.pdc. msdcs.quenya.org

• ldap.gc. msdcs.quenya.org

• ldap.default-first-site-name. sites.gc. msdcs.quenya.org

• ldap.{SecID}.domains. msdcs.quenya.org

• ldap. tcp.dc. msdcs.quenya.org

• kerberos. tcp.dc. msdcs.quenya.org

• ldap.default-first-site-name. sites.dc. msdcs.quenya.org

• kerberos.default-first-site-name. sites.dc. msdcs.queyna.org

• SecID. msdcs.quenya.org

Presence of the correct DNS entries can be validated by executing:

root# dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org

; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org ;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION: ;_ldap._tcp.dc._msdcs.quenya.org. IN ANY ;; ANSWER SECTION: _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org. _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org. ;; ADDITIONAL SECTION: frodo.quenya.org. 3600 IN A 10.1.1.16 noldor.quenya.org. 1200 IN A 10.1.1.17

122 Network Browsing Chapter 9

;; Query time: 0 msec

;; SERVER: frodo#53(10.1.1.16) ;; WHEN: Wed Oct 7 14:39:31 2004 ;; MSG SIZE rcvd: 171