[스크랩] netbios / SMB / WINS

영어라서 볼려니까 머리가 아프다ㅠㅠ

https://en.wikipedia.org/wiki/NetBIOS

Services[edit]

NetBIOS provides three distinct services:

• Name service (NetBIOS-NS) for name registration and resolution.
• Datagram distribution service (NetBIOS-DGM) for connectionless communication.
• Session service (NetBIOS-SSN) for connection-oriented communication.

(Note: SMB, an upper layer, is a service that runs on top of the Session Service and the Datagram service, and is not to be confused as a necessary and integral part of NetBIOS itself. It can now run atop TCP with a small adaptation layer that adds a packet length to each SMB message; this is necessary because TCP only provides a byte-stream service with no notion of packet boundaries.)

------------------------------------------------------------------------------------------------------------------------------------

http://ktword.co.kr/abbr_view.php?m_temp1=319

4. NetBIOS가 제공하는 3가지 서비스

  ㅇ 이름명명법 (Name Service)   ☞  NetBIOS Name Service
     - 네임 서비스 (이름 서비스)
        . 이름 : 16 바이트의 알파벳 문자 또는 숫자의 조합
        . 대문자로 된 컴퓨터 이름 (15 바이트) + name type (1 바이트)
        . NetBIOS 이름공간(Name Space)는 평평하다.  즉 DNS 처럼 계층적이지 않다.

  ㅇ NetBIOS는 다음 두 통신 모드를 제공한다.
     - 세션(Session) 모드 서비스
        . 두 컴퓨터가 통신할 수 있는 연결을 성립시키고, 보다 큰 메시지가 처리될 수
          있게 하며, 통신 에러의 발견과 회복을 제공.
     - 데이터그램(Datagram) 모드 서비스
        . 데이터그램 모드는 비연결형(connectionless, 각 메시지가 독립적으로 전송)으
          로, 메시지가 보다 작으며 응용 프로그램이 통신 에러의 발견과 회복을 수행.
          또한 메시지를 LAN의 모든 컴퓨터에 전송시키는 브로드캐스트(방송)을 지원.

------------------------------------------------------------------------------------------------------------------------------------

Name service[edit]

In order to start sessions or distribute datagrams, an application must register its NetBIOS name using the name service. NetBIOS names are 16 octets in length and vary based on the particular implementation. Frequently, the 16th octet, called the NetBIOS Suffix, designates the type of resource, and can be used to tell other applications what type of services the system offers. In NBT, the name service operates on UDP port 137 (TCP port 137 can also be used, but rarely is).

The name service primitives offered by NetBIOS are:

• Add name – registers a NetBIOS name.
• Add group name – registers a NetBIOS "group" name.
• Delete name – un-registers a NetBIOS name or group name.
• Find name – looks up a NetBIOS name on the network.

NetBIOS name resolution is not supported by Microsoft for Internet Protocol Version 6 (IPv6).

Datagram distribution service[edit]

Datagram mode is connectionless; the application is responsible for error detection and recovery. In NBT, the datagram service runs on UDP port 138.

The datagram service primitives offered by NetBIOS are:

• Send Datagram – send a datagram to a remote NetBIOS name.
• Send Broadcast Datagram – send a datagram to all NetBIOS names on the network.
• Receive Datagram – wait for a packet to arrive from a Send Datagram operation.
• Receive Broadcast Datagram – wait for a packet to arrive from a Send Broadcast Datagram operation.

Session service[edit]

Session mode lets two computers establish a connection, allows messages to span multiple packets, and provides error detection and recovery. In NBT, the session service runs on TCP port 139.

The session service primitives offered by NetBIOS are:

• Call – opens a session to a remote NetBIOS name.
• Listen – listen for attempts to open a session to a NetBIOS name.
• Hang Up – close a session.
• Send – sends a packet to the computer on the other end of a session.
• Send No Ack – like Send, but doesn't require an acknowledgment.
• Receive – wait for a packet to arrive from a Send on the other end of a session.

In the original protocol used to implement NetworkBIOS services on PC-Network, to establish a session, the initiating computer sends an Open request which is answered by an Open acknowledgment. The computer that started the session will then send a Session Request packet which will prompt either a Session Accept or Session Reject packet.

During an established session, each transmitted packet is answered by either a positive-acknowledgment (ACK) or negative-acknowledgment (NAK) response. A NAK will prompt retransmission of the data. Sessions are closed by the non-initiating computer by sending a close request. The computer that started the session will reply with a close response which prompts the final session closed packet.

----------------------------------------------------------------------------------------------------------------------------------

http://hyperv.tistory.com/entry/NetBIOS%EC%99%80-IP-%EC%A3%BC%EC%86%8C%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

