|
|
Once long ago, there was a buzzword referred to as DCE/RPC. This stood for Distributed Computing Environment / Remote Procedure Calls, and conceptually was a good idea. It was originally developed by Apollo/HP as NCA 1.0 (Network Computing Architecture) and only ran over UDP. When there was a need to run it over TCP so that it would be compatible with DECnet 3.0, it was redesigned, submitted to The Open Group, and officially became known as DCE/RPC. Microsoft came along and decided, rather than pay $20 per seat to license this technology, to reimplement DCE/RPC themselves as MSRPC. From this, the concept continued in the form of SMB (Server Message Block, or the "what") using the NetBIOS (Network Basic Input/Output System, or the "how") compatibility layer. You can run SMB (i.e., transport) over several different protocols; many different implementations arose as a result, including NBIPX (NetBIOS over IPX, NwLnkNb, or NWNBLink) and NBT (NetBIOS over TCP/IP, or NetBT). As the years passed, NBT became the most common form of implementation until the advance of "Direct-Hosted TCP" -- the Microsoft marketing term for eliminating NetBIOS entirely and running SMB by itself across TCP port 445 only. As of yet, direct-hosted TCP has yet to catch on. And so the story goes...
Perhaps the best summary of the origins of SMB are voiced in the 1997 article titled, CIFS: Common Insecurities Fail Scrutiny: "Several megabytes of NT-security archives, random whitepapers, RFCs, the CIFS spec, the Samba stuff, a few MS knowledge-base articles, strings extracted from binaries, and packet dumps have been dutifully waded through during the information-gathering stages of this project, and there are *still* many missing pieces... While often tedious, at least the way has been generously littered with occurrences of clapping hand to forehead and muttering 'crikey, what are they *thinking*?!'"
Anyone even remotely considering getting involved in implementing a Samba server should review the articles listed at the end of this document from Linux Magazine for some useful background material. If you don't understand the concepts of the tools you're working with, it will be a long and difficult road ahead indeed!
Download the files:
$ wget http://us1.samba.org/samba/ftp/samba-2.2.6.tar.gz
$ wget http://us1.samba.org/samba/ftp/samba-2.2.6.tar.gz.asc
It's recommended that you verify the PGP signature for the Samba source file before doing anything else. Download the Samba PGP Public Key file from http://us1.samba.org/samba/ftp/samba-pubkey.asc and run:
$ gpg --import samba-pubkey.asc
$ gpg --verify samba-2.2.6.tar.gz.asc
If you receive a message like, "Good signature from Samba Distribution Verification Key..." then all is well. The warnings about trust relationships can be ignored. Next, extract the package and change into the /source subdirectory.
|
|
helps you to to avoid headaches later when you decide you want to mount remote smb filesystems |
|
|
changes the Samba man page destination from the default of /usr/local/samba/man/ |
|
|
changes the logfile destination from the default of /usr/local/samba/logs/ |
$ tar xzf samba-2.2.6.tar.gz
$ cd samba-2.2.6/source
$ ./configure --with-logfilebase=/var/log/samba --with-smbmount --mandir=/usr/man
$ make
# make install
Samba's configuration file resides
in
/usr/local/samba/lib/smb.conf
and by default doesn't exist;
you'll need to create it with your favorite text editor. A good way to determine
what the default values will be is to create an empty smb.conf file (touch smb.conf),
run testparm against it, and grep for the value you're curious about. For those
that just want to get started, here's a quick & dirty (although not secure)
smb.conf to try out:
# This is /usr/local/samba/lib/smb.conf
[global]
netbios name = BIGSERVER
workgroup = WORKGROUP
log level = 2
log file = /usr/local/samba/var/samba.log
security = share
[pub]
path = /home/public
browseable = yes
guest ok = yes
read only = no
You'll want to make sure that /home/public does indeed exist, and with the appropriate directory permissions to allow access for the above example. When ready, launch the Samba dameon with:
# /usr/local/samba/bin/smbd -D
# /usr/local/samba/bin/nmbd -D
When you run the smbd daemon, you should be able to verify that all is working by examining the /usr/local/samba/var/samba.log file for something like:
[2002/10/31 14:54:21, 2] lib/interface.c:add_interface(81)
added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
[2002/10/31 14:54:21, 2] smbd/server.c:open_sockets(215)
waiting for a connection
Additionally, you can verify the nmbd name service daemon is running by examining /usr/local/samba/var/log.nmbd for something similar to:
[2002/10/31 14:57:31, 0] nmbd/nmbd.c:main(794)
Netbios nameserver version 2.2.6 started.
Copyright Andrew Tridgell and the Samba Team 1994-2002
[2002/10/31 14:57:31, 1] lib/debug.c:debug_message(258)
INFO: Debug class all level = 2 (pid 23684 from pid 23684)
[2002/10/31 14:57:31, 2] nmbd/nmbd.c:main(832)
Becoming a daemon.
[2002/10/31 14:57:31, 2] lib/interface.c:add_interface(81)
added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
[2002/10/31 14:57:31, 2] nmbd/nmbd_subnetdb.c:make_subnet(192)
making subnet name:192.168.1.1 Broadcast address:192.168.1.255 Subnet mask:255.255.255.0
[2002/10/31 14:57:31, 2] nmbd/nmbd_subnetdb.c:make_subnet(192)
making subnet name:UNICAST_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0
[2002/10/31 14:57:31, 2] nmbd/nmbd_subnetdb.c:make_subnet(192)
making subnet name:REMOTE_BROADCAST_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0
On your Windows machine, click on Start / Run and type "\\BIGSERVER\PUB" (minus quotes). You should find that all works well. If not, see the next section...
If you want to easily start and stop your smbd/nmbd daemons with a minimum of fuss, you can use the following script. Note that any active clients won't like you for it, especially if they're running Microsoft Access on an open networked file ;-)
#!/bin/sh
# Start/stop/restart samba
samba_start() {
echo "Starting smbd"
/usr/local/samba/bin/smbd -D:
echo "Starting nmbd"
/usr/local/samba/bin/nmbd -D
}
samba_stop() {
echo "Stopping smbd nmbd"
killall smbd nmbd
}
samba_restart() {
samba_stop
sleep 1
samba_start
}
case "$1" in
'start')
samba_start
;;
'stop')
samba_stop
;;
'restart')
samba_restart
;;
*)
echo "usage $0 start|stop|restart"
esac
Below are a few of the more interesting additional configuration bits you might be interested in.
# Do you run your samba server on a machine that has a valid IP address to the Internet?
# For such a risky venture, you'll need to limit the interfaces on which Samba will run.
# A common mistake is to set the interfaces line to the specific IP address of the box,
# when it is actually the IP subnet that your interface is on that you want to use.
interfaces = 192.168.0.0/16 127.0.0.1
bind interfaces only = Yes
# Encrypted passwords -- I would, wouldn't you?
# Windows 95 and 95a clients may have problems here;
# in which case you'll need to turn this off instead
encrypt passwords = Yes
# Allow clients to issue a NET TIME \\SERVERNAME /SET /YES command
# to synchronize the clocks.
time server = Yes
# Here's a nifty optimization trick: Set the socket options below, and start Samba.
# Find a large file or create one yourself (e.g., `dd if=/dev/zero of=testfile count=1024 bs=1024`).
# Disable any of your client's anti-virus software, restart Samba, then take the file and copy it to
# the server while timing how long it takes (SO_RCVBUF).
# Restart Samba (to flush the memory cache) and copy the file back to your workstation,
# timing the result (SO_SNDBUFF).
# Lather, rinse, & repeat with different values in increments/decrements of 1024.
# Find your optimum values for the server and use them.
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
# Use this if you don't plan to run Samba as a PDC.
# Temporarily comment this out while you are adding machines to your PDC domain
invalid users = root @wheel
# Unreadable files where the Linux permissions don't allow access won't show up in the client's file listings
hide unreadable = Yes
# Don't allow access to any of the following files.
# Useful for preventing the spread of virus infections on your server
# should a Windows-connected client become infected.
# The last match bit prevents accessing files with a CLSID in its file extension
veto files = /*.exe/*.dll/*.com/*.vbs/*.{*}/
# Hide the following files; the client can still choose to alter their view settings to show hidden files.
hide files = /example.txt/*.bad/
You've configured your server and can't seem to get it working. Chances are you're uncertain how to proceed. But don't panic; there are some useful things you can do to determine where the problem is. At a minimum, you should be running the latest stable version of Samba and have reviewed the steps outlined in /docs/textdocs/DIAGNOSIS.TXT in the source file. Don't be suprised if nobody answers your questions if you haven't followed the steps outlined in that document ;-) In addition, here are a few things you should check:
Is your Windows client on the same subnet as your Samba server?
Does the WINS server your Windows client is using know about your Samba server? Better yet, is your Windows client configured to use the Samba server as its WINS server, and is the Samba server configured to run the WINS service via nmbd?
Is there a firewall running on the Samba server? Note that this happens more often than not! ;-)
Did you use SWAT to configure your smb.conf file? Try starting over from scratch using your favorite text editor first before you get fancy. Trust me, it's simpler, less can go wrong, and forces you to dive in and get your hands dirty ;-)
Are you using the default smb.conf file that came with the source? Use this only as a template and create a new, blank smb.conf file with only the minimum statements you need. I.e., if you end up sending your smb.conf file to someone for assistance, it looks bad if 90% of it is commented out from the original sample template, but then again, that's just me talking...
Are you trying to see the shares via Network Neighborhood? This list is updated only once every fifteen minutes, and is not accurate. Use NET VIEW instead
Did you turn on debugging to at least log level 3 and review the results?
Again, don't panic. The solution is there; you just have to do the work to determine the cause of the problem. If you're certain you've exhausted your options and have read and followed the steps in DIAGNOSIS.TXT, you can always post your question to one of the Samba mailing lists located at http://lists.samba.org/. It also might not hurt to review How to Ask Questions the Smart Way by Eric Raymond.
Opportunistic locking essentially means that the client is allowed to download and cache the file on their hard drive while making changes; if a second client wants to access the file, the first client receives a break and must sync the file back to the server. This can give significant performance gains in some cases; in others, some programs insist on syncing back the contents of the entire file for a single change.
Oplocks should be disabled if you are accessing the same files from both Unix/Linux and SMB clients. They should also be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, as any break the first client receives will result in the entire file needing to be sync'd (not just the single record), which will result in a noticable performance delay and, more likely, problems accessing the database in the first place.
You can disable oplocks on a per-share basis with the following:
oplocks = False
level2oplocks = False
Alternately, you could disable oplocks
on a per-file basis within the share:
veto oplock files = /*.mdb/*.MDB/
If you're working in a Linux/Windows mixed environment, you're bound to come across files that are littered with '^M' at the end of every line. This is the Windows command for 'newline', which uses a combination of CR/LF, whereas Linux uses just the single LF. To convert a text file from DOS to Linux, thereby removing the '^M' newline characters in the file, use the fromdos command:
fromdos <dosfile >linuxfile
To convert a text file from Linux to DOS, thus adding the '^M' newline characters so that the file can be read by your Windows clients, use todos:
todos <linuxfile >dosfile
Alternately, if you find you don't have the fromdos/todos utilities, you can try this simple trick:
cat dosfile | col -b > linuxfile
It's worth noting that if you're running into this problem in the first place, it means you're working on a file that is being edited in both your Linux and Windows environments. As such, you should probably read the section on Oplocks to prevent any data loss...
If you'd rather take care of things from the Windows side of the coin, you can simply use a text editor that can convert between DOS/Linux. My personal favorite is Jean-Pierre Menicucci's Editeur which includes syntax highlighting, although you're encouraged to look around for what fits your needs best.
If you're running your Samba server to act as a Primary Domain Controller (PDC) for Windows clients, you can have a batch file execute upon login. This can be enabled by adding the following to your smb.conf file:
[global]
logon script = %m.bat
See VARIABLE SUBSTITUTIONS in the man page for smb.conf for a full list of potential variables. Common ones include the username of the current service (%u), the session username that the client wanted - not necessarily what they got (%U), the primary group name of the user (%g), and the NetBIOS name of the client computer (%m).
All login scripts must reside in the [netlogon] share (see Running Samba as a PDC) and should be formatted to be readable by your Windows clients (see Line Feeds CR/LF). Here's a sample script which I find to be quite useful:
@echo off
REM Synchronize the client's clock with the server. Requires Power User rights, however
NET TIME \\SERVERNAME /SET /YES
REM Map a drive
NET USE I: \\SERVERNAME\INSTALL /YES
REM Map the user's home directory
NET USE P: \\SERVERNAME\HOMES /YES
REM Run Symantec Liveupdate (silently) for Antivirus definitions.
REM Does not require the user to have local adminstrator rights ;-)
IF EXIST "C:\Program Files\Symantec\LiveUpdate\Luall.exe" "C:\Program Files\Symantec\LiveUpdate\Luall.exe" -s
REM Run WinNT/2K/XP specific stuff
IF NOT "%OS%"=="Windows_NT" goto endit
REM Stop the protected storage service to disable password caching on web pages
NET STOP "Protected Storage"
NET START "Automatic Updates"
REM Back up the client's registry
REGEDIT /E P:\Registry.bak
REM Update (silently) the client's registry
REGEDIT /S "\\SERVERNAME\NETLOGON\Update.reg"
REM If you're not using client profiles, this helps back up the client's data very nicely
IF NOT EXIST P:\Backup MKDIR P:\Backup
XCOPY "%USERPROFILE%\*.*" "P:\Backup\*.*" /S /E /C /H /R /Y /D
:endit
To run as a Primary Domain controller (PDC), you will need to add the following entries added to your smb.conf file:
[global]
admin users = root
domain logons = yes
domain master = yes
logon drive = H:
logon home = \\BIGSERVER\%u
os level = 99
preferred master = yes
security = user
wins support = yes
[homes]
create mode = 0600
directory mode = 0700
path = %H
read only = no
valid users = %S
[netlogon]
path = /home/netlogon
Use the Group Policy editor (gpedit.msc) and disable the "Domain Member: Digitally encrypt or sign secure channel data". Alternately, you can make the following change to the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
On the Samba server, add an entry for the NetBIOS machine name of the client that will be joining the domain to the /etc/passwd file. You'll want to use a unique group id (gid) as well. Note the addition of the dollar sign ($) to the NetBIOS machine name. For example, if your machine's name was "pc14", the entry in the /etc/passwd file would be:
pc14$:x:400:400:Workstation:/dev/null:/bin/false
Next, add an entry for the machine into your SMB password file. The -m switch tells smbpasswd to treat this account as a machine account. Note the lack of the dollar sign ($) here.
/usr/local/samba/bin/smbpasswd -m -a pc14
And add another entry, if you haven't yet, for the only username that can join workstations to domains (at least, with the current version of Samba). Make sure to use a different password than the actual root account.
/usr/local/samba/bin/smbpasswd -a root
On the client computer, log in as the local Administrator. It won't consistently work if you log in as another user that also has Local Admin rights. Then open up the My Computer icon, select Tools, then Disconnect Network Drive. Disconnect all the connections that are on the Samba server. You might be suprised; some connections occur that never show up in the My Computer icon; you have to actually force the disconnection in this manner. Next, right-click on the My Computer icon and choose Properties, then the Computer Name tab. Click the "Change" button, select Domain, and enter the name of the domain that you are going to join. You'll be prompted for a username/password pair; enter the username of "root" and the root smb password. If this works, you'll be welcomed to the domain!
If this doesn't work, try rebooting
and increase the logging level on your Samba server to see which step you might
be missing. Note that each workstation must have an entry in the DNS
and/or in the file
/etc/hosts (not
/usr/local/samba/lib/lmhosts),
or they won't be able to log in.
It is critical that you understand the difference between a Windows Local User and a Windows Domain User. The same goes for Local Groups and Domain Groups. If you're not clear on the difference, it's time to hit the books and study for that MCSE again, as you'll have nothing but headaches. In a nutshell, Local Users and Local Groups exist only on the workstation; they have nothing to do with the Samba server, which could care less about such things. However, if you want to allow a Domain User to log in to a workstation and use, for example, the NET TIME command to set the workstation's clock, you'll need to make sure that the workstation knows that this is allowed behavior via the Group Policy Editor. To understand how to use the Group Policy Editor on Windows XP, see Microsoft's Technet article Q307882 on their website.
Again, if you don't know what any of this is, it's time to hit those MCSE books again; this is a tutorial on Samba concepts, not on Windows concepts ;-)
If you'd like to enable roaming profiles for Win2k/XP clients, and you're already configured to act as a domain controller, make the following changes to your smb.conf file. You'll need to be running Samba 2.2.6 to support WinXP SP1 clients. Whatever you do, don't place the profile acls parameter in the global section, otherwise you'll find all sorts of things will start to act up ;-) Instead of using profile acls, you could read Microsoft's Technet article Q327462 and follow their instructions for enabling the "Do not check for user ownership of Roaming Profile Folders" setting on your WinXP SP1 clients.
[global]
logon path = \\BIGSERVER\profile\%U
[profile]
create mode = 0600
directory mode = 0700
path = /home/profile
profile acls = yes
read only = no
"System error 6118 has occurred. The list of servers for this workgroup is not currently available". You have enabled the Internet Connection Firewall (ICF), which disables SMB ports by default.
"System error 53 has occurred. The network path was not found.". You have disabled NetBIOS over TCP/IP (NetBT), even if you are only using direct-hosted SMB over TCP/IP.
"The Messenger service terminated with service-specific error 2270". Your computer name, username, and domain name are not all set to unique (different) values.
This is a frequently asked question by system administrators wishing to secure remote SMB traffic. It is technically in the realm of SSH, but will be touched on briefly here. However, please note that even running SMB by itself without SSH over a 56k dialup line is still terribly slow to the point of frustration. If you don't have a high speed link, you probably don't even want to deal with tunneling over SSH as a result.
The good news is that tunneling works, even though you can only tunnel TCP. This works for both SMB NetBIOS and SMB Direct-Hosted. The unfortunate news is that due to a design limitation in the GUI API of Windows 95/98/ME, you'll only be able to perform your tunneled work in a MS-DOS window. Once you step outside of this and attempt to interact with your remote server via the GUI, you'll find 30-60 second periods where the computer will pause/hang, after which it will complain that the path is invalid or unavailable. One possible explanation is the 16/32-bit nature of this type of Windows OS, however there has yet to be a confirmation of this by either Microsoft or the Samba team. Those using the 32-bit Windows 2000/XP systems will not have this limitation whatsoever.
Since UDP tunneling is not available
under SSH, on your Windows 2000/XP box you'll need to create an entry in your
%systemroot%\System32\drivers\etc\LMHOSTS file:
127.0.0.1 FAKENAME #PRE
Where
FAKENAME is a
bogus NetBIOS name that you will use to refer to your Samba server. This file
will not be reread until you reboot unless you issue the following command (note
the uppercase-R):
nbtstat -R
Configure your client's SSH program to forward port 139/tcp to port 139/tcp on the server, and connect via SSH. Once done, open up a MS-DOS window and issue this command:
NET VIEW \\FAKENAME
Viola! It works, and you can confirm the encryption with a packet filter.
SMB (Server Message Block) - SMB is a file sharing protocol, that uses a computer name and numerical type to create a NetBIOS name. Developed in 1983 by IBM and The Open Group, and reimplemented by Microsoft.
CIFS (Common Internet Filesystem) - Around 1996, Microsoft apparently decided that SMB needed the word "Internet" in it, so they changed it to CIFS. The change is essentially cosmetic marketing hype, however there are those who would disagree.
DCE/RPC (Distributed Computing Environment / Remote Procedure Calls) - Developed by Apollo/HP and The Open Group and reimplemented by Microsoft as MSRPC
IPC (Inter-process Communication) - A method to communicate specific information between programs.
NetBIOS - Network Basic Input/Output System. This is a standard which was originally developed for IBM by Sytek in 1983. To exaggerate the analogy a bit, it can help to think of this in comparison your computer's BIOS -- it controlls the essential functions of your input/output hardware -- whereas NetBIOS controlls the essential functions of your input/output traffic via the network. Again, this is a bit of an exaggeration but it should help that paradigm shift. What is important to realize is that NetBIOS is a transport standard, not a protocol. Unfortunately, even technically brilliant people tend to interchange NetBIOS with terms like NetBEUI without a second thought; this will cause no end (and no doubt) of confusion.
NetBEUI -IBM first introduced the "NetBIOS Extended User Interface" (NetBEUI) in 1985 as an extension to the NetBIOS standard. Unlike NetBIOS, NetBEUI is a protocol, not a standard. It is also not routable, so traffic on one side of a router will be unable to communicate with the other side. Understanding NetBEUI is not essential to deciphering SMB; however it helps to point out that it is not the same as NetBIOS and to improve your score in trivia at parties. NetBEUI was originally referred to by Microsoft as "NBF", or "The Windows NT NetBEUI Frame protocol driver". It is not often heard from these days.
NBT - "NetBIOS over TCP", or "NetBT". Allows the continued use of NetBIOS traffic proxied over TCP/IP. As a result, NetBIOS names are made equivilant to IP addresses and NetBIOS name types are conceptually equivilant to TCP/IP ports. This is how file and printer sharing are accomplished in Windows 95/98/ME. They traditionally rely on three ports: NetBIOS Name Service (nbname) via UDP port 137, NetBIOS Datagram Service (nbdatagram) via UDP port 138, and NetBIOS Session Service (nbsession) via TCP port 139. All name resolution is done via WINS, NetBIOS broadcasts, and DNS. NetBIOS over TCP is documented in RFC 1001 (Concepts and methods) and RFC 1002 (Detailed specifications).
"Direct-Hosted" TCP - This is the new Microsoft marketing term used to describe a new method of file and printer sharing in Windows 2000/XP, which uses only TCP and UDP port 445. All name resolution is done via DNS. Note that by default, Windows 2000/XP use both NBT and Direct Hosted traffic (you can disable this in the WINS properties tab). If a client supports both direct-hosted and NBT, both methods are tried and the first type to respond is used. In direct-hosted traffic, a 4-byte header precedes the SMB traffic. The first byte is always 0x00, and the remaining three bytes are the length of the remaining data. So, if you simply switch off NBT support in favor of direct-hosted tcp, it simply removes one route by which the SMB server can be contacted.
Traditionally, SMB uses UDP port 137 (NetBIOS name service, or netbios-ns), UDP port 138 (NetBIOS datagram service, or netbios-dgm), and TCP port 139 (NetBIOS session service, or netbios-ssn). Anyone looking at their network with a good packet sniffer will be amazed at the amount of traffic generated by just opening up a single file!
Microsoft mainly provides file and printer sharing via two different methods:
NetBIOS over TCP: All current versions of Windows support this method of file/print sharing.
Direct-Hosted:SMB traffic via TCP without the use of NetBIOS. This is available only on Windows 2000/XP as an alternative to the former method of file/print sharing. This has the advantage of removing dependence on WINS & NetBIOS broadcasts for name resolution.
In general, SMB sessions are established in the following order:
TCP Connection - establish connection to port 139 or 445.
NetBIOS Session Request - using NetBIOS names of your machine and the server.
SMB Negotiate Protocol - determine the protocol dialect to use.
SMB Session Startup
SMB Tree Connect
Protocol dialects (from SMB Negotiate Protocol, step 3 above) are selected from one of the following:
PC Network Program 1.0 (Core) - share level security mode only
Microsoft Networks 1.03 (Core Plus) - share level security mode only
Lanman1.0 (LAN Manager 1.0) - uses Challenge/Response Authentication
Lanman2.1 (LAN Manager 2.1) - uses Challenge/Response Authentication
NT LM 0.12 (NT LM 0.12) - uses Challenge/Response Authentication
In the Session Startup (step 4, above) Passwords are encrypted (or not) according to one of the following methods:
Null (no encryption)
Cleartext (no encryption)
LM and NTLM
NTLM
NTLMv2
A good way to examine this process in depth is to try out SecurityFriday's SWB program, which allows you to enables the SMB(CIFS) session setup without depending on the version and the registry setting of your Windows machines.
Problem: You want
to determine whether or not you are successfully able to query your server's
nmbd WINS service and are not being blocked by firewalling, misconfiguration,
etc.
Solution: On the Samba box, run `tcpdump port 137 -n` and on
the Windows box run `net view /domain:yourdomainname` from a command prompt.
A successful query should look like this:
10:29:16.793821 windows-client.137
> samba-server.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
10:29:16.793876 samba-server.137 > windows-client.137: NBT UDP PACKET(137):
QUERY; POSITIVE; RESPONSE; UNICAST (DF)
An indication that your Windows computer is not using Samba's nmbd WINS service would look like this:
10:29:29.756281 windows-client.137
> subnet-broadcast-address.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
Andrew Tridgell's interview with the Financial Review October 2002
Just what is SMB? by Richard Sharpe
Using Samba as a PDC, Linux Magazine February 2002
Understanding the Network Neighborhood, Linux Magazine May 2001
The Story of Samba: Linux's Stealth Weapon, Linux Magazine September 1999
Samba - Opening Windows Everywhere, Linux Magazine May 1999
SMB HOWTO, The Linux Documentation Project
RFC 1088 - Standard for the transmission of IP datagrams over NetBIOS networks
Implementing CIFS - The Common Internet File System
Microsoft's description of some of the protocols, from the days of Windows NT 3.5