NetBIOS와 IP 주소의 차이점

윈도우 2013.01.14 17:57

----------------------------------------------------------------------------------------

출 처 : http://cafe.naver.com/devctrl/5583

----------------------------------------------------------------------------------------

 

NetBIOS는 네트워크 프로토콜이 아니라 세션 Layer에 TCP, IP, IPX, NetBIEU 등의 네트워크/전달 계층 프로토콜을 연결하는 역활을 하는 프로그램이다.

 

윈도우즈 98 이전의 윈도우즈 네트워크에서 각각의 컴퓨터를 인식하려면 넷바이오스를 필요로 했는데, 이처럼 각각의 컴퓨터를 구분하기 위해 사용하는 이름을 넷바이오스 이름이라고 한다. 넷바이오스 이름은 16바이트까지 나타낼 수 있으며(우리말의 경우 실제로는 7자까지) 보통 네트워크 환경을 더블클릭하여 나타나는 네트워크 상의 이름들을 넷바이오스 이름이라고 생각하면 된다.

 

명령 프롬프트 상태에서

C:\>nbtstat -n

라고 치면 자신의 넷바이오스 이름을 확인할 수 있다.

 

[내 컴퓨터]의 속성을 통해 확인할 수 있는 "전체 컴퓨터 이름" 및 "작업 그룹"이 바로 NetBIOS 이름이다.

 

넷바이오스를 지원하는 윈도우즈의 프로토콜이 NetBIEU이다.

그래서 TCP/IP 프로토콜을 설치하지 않거나 각 컴퓨터가 IP 주소를 정적 혹은 동적으로 받지 못했어도 NetBIEU가 설치되어 있으면 내부 네트워크상에서 서로 연결되고 파일을 공유할 수도 있다.

 

단 라우팅이되는 프로토콜이 아니기 때문에 라우터를 이용하여 우리 네트워크(흔히 브로드캐스트 도메인이라고 해서 패킷이 라우팅 되지 않고 전달되 수 있는 영역)를 넘어 다른 네트워크로 갈 수 없다. 즉, 인터넷이 불가능하다.

그래서 NetBIOS 이름은 다른 네트워크로 전송되지 않기 때문에 예를 들어 "우리집컴퓨터"라는 NetBIOS 이름은 전세계 수백개가 있어도 아무 상관이 없다(같은 네트워크가 아니라면).

 

현재 윈도우즈 운영체제는 "NetBIOS over TCP/IP"라고 해서 TCP/IP가 NetBIOS의 역활을 대신하고 있다. 대신한다기 보다는 얹혀 있다고 표현하는 것이 좋다. 그래서 NetBIEU 프로토콜이 설치되어 있지 않아도 TCP/IP가 설치되어 있으면 NetBIOS 이름을 해석할 수 있다.  

----------------------------------------------------------------------------------------------------------------------------------

https://technet.microsoft.com/en-us/library/cc940063.aspx

NetBIOS Over TCP/IP

The Windows 2000 implementation of NetBIOS over TCP/IP is referred to as NetBT . NetBT uses the following TCP and UDP ports:

• UDP port 137 (name services)

• UDP port 138 (datagram services)

• TCP port 139 (session services)

NetBIOS over TCP/IP is specified by RFC 1001 and RFC 1002. The Netbt.sys driver is a kernel -mode component that supports the TDI interface. Services such as workstation and server use the TDI interface directly, while traditional NetBIOS applications have their calls mapped to TDI calls through the Netbios.sys driver. Using TDI to make calls to NetBT is a more difficult programming task, but can provide higher performance and freedom from historical NetBIOS limitations.

NetBIOS defines a software interface and a naming convention, not a protocol. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the IP internetworks and providing interoperability with various other operating systems.

The Windows 2000 workstation service, server service, browser, messenger, and NetLogon services are all NetBT clients and use TDI to communicate with NetBT. Windows 2000 also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI functions.

Windows 2000 uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 95. However, the Windows 2000 redirector and server components now support direct hosting for communicating with other computers running Windows 2000. With direct hosting, NetBIOS is not used for name resolution. DNS is used for name resolution and the Microsoft networking communication is sent directly over TCP without a NetBIOS header. Direct hosting over TCP/IP uses TCP port 445 instead of the NetBIOS session TCP port 139.

By default, both NetBIOS and direct hosting are enabled, and both are tried in parallel when a new connection is established. The first to succeed in connecting is used for any given attempt. NetBIOS over TCP/IP support can be disabled to force all traffic to use TCP/IP direct hosting.

To disable NetBIOS over TCP/IP support

1. From the Network and Dial-up Connections icon in Control Panel , select Local Area Connection and right-click Properties .

2. On the General tab, click Internet Protocol (TCP/IP) in the list of components, and click the Properties button.

3. Click the Advanced button.

4. Click the WINS tab. Click Disable NetBIOS over TCP/IP .

Applications and services that depend on NetBIOS over TCP/IP no longer function once NetBIOS over TCP/IP is disabled. Therefore, verify that any clients and applications no longer need NetBIOS over TCP/IP support before you disable it.

NetBIOS Names

The NetBIOS namespace is flat, meaning that all names within the namespace must be unique. NetBIOS names are 16 bytes long. Resources are identified by NetBIOS names, which are registered dynamically when services or applications start, or users log on. Names can be registered as unique names (one owner) or as group names (multiple owners). A NetBIOS Name Query is used to locate a resource by resolving the NetBIOS name to an IP address.

Microsoft networking components, such as the workstation and server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the 16th character of the NetBIOS name to indicate a resource type (00-FF hex). Tables 2.2 and 2.3 have some example NetBIOS names used by Microsoft components:

Table 2.2 Unique NetBIOS Names Used by Microsoft Components

Unique Name	Service
<computer_name>[00] (space filled) 1	Workstation Service
<computer_name>[03] (space filled)	Messenger Service
<computer_name>[06] (space filled)	RAS Server Service
<computer_name>[1F] (space filled)	NetDDE Service
<computer_name>[20] (space filled)	Server Service
<computer_name>[21] (space filled)	RAS Client Service
<computer_name>[BE] (0xBE filled)	Network Monitor Agent
<computer_name>[BF] (0xBF filled)	Network Monitor Application
<user_name>[03] (space filled)	Messenger Service
<domain_name>[1D] (space filled)	Master Browser
<domain_name>[1B] (space filled)	Domain Master Browser
1 The number in brackets is a hexadecimal number. (space filled) means that if the computer or domain name is not 15 characters long, the name is filled with spaces up to 15 characters.

Table 2.3 Group NetBIOS Names Used by Microsoft Components

Group Name	Service
<domain_name>[00] (space filled)	Domain Name
<domain_name>[1C] (space filled)	Domain Controllers
<domain_name>[1E] (space filled)	Browser Service Elections
[01h][01h]__MSBROWSE__[01h][01h]	Master Browser

Top Of Page

NBTStat Tool

The NBTStat tool is used to view and register NetBIOS names on a Windows 2000 computer. To see which NetBIOS names a computer has registered over NetBT, type the following from a command prompt:

nbtstat -n

Windows 2000 allows you to reregister NetBIOS names with the name server after a computer has already been started. To reregister NetBIOS names, type the following from a command prompt:

nbtstat –RR

Top Of Page

NetBIOS Name Registration and Resolution

Windows 2000 TCP/IP systems use several methods to locate NetBIOS resources:

• NetBIOS name cache.

• NetBIOS name server.

• IP subnet broadcasts.

• Static Lmhosts file.

• Static Hosts file (optional, depends on EnableDns registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters)).

• DNS servers (optional, depends on EnableDns registry entry).

NetBIOS name resolution order depends upon the node type and system configuration. The following node types are supported:

• B-node — uses broadcasts for name registration and resolution.

• P-node — uses a NetBIOS Name Server for name registration and resolution.

• M-node — uses broadcasts for name registration. For name resolution, it tries broadcasts first, but switches to p-node if it receives no answer.

• H-node — uses NetBIOS name server for both registration and resolution. However, if no name server can be located, it switches to b-node. It continues to poll for name server and switches back to p-node when one becomes available.

• Microsoft-enhanced — uses the local Lmhosts file or WINS proxies plus Windows Sockets gethostbyname( ) calls (using standard DNS and/or local Hosts files) in addition to standard node types.

Microsoft includes a NetBIOS name server known as the Windows Internet Name Service (WINS). Most WINS clients are set up as h-nodes; that is, they first attempt to register and resolve names using WINS, and if that fails, they try local subnet broadcasts. Using a name server to locate resources is generally preferable to broadcasting for two reasons:

• Broadcasts are not usually forwarded by routers.

• Broadcast frames are processed by all computers on a subnet.

Figures 2.4 through 2.5 illustrate the NetBIOS name resolution methods used by Windows 2000.

Figure 2.4 NetBIOS Name Resolution Flowchart (part 1 of 2)

Figure 2.5 NetBIOS Name Resolution Flowchart (part 2 of 2)

Top Of Page

NetBIOS Name Registration and Resolution for Multihomed Computers

NetBT binds to only one IP address per physical network interface. From the NetBT viewpoint, a computer is multihomed only if it has more than one network adapter installed. When a name registration packet is sent from a multihomed computer, it is flagged as a multihomed name registration so that it does not conflict with the same name being registered by another interface in the same computer.

If a multihomed computer receives a broadcast NetBIOS Name Query, all NetBT and interface bindings that receive the query respond with their addresses, and by default the client chooses the first response and connects to the address supplied by the responder. To have the responder randomly choose the IP address to put in the name query response, set the value of the RandomAdapter registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters) to 1. This can be used by a server with two interfaces on the same network for load balancing.

When a directed name query is sent to a WINS server, the WINS server responds with a list of all IP addresses that are registered with WINS by the multihomed computer.

A Windows 2000 client uses the following process to choose the best IP address to connect to on a multihomed computer:

1. If one of the IP addresses in the name query response list is on the same logical subnet as the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those that match.

2. If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, then that address is selected. If multiple addresses meet this criteria, one is picked at random.

3. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, then an address is selected at random from the list.

4. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, an address is selected at random from the list.

This algorithm provides a reasonable balancing of connections to a server across multiple network adapters, while still favoring local (same subnet) connections when they are available. To provide some fault tolerance, when there is a list of IP addresses returned, they are sorted into the best order, and NetBT attempts to ping each of the addresses in the list until one responds. NetBT then attempts a connection to that address. If no addresses respond, then a connection attempt is made to the first address in the list. This is tried in case there is a firewall or other device filtering ICMP traffic. Windows 2000 supports "per interface" NetBT name caching, and nbtstat -c displays the name cache on a per interface basis.

Top Of Page

Windows 2000 NetBT Internet/DNS Enhancements

It is possible to connect from one Windows 2000–based computer to another using NetBT over the Internet. To do so, some means of name resolution has to be provided. Two common methods are the Lmhosts file or a WINS server. Several enhancements were introduced in Windows NT 4.0 and carried forward in Windows 2000 to eliminate these special configuration needs.

It is now possible to connect to a NetBIOS over TCP/IP resource in two new ways:

• Use the command net use \\< ip address >\< share_name > . This eliminates the need for NetBIOS name resolution configuration.

• Use the command net use \\< FQDN >\< share_name > . This allows the use of a DNS server to connect to a computer using its fully qualified domain name (FQDN).

Examples of using new functionality to map a drive to ftp.microsoft.com at the IP address of 198.105.232.1 are shown here.

• net use f: \\ftp.microsoft.com\data

• net use \\198.105.232.1\data

• net view \\198.105.232.1

• dir \\ftp.microsoft.com\bussys\winnt

In addition, various applications allow you to enter an FQDN or IP address in place of a computer name. This new behavior is illustrated in Figure 2.6.

Figure 2.6 Behavior of NetBT Internet/DNS Enhancements

In Windows 2000, it is also possible to use direct hosting to establish redirector or server connections between Windows 2000 computers without the use of NetBIOS. By default, Windows 2000 attempts to make connections using both methods so that it can support connections to older versions of Windows computers. However, in Windows 2000–only environments, you can disable NetBIOS over TCP/IP as described in the "NetBIOS Over TCP/IP Sessions" following in this chapter.

The new interface in Windows 2000 that makes NetBIOS-less operation possible is called the Server Message Block (SMB) device. It appears to the redirector and server as another interface, much like an individual network adapter/protocol stack combination. However, at the TCP/IP stack, the SMB device is bound to ADDR_ANY, and uses the DNS namespace natively like a Windows Sockets application. Calls placed on the SMB device result in a standard DNS lookup to resolve the domain name to an IP address, followed by a single outbound connection request using the best source IP address and interface as determined by the route table.

Additionally, there is no "NetBIOS session setup" on top of the TCP connection, as there is with traditional NetBIOS over TCP/IP. By default, the redirector places calls on both the NetBIOS device(s) and the SMB device, and the file server receives calls on both. The file server SMB device listens on TCP port 445 instead of the NetBIOS over TCP port 139.

Top Of Page

NetBIOS Over TCP/IP Sessions

NetBIOS sessions are established between two names. For example, when a Windows 2000 workstation service makes a file sharing connection to a Windows 2000 server service using NetBIOS over TCP/IP, the following sequence of events takes place:

1. The NetBIOS name for the server process is resolved to an IP address.

2. A TCP connection is established from the workstation to the server, using TCP port 139.

3. The workstation sends a NetBIOS Session Request to the server name over the TCP connection. Assuming the server is listening on that name, it will respond affirmatively and a session is established.

Once the NetBIOS session has been established, the client and server negotiate the file sharing connection with the Server Message Block (SMB) protocol. Microsoft networking uses only one NetBIOS session between two names at any point in time. Any additional file or print sharing connections made after the first one are multiplexed over the same NetBIOS session.

NetBIOS keep-alives are used on each connection to verify that the server and workstation are still both up and able to maintain their session. This way, if a workstation is shut down ungracefully, the server will eventually clean up the connection and associated resources, and vice versa. NetBIOS keep-alives are controlled by the SessionKeepAlive registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters) and default to once per hour.

If Lmhosts files are used and an entry is misspelled, it is possible to attempt to connect to a server using the correct IP address but an incorrect name. In this case, a TCP connection is still established to the server. However, the NetBIOS session request using an invalid name will be rejected by the server. If attempting the connection with the net use command, "Error 51: Remote computer not listening" is returned.

Top Of Page

NetBIOS Datagram Services

Datagrams are sent from one NetBIOS name to another over UDP port 138. The datagram service provides the ability to send a message to a unique name or to a group name. Group names can resolve to a list of IP addresses or a broadcast. For instance, the command net send /d:mydomain test sends a datagram containing the text "test" to the group name MYDOMAIN[03]. The MYDOMAIN[03] name resolves to an IP subnet broadcast, so the datagram is sent with the following characteristics:

• Destination MAC address: The MAC-level broadcast (0xFF-FF-FF-FF-FF-FF).

• Source MAC address: The MAC address of the local computer.

• Destination IP address: The local subnet broadcast address.

• Source IP address: The IP address of the local computer.

• Destination name: MYDOMAIN[03] (the messenger service on the remote computers).

• Source name: USERNAME[03] (the messenger service on the local computer).

All hosts on the subnet pick up the datagram and process it at least to the UDP protocol. on hosts running a NetBIOS datagram service, UDP hands the datagram to NetBT on port 138. NetBT checks the destination name to see if any application has registered that name, and if so, passes up the datagram. If no receive message was posted, the datagram is discarded.

Note that if support for NetBIOS is disabled in Windows 2000, then the NetBIOS datagram is discarded by UDP.

----------------------------------------------------------------------------------------------------------------------------------

http://www.icir.org/gregor/tools/ms-smb-protocols.html

Microsoft SMB, SMB2, NetBIOS, WINS protocol suite

This document provides a quick overview of how various Microsoft protocol (SMB, SMB2, NetBIOS, WINS, dynamic DNS updates) work and interact. This is work in progress and reflects my current knowledge, which might or might not be accurate.

Keywords: SMB, SMB2, CIFS, NetBIOS, WINS, dynamic DNS updates, netbios-ns, netbios-dgm, netbios-ssn, port 137, port 138, port 139, port 445

1   SMB

• Server Message Block (SMB), aka Common Internet File System (CIFS).
• Application layer protocol to network access to files, printer, etc. as well as inter process communication
• New version (SMB2) introduced with Windows Vista
• Originally used NetBIOS and NetBIOS over TCP/IP for communication.
• Uses NetBIOS datagram and session service.
• Question: when is datagram service used
• Direct communication over 445/TCP added with Win 2000
• Broadcast traffic issues were due to WINS
• SMB2 might only support 445/TCP and not NetBIOS, but I don't know.
• History:
  • Originated at IBM
  • Microsoft merged it with LAN Manager
  • Designed to run over NetBIOS

2   NetBIOS

• Background
  • Provides services related to OSI session layer
  • NetBIOS is an API, not a networking protocol
  • Developed in 1983, used for a bunch of things, but now only known as API providing services for SMB.
  • Older OSes ran NetBIOS over Ethernet, IPX/SPX using NetBIOS Frames (NBF)
  • Now mostly NetBIOS over TCP/IP (NBT). (NetBIOS is now used as synonym for NBT)
  • Nodes have a NetBIOS name and an IP address.
• NetBIOS over TCP/IP services.
  • Standardized in
    • RFC 1001
    • RFC 1002
  • Provides: + Name Service (Port 137/UDP) + Datagram Service (Port 138/UDP) + Session Service (Port 139/TCP)
• SMB runs on top of NetBIOS

2.1   Windows Internet Naming Service (WINS)

• Microsoft's implementation of NetBIOS nameservice.
• Port 137/UDP, (multicast?, broadcast?, unicast?)
• Provides serverless NetBIOS name <--> IP translation
• Can also use central WINS server(s)
  • WINS server can replicate and automatically discover replication partners (see [MS-WINSRA]
• Superseded since Win2000 by hierarchical dynamic DNS updates (see Section Hierarchical dynamic DNS updates.
  • Dynamic DNS is centralized. Sends Name <--> IP mapping updates to DNS Server
  • Exchange, and MS-SQL (2000 and 2003) still require WINS.
  • LLMNR (see my other site) adds serverless name resolution using mulicast (introduces with WinVista). Might make WINS really obsolete.

2.2   Session service

• Runs on port 139/TCP
• See RFCs for details
• Basic Idea
  • Establish TCP connection
  • Originator sends NetBIOS session request message (type=0x81) (this includes information about the caller and callee, like their WINS / NetBIOS names).
  • Responder sends response (e.g., type=0x82 if session is accepted). But can also deny or send a redirect.
  • Messages are exchanged. These are of type 'session message' (type=0x00). The session message is 4 bytes NetBIOS specific information followed by the payload. SMB is carried in this payload. The first couple of bytes of payload are SMB's magic Note, that the NetBIOS message header specifies the length of the payload.
  • NetBIOS also specifies Keepalives messages, but I don't know whether these are used by Microsoft. They have type=0x85
  • No other services or communication provided by session service

2.3   Datagram service

• Runs on port 138/UDP
• See RFC for details
• Basic idea:
  • Each datagram has caller, callee, etc. header, followed by payload.
  • Has some sort of support for fragmentation, however, I don't know if Microsoft uses this and even they do, why it is necessary, as IP should handle that on its own.
  • SMB is carried as payload of the NetBIOS datagram
  • Unknown which SMB messages use datagram service, as it is unreliable

3   SMB revisited

• If used over NetBIOS see above.
• If used native (port 445/port), each SMB message is preceded by a shim NetBIOS 'session message' prefix (type 0x00, 4 bytes long, includes the length of the message). Presumably this is required to specify the length of the message. No NetBIOS session establishment (types 0x81, 0x82 are used on port 445!)
• SMB2 still has this 4 byte prefix!
• See protocol specs below.

4   Hierarchical dynamic DNS updates

• Superseded WINS. But requires a central DNS server.
• Are SRV RRs relevant here??
• TODO

5   References

5.1   Information and Overview

1. Wikipedia SMB site
2. Wikipedia NetBIOS site
3. Microsoft: Understanding dynamic DNS Update
4. My notes on Zeroconf, Bonjour, and LLMNR
5. Microsoft: How WINS technology works
6. Wikipedia Active Directory page

5.2   Specifications

1. NetBIOS over TCP/IP spec (name services, datagram service, session service)
   • RFC 1001
   • RFC 1002
   • Microsoft's NetBIOS over TCP/IP extensions [MS-NBTE]
2. RFC 2136 Dynamic DNS updates Spec
3. SMB protocol spec [MS-SMB]
4. SMB2 protocol spec [MS-SMB2]
5. WINS Replication and Autodiscovery spec (for servers only) [MS-WINSRA]

----------------------------------------------------------------------------------------------------------------------------------

https://technet.microsoft.com/ko-kr/library/cc725802.aspx

WINS(Windows Internet Name Service) 개요

적용 대상: Windows Server 2008 R2

WINS(Windows Internet Name Service)는 컴퓨터 NetBIOS 이름을 IP 주소로 매핑하는 컴퓨터 이름 등록 및 확인 서비스입니다. 네트워크에 WINS 서버를 배포하면 최종 사용자는 기억하기 어려운 IP 주소를 사용하지 않고 이름을 사용하여 네트워크 리소스에 액세스할 수 있습니다. 또한 컴퓨터에서 실행되는 소프트웨어와 기타 서비스, 그리고 기타 장치에서 WINS 서버에 대해 이름 쿼리를 수행하여 이름을 통해 IP 주소를 확인할 수 있습니다.

WINS 서버에서 제공하는 기능

TCP/IP 기반 네트워크를 관리할 때 WINS에서는 다음과 같은 이점을 제공합니다.

• 동적 이름-주소 간 데이터베이스를 통해 컴퓨터 이름 등록 및 확인에 대한 지원을 유지 관리할 수 있습니다.
  
  
• 이름-주소 간 데이터베이스의 중앙 관리를 통해 Lmhosts 파일을 관리해야 할 필요성을 줄일 수 있습니다.
  
  
• 클라이언트에서 WINS 서버를 쿼리하여 원격 시스템을 직접 찾을 수 있게 함으로써 서브넷에 대한 NetBIOS 기반 브로드캐스트 트래픽을 줄일 수 있습니다.
  
  
• 각 서브넷에 로컬 도메인 컨트롤러가 없어도 이전 버전의 Microsoft(R) Windows(R) 클라이언트와 NetBIOS 기반 클라이언트에서 원격 Windows 도메인 목록을 찾아볼 수 있게 함으로써 네트워크에서 이러한 유형의 클라이언트를 지원할 수 있습니다.
  
  
• WINS 조회 통합이 구현되어 있을 경우 DNS 기반 클라이언트에서 NetBIOS 리소스를 찾을 수 있게 함으로써 이러한 클라이언트를 지원할 수 있습니다.
  
  

WINS 클라이언트에 대한 이름 확인은 모든 Microsoft NetBT(NetBIOS over TCP/IP) 클라이언트가 네트워크에서 NetBIOS 이름 쿼리를 확인할 때 사용하는 동일한 이름 확인 프로세스를 확장한 것입니다. 실제로 이름을 확인하는 방법은 사용자에게 투명합니다.

Windows XP 및 Windows 2000의 경우 WINS 클라이언트에서는 net use 또는 이와 유사한 NetBIOS 기반 응용 프로그램을 사용하여 쿼리를 수행한 다음 아래 순서에 따라 이름을 확인합니다.

1. 이름이 15자를 넘는지 또는 이름에 마침표(".")가 포함되어 있는지 확인합니다. 해당되는 경우 DNS에 이름을 쿼리합니다.
   
   
2. 클라이언트의 원격 이름 캐시에 이름이 저장되어 있는지 확인합니다.
   
   
3. 구성된 WINS 서버에 연결하여 WINS를 통해 이름 확인을 시도합니다.
   
   
4. 서브넷에 로컬 IP 브로드캐스트를 사용합니다.
   
   
5. 이 연결에 대한 인터넷 프로토콜(TCP/IP) 속성에서 LMHOSTS 조회 가능이 사용하도록 설정되어 있을 경우 Lmhosts 파일을 확인합니다.
   
   
6. Hosts 파일을 확인합니다.
   
   
7. DNS 서버를 쿼리합니다.
   
   

WINS 서버의 구성 요소

WINS는 WINS 서버와 WINS 클라이언트라는 두 가지 주요 구성 요소로 이루어집니다. 일부 구성에서는 WINS 프록시가 사용됩니다.

WINS 서버

WINS 서버는 WINS 클라이언트에서 보낸 이름 등록 요청을 처리하고, 해당 이름과 IP 주소를 등록합니다. 또한 클라이언트에서 NetBIOS 이름 쿼리를 보내면 해당 이름이 서버 데이터베이스에 있을 경우 쿼리된 이름의 IP 주소를 반환하여 응답합니다.

IP 주소에 매핑되는 NetBIOS 컴퓨터 이름을 포함하는 데이터베이스의 내용을 다른 WINS 서버로 복제하도록 WINS 서버를 구성할 수도 있습니다. 워크스테이션 컴퓨터와 같은 WINS 클라이언트가 네트워크에서 시작되면 구성된 주 WINS 서버로 해당 컴퓨터 이름과 IP 주소가 등록 요청과 함께 직접 보내집니다. 서버에서 이러한 클라이언트를 등록하기 때문에 서버는 데이터베이스에서 클라이언트 레코드의 소유자가 됩니다.

WINS 데이터베이스

WINS 데이터베이스에는 네트워크에 대한 NetBIOS 이름-IP 주소 간 매핑이 저장됩니다. 데이터베이스 내용이 "밀어 넣어지는" 복제 파트너와 함께 WINS 서버를 구성하는 경우 로컬 서버의 데이터베이스 내용이 복제 파트너 서버로 복제됩니다. 복제 파트너를 "끌어오기" 파트너로 구성한 경우 원격 WINS 서버의 레코드가 로컬 데이터베이스로 복사됩니다. WINS 콘솔이라고도 하는 WINS 스냅인을 사용하여 WINS MMC(Microsoft Management Console)에서 이 복제 이벤트가 발생하는 간격을 구성할 수 있습니다.

또한 WINS 콘솔에서는 WINS 서버 데이터베이스를 유지 관리, 표시, 백업 및 복원하는 데 필요한 도구를 제공하며, WINS 서버에서 다른 파일을 백업할 때마다 데이터베이스를 백업합니다.

WINS 클라이언트

WINS 클라이언트는 시작되거나 네트워크에 가입될 때 WINS 서버에 해당 이름을 등록하려고 시도합니다. 그런 다음 클라이언트는 필요에 따라 WINS 서버를 쿼리하여 원격 이름을 확인합니다.

WINS 사용 클라이언트는 WINS 서버를 직접 사용하도록 구성할 수 있는 컴퓨터입니다. 일반적으로 대부분의 WINS 클라이언트에는 NetBIOS 이름이 두 개 이상 있으며, 네트워크에서 사용하려면 이 이름을 등록해야 합니다. 이러한 이름은 메신저나 워크스테이션 서비스와 같은 다양한 유형의 네트워크 서비스를 게시하는 데 사용되며, 이러한 서비스는 각 컴퓨터에서 다양한 방법으로 네트워크의 다른 컴퓨터와 통신하는 데 사용할 수 있습니다.

WINS 프록시

WINS 프록시는 WINS를 직접 사용할 수 없는 다른 호스트 컴퓨터를 대신해서 작동하도록 구성된 WINS 클라이언트 컴퓨터입니다. WINS 프록시는 라우팅된 TCP/IP 네트워크에 있는 컴퓨터의 NetBIOS 이름 쿼리를 확인하는 데 도움이 됩니다.

기본적으로 대부분의 컴퓨터에서는 WINS 브로드캐스트를 사용하여 NetBIOS 이름 쿼리를 확인할 수 없으며, NetBIOS 이름을 네트워크에 등록할 수 없습니다. 이러한 컴퓨터 대신 수신을 하고, 브로드캐스트에 의해 확인되지 않는 이름을 WINS 서버에 쿼리하도록 WINS 프록시를 구성할 수 있습니다.

WINS 프록시는 NetBIOS 브로드캐스트 전용 클라이언트 또는 b 노드 클라이언트가 포함된 네트워크에서만 유용하거나 필요합니다. 대부분의 네트워크에서는 WINS 사용 클라이언트가 일반적이며 대개 WINS 프록시는 필요하지 않습니다.

WINS 프록시는 b 노드 NetBIOS 이름 서비스 기능(이름 등록, 이름 해제 및 이름 쿼리)을 수신하며, 로컬 네트워크에서 사용되지 않는 원격 이름에 응답할 수 있습니다. 프록시는 WINS 서버와 직접 통신하여 이러한 로컬 브로드캐스트에 응답하는 데 필요한 정보를 검색합니다.

WINS 프록시는 다음 방법으로 사용됩니다.

• b 노드 클라이언트가 이름을 등록하는 경우 프록시는 WINS 서버 데이터베이스에서 해당 이름을 확인합니다. WINS 데이터베이스에 이름이 있으면 프록시는 이름을 등록하려는 b 노드 클라이언트에 등록 거절 응답을 보냅니다.
  
  
• b 노드 클라이언트가 이름을 해제하는 경우 프록시는 원격 이름 캐시에서 클라이언트 이름을 삭제합니다.
  
  
• b 노드 클라이언트에서 이름 쿼리를 보내면 프록시는 원격 이름 캐시에 로컬로 포함된 정보 또는 WINS 서버로부터 받은 정보를 사용하여 이름을 확인하려고 시도합니다.
  
  

WINS 서버 관리

WINS 서버를 관리할 때 주로 사용하는 도구는 WINS 콘솔과 WINS용 Netsh 명령입니다.

WINS 콘솔

WINS 콘솔은 MMC(Microsoft Management Console) 스냅인입니다.

WINS 서버를 설치한 후 WINS 콘솔 또는 Netsh WINS 명령을 사용하여 다음과 같은 기본 서버 관리 작업을 수행할 수 있습니다.

1. 네트워크에서 사용되는 클라이언트 이름에 대해 WINS 서버에 저장된 NetBIOS 이름 등록을 보고, 필터링할 수 있습니다.
   
   
2. WINS 서버의 복제 파트너를 추가 및 구성할 수 있습니다.
   
   
3. WINS 서버 데이터베이스에서 백업, 복원, 압축, 청소 등의 유지 관리 작업을 수행할 수 있습니다.
   
   

또한 WINS 콘솔 또는 Netsh WINS 명령을 사용하여 다음과 같은 선택적 설정 작업 또는 고급 설정 작업을 수행할 수 있습니다.

갱신 간격과 서버 데이터베이스에 저장된 이름 레코드를 등록, 갱신 및 확인할 때 사용하는 기타 간격을 비롯한 WINS 속성을 보고, 수정할 수 있습니다.

• 네트워크에서 사용하기 위해 필요한 경우 정적 WINS 매핑을 추가 및 구성할 수 있습니다.
  
  
• 네트워크 전체에서 사용되는 WINS 서버 데이터에 나타나는 WINS 레코드를 삭제하거나 삭제 표시합니다.
  
  

WINS용 Netsh 명령

명령 프롬프트 창에서 netsh wins> 명령 프롬프트에 Netsh WINS 명령을 입력하거나 배치 파일 및 기타 스크립트에서 Netsh WINS 명령을 실행할 수 있습니다. WINS 콘솔에서 사용할 수 있는 모든 기능을 netsh wins> 명령 프롬프트에서도 사용할 수 있습니다.