[Samba] samba without netbios
William Burns
bburns at aeroflex.com
Thu Oct 27 01:42:45 GMT 2005
John H Terpstra wrote:
>OK - I'll try to answer this.
>
>Originally Windows networking used only NetBIOS over TCP/IP.
>
>
.....
>Now, please send me documentation updates as your contribution to help others
>like yourself from getting sucked into the same whirlpool.
>
>
Um, Ok. I hope you don't end up regretting the request.
I tried cram in everything I've run across..
If it holds up to scrutiny, I can look for ways to integrate this into
the current docs.
------------
SAMBA, naming services, "NetBIOS-over TCP/IP", and the potential for
NetBIOS-less SMB protocol.
NetBIOS-over-TCP/IP means different things to different people.
Much trouble results from confusing the original NetBEUI a.k.a.
NetBIOS-over-LLC, w/ the emulated NetBIOS-over-TCP/IP, and the latest
non-NetBIOS use of SMB that has large dependencies on either
undocumented, or poorly documented naming services that (as of this pre
SAMBA-4 writing) can only be provided by a MS-AD-Domain.
In the early days of ethernet standards, NetBIOS (like many early
sibling protocols to TCP/IP) was implemented over an ethernet frame type
called 802.2, or "LLC". In this form, NetBIOS was referred to as NetBEUI.
SMB file sharing was implemented on top of NetBIOS, providing the
now-common UNC "\\server\sharename" syntax used by microsoft today.
Meanwhile, TCP/IP developed. IPv4 came w/ routing features and was
deployed on top of the "ethernet II" frame type.
TCP (like NetBIOS) provided the concept of a session, but NetBIOS sessions
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/netbios/netbios_3qjy.asp
are established from and to "calling" and "called" NetBIOS names, while
TCP sessions are established between IP addresses.
(unlike NetBIOS, most TCP/IP protocols are unaware of, or do not need to
be aware of, the actual names of the client and server on each end of a
session)
In the era of Win'NT 3.5.1, Microsoft implemented a TCP/IP stack,
NT-Domains, and included an SMB file server.
Since their SMB implementation depended on NetBIOS, Microsoft emulated a
NetBIOS network over TCP/IP.
NetBIOS naming traffic was sent over ports 137, and 138. SMB traffic
was sent over virtual NetBIOS sessions, over a TCP session on port 139.
Other networking companies were adapting the SMB protocol in the same
way, and SAMBA was designed to work w/ one of their products.
It is this NetBIOS-naming (performed by nmbd) on ports 137/138, and
SMB-over-NetBIOS-session-over-TCP-session on port 139 that today allows
SAMBA to interoperate w/ Win'NT4, and Win'9x, as well as Win'XP, and
Win'200x.
By default, Win'95 uses the same emulated NetBIOS-over-TCP/IP scheme as
NT 3.5.1.
Win'95 can either broadcast NetBIOS-over-TCP/IP packets, to reach every
machine in it's NT-domain/workgroup.
or send unicast NetBIOS-over-TCP/IP packets to a WINS server, defined in
the client's network properties.
Turning off the Win'95 "NetBIOS-over-TCP/IP" feature causes it to revert
to NetBIOS over LLC, which does not work w/ SAMBA. (smbd supports
NetBIOS-over-TCP -only on port 139)
In Win'95, turning off this feature does NOT get rid of NetBIOS, it
detaches your NetBIOS-based UNC shares from access to TCP/IP, which is
probably the opposite of what you intended.
"Browsing" the network opens (small) can of worms.
In the windows-GUI world, simply typing a UNC name in order to access a
server or share isn't good enough.
You "browse" through the list of computers available to you in your
network neighborhood.
Hopefully, your local master browser's list of cached server names is up
to date. (If the "weather" is good in your network neighborhood)
Your client will display this browse-list of server names, organizing it
by workgroup/NT-domain.
In the world of NetBIOS networks, it makes perfect sense to open a
NetBIOS session (port 139) to your local-master-browser(s), or your WINS
server, so that you can pull down a large list of available computer names.
In the world of SAMBA, the samba-naming-daemon (nmbd) listens on ports
137 and 138, while the smb server (smbd) listens on port 139, the
"session" port. Of course, your SMB share is the *only* thing that might
require a session, right? wrong.
In those situations where your samba server is acting as a master
browser, it has to accept the "browse" connection on port 139, and
help-out nmbd by providing the "name service" function of listing all
the names in nmbd's NetBIOS naming cache.
How can you use NetBIOS to "browse" over to some other network of SMB
servers?
You can't. w/ NetBIOS, your GUI client shows you every NT-domain it can
find. If you need to access a machine that's not listed because it's on
a non-local network, you'll have to type the UNC.
Note:
{If you're fine w/ typing in UNC names, you might wonder what a local
master browser does for you, and why they bother holding elections for one.
I mean, if all NetBIOS naming info is available from a local master
browser, why does Win'XP keep broadcasting on ports 137, and 138? It
should be able to unicast to the master browser, once a master browser
is located.
You'd think that the master browser would perform the same
broadcast-limiting function as a WINS server, but it doesn't.
The problem is that NetBIOS allows for a local master browser
per-NT-domain. (and, thanks to NetBIOS-over-TCP/IP, per subnet as well)
A client has to perform a broadcast in order to get responses from the
local master browsers for each NT-domain in the local subnet... Yuk.
Why couldn't a NetBIOS client just get a direct response from any
client? The original NetBIOS wasn't routable, and original NetBIOS
didn't do DNS. In order to find NetBIOS names for machines in other IP
subnets, each local master browser must synchronize naming information
w/ an NT-domain-master-browser }
Win'200x removed support for the old NetBEUI a.k.a NetBIOS over the old
LLC frame type.
Likewise,Win'XP uses NetBIOS-over-TCP/IP on the usual ports 137,138 and 139.
But, while withdrawing support for the old NetBEUI/LLC frames, these
operating systems added support for something called "naked-SMB" on port
445.
"Naked-SMB" means "SMB-without-NetBIOS and directly on TCP/IP".
By default, a Win'XP client will try both the now-old
NetBIOS-over-TCP/IP naming scheme as well as a new AD-Domain naming scheme.
Disabling "NetBIOS-over-TCP/IP" on a client *should* (logically...) stop
all traffic from that client on ports 137, 138 and 139, and cause it to
use AD-Domain naming along w/ "naked-SMB" on port 445.
In theory, disabling NetBIOS-over-TCP/IP on a Win'XP client should
reduce network traffic, and it might actually do that, but many have
pointed out that a "properly" configured NetBIOS/WINS server is far more
bandwidth efficient than AD-domain naming, so even in a win'200x server
environment, disabling NetBIOS-over-TCP/IP may actually increase network
traffic in those (most?) instances where the WINS server would have
provided a fast and accurate response.
Note: possibly to avoid confusing Win'XP clients, many SAMBA admins
recommend disabling smbd on port 445, keeping it squarely in the world
of NetBIOS. If a Win'XP client can make a connection on port 445, it
might reasonably expect this "naked-SMB" server to live in an AD-domain,
which your SAMBA server very likely does not.
How does the old SMB protocol deal w/ the new "raw TCP" environment?
or... does "naked-SMB" no longer use the old NetBIOS API that required
both "called", and "calling" NetBIOS names to be known?
The answer is ... "I don't know".
But... I did find this:
From: http://lists.samba.org/archive/jcifs/2003-February/001760.html
> Samba doesn't actually care whether you get the Called and Calling
> names right. Samba ignores those fields. Windows, however, likes to
> make sure that the Called name matches the service you're actually
> trying to reach.
So... Possibly Win'200x server takes a page from the SAMBA playbook, and
has "found a way" to ignore these old NetBIOS parameters when doing SMB
on port 445.
What is the nature of this AD-domain naming?
UNIX admins have often felt that the hierarchical DNS naming system that
powers the internet is far superior to WINS, and certainly superior to
the default behavior of unmanaged NetBIOS broadcasts, elections and
master browsers.
Unfortunately, the SAMBA docs tell us in:
http://us3.samba.org/samba/docs/Samba-Guide.pdf
13.3.1.2 Routed Networks - Page 480
>Note
>The use of DNS is not an acceptable substitute
>for WINS. DNS does not store specific
>information regarding NetBIOS networking
>particulars that get stored in the WINS
>name resolution database and that Windows
>clients require and depend on.
>
Specifically, in Win'9x machines there's no way (and no effort) for a
client to get NT-domain membership information from a DNS server.
At the time there were no DNS "SRV" records, so a
NetBIOS-over-TCP/IP-only clients don't know to look for this information.
This is not the case w/ AD-aware clients like Win'200x, and Win'XP.
Microsoft decided to change things w/ AD-domains.
AD-aware operating systems start their daily relationship w/ an
AD-domain by authenticating via Kerberos.
Kerberos was an open standard championed by MIT, and then embraced by
microsoft.
Microsoft extended the kerberos standard by storing some authorization
information (specifically the primary group-membership of a user) into
an unused field of this otherwise authentication-only protocol.
This effectively breaks the intent of the kerberos protocol by making
any non-microsoft kerberos server useless to a microsoft kerberos client.
To my knowledge microsoft has provided no information on how to reverse
the damage caused to the kerberos standard by this extension.
One might assume that their advice would be to have all kerberos servers
be purchased from microsoft, thus negating it's usefulness as an open
standard.
From this point on, an AD-aware client *could* be configured to not use
NetBIOS-over-TCP/IP, which should force it to locate any server by doing
a DNS query on the MS-DNS server of an AD-domain.
The array of "SRV" records apparently required to make a server known to
an AD-aware client evokes images of attempting to browse a DNS tree w/
regedit.
One would assume that information along the lines of browse-lists would
be available via LDAP, since that protocol is used by AD-aware clients,
and it would be suitable to that task.
Still more communication occurs over MS-RPC protocol.
At this time (pre-SAMBA4) it is not known how to emulate all the
functions provided by an AD-aware client that is attempting to locate,
and communicate w/ a "naked-SMB" service.
It is also not known which parts of this communication are strictly
necessary to provide the name-service tasks required by the SMB protocol
in the absence of NetBIOS emulation.
What SAMBA IS capable of doing, is providing a "naked-SMB" service on
port 445.
In this case, a SAMBA server can act as an AD-member-server, within a
pre-existing Microsoft AD-Domain.
In order to accomplish this, your SAMBA server will have to interact w/
an AD-domain, exchanging authentication "tickets" w/ Microsoft's
Active-Directory enabled Kerberos server.
Your SAMBA server needs to join the Active-Directory domain, as
described in:
http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
"6.3 Domain Member Server"
and
"6.4 Samba ADS Domain Membership"
on Page 107.
Hopefully, this process will cause all the appropriate information to be
added to the AD-Domain's MS-DNS server.
You can attempt to check the success of this joining by verifying the
contents of your MS-DNS server against the information in:
http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
"9.3.2 TCP/IP without NetBIOS"
on Page 152.
It would have been nice if it were possible to simply list one or two
SRV records, corresponding to early NetBIOS "service" names in order to
enable a Win'XP client to use a UNC name to access either a new
"naked-SMB", or even a traditional "NetBIOS-SMB" on port 139.
It appears at this time that providing NetBIOS-less SMB for use w/ a
Win'XP client is not going to be that easy.
Still, if all the above steps are completed, it is now technically
possible to serve SMB without any NetBIOS naming, or emulation going on,
as long as you are willing to join your SAMBA server to an AD-Domain,
and allow a Microsoft AD-Domain server to provide the authentication,
access control, and naming services.
------------------------------------------------------------------------------------------------
End of proposed docs...
Can anyone on the list poke holes in that for me?
------------------------------------------------------------------------------------------------
Sorry to make this complicated but...
I was hoping that grinding through all this name-service stuff would
help me figure our my DFS problem.
I CAN address a Win'2000 server AND a SAMBA server across subnets from a
Win'XP client that is not configured to use WINS. (client using NetBIOS
over TCP/IP, and looking for a fully qualified third-level DNS domain name)
I CAN access both regular shares and follow DFS links.
Is that "\\server.mydomain.com\sharename" address not supposed to work
across subnets?
If the Win'XP client gets a match on a DNS query, do the machines at
both ends of the TCP/IP connection then do directed NetBIOS queries to
each other to discover/verify their names?
If so, that would explain why I can get a connection. (note, that w/
tcpip helper off, I can't make this connection)
But... I can't explain why it is that when I use a fully qualified
FOURTH-level DNS domain name the behavior is slightly different.
I can make a connection, I can access normal shares fine, but I cannot
follow the links of a DFS share.
I get the same behavior on local subnets as when I try to access the
share across subnets.
(the properties/DFS-tab is missing from the links)
"\\server.sub.mydomain.com\sharename" works.
"\\server.sub.mydomain.com\dfsshare" does not.
What is different about the process of accessing a DFS share?
-Bill
-------------------------------------------------------------------------------
>Browsing uses a complex interaction of name registration and resolution
>involving UDP ports 137 and 138. Port 137 is the NetBIOS Name Server port,
>but it is also used to handle all browsing operations. Browsing is the
>ability to locate domains and machines over the network.
>
>A NetBIOS machine name must be resolved to its IP address. This can be done
>using WINS using NetBIOS unicast requeries over unicast UDP, or via NetBIOS
>broadcasts over UDP broadcast using port 137.
>
>
>File and print sharing operations under NetBIOS over TCP/IP are performed over
>TCP port 139. Both ends of the NetBIOS over TCP/IP connection must know each
>others NetBIOS name. Name resolution is vital to NetBIOS over TCP/IP
>operation - WINS is your friend because it adds reliability and reduces
>network UDP traffic.
>
>Windows 2000 introduces ADS!
>
>Enter Windows 2000 with ADS, and the ability to disable NetBIOS over TCP/IP.
>In its place Windows 200X uses DNS, Kerberos, LDAP, and Raw SMB over TCP/IP.
>The DNS, Kerberos and LDAP services run over the standard well-known ports.
>Raw SMB over TCP/IP uses TCP port 445.
>
>On Windows 200X clients, when NetBIOS over TCP/IP is disabled, and an attempt
>is made to join a domain, the client automatically tries to use the
>combination of DNS, Kerberos, LDAP and TCP port 445 services with the
>expectation that Microsoft Active Directory is being used. In order to remain
>backwards compatible, TCP port 139 can also be used.
>
>The mechanisms behind TCP ports 139 and 445 are very different. A connection
>made on port 445 must be able to resolve the fully qualified hostname using
>the protocols expected within ADS. That is, via DNS using SRV records as well
>as A records. Additionally, the client will try to use Kerberos information
>to contact the DNS server and the LDAP server. It expects to find SMB
>information in the Kerberos PAC (a data blob inside the Kerberos ticket that
>is unique to ADS's implementation).
>
>With ADS browsing involves DNS, LDAP and Raw SMB traffic over ports 445 and
>139. The client expects all the information that it wold obtain if it were a
>member of an ADS domain.
>
>Samba-3 supports port 445 and all operations necessary to be an ADS domain
>member server. It can not be an ADS server, and it can not be an ADS domain
>controller. That functionality is being added in the Samba-4 project.
>
>What this means is, that if you disable NetBIOS over TCP/IP on your clients
>and on Samba-3, you will not be able to browse the network. Additionally,
>Samba can NOT be a domain controller. It can be a stand-alone server without
>NetBIOS over TCP/IP.
>
>Samba-3 can be a file and print server for Windows clients that have NetBIOS
>disabled - but some things may break.
>
>In short, NetBIOS-less SMB implies ADS. Samba-3 is not an ADS server. Ergo, NO
>ADS for all practical purposes means DOES NOT WORK.
>
>On Tuesday 25 October 2005 07:12, William Burns wrote:
>
>
>>>On Monday 24 October 2005 14:06, julius Junghans wrote:
>>>
>>>
>>>>ive read a lot in the howto about netbios/ddns, but im still confused if
>>>>its possible for samba to only use tcp/ip without netbios.
>>>>are there any howtos for this topic that are not mentioned in the samba3
>>>>howto?
>>>>
>>>>
>>John H Terpstra wrote:
>>
>>
>>>Please point me to the documentation (section and page number please) that
>>>you have referred to and that is not clear to you. I need to know so I
>>>can fix it.
>>>
>>>
>>John:
>>I don't know what Julius is looking at but...
>>I'm looking into similar docs re: DFS not working on SAMBA servers that
>>are referred to w/ fully.qualified.sub.domains... (even though a
>>straight samba share WILL work under that name)
>>
>>I figure that all the info that Julius needs is in the docs...
>>
>>
>
>I am not sufficiently tuned in to answer what Julius' needs are. I offer a
>speculative answer below.
>
>
>
>>Here's how he might proceed to get where he wants to go.
>>
>>At the bottom of this section:
>>http://us3.samba.org/samba/docs/Samba-Guide.pdf
>>13.3.1.2 Routed Networks - Page 480
>>
>>There's a pretty definitive sounding statement:
>>
>>
>>>Note
>>>The use of DNS is not an acceptable substitute
>>>for WINS. DNS does not store specific
>>>information regarding NetBIOS networking
>>>particulars that get stored in the WINS
>>>name resolution database and that Windows
>>>clients require and depend on.
>>>
>>>
>>That sounds like a "no".
>>
>>
>
>Correct - DNS can not substitue for WINS or Broadcast UDP-based name
>resolution for NetBIOS over TCP/IP enabled configurations.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>
>>But, later in section
>>"15.1 Joining a Domain: Windows 200x/XP Professional"
>>
>>at the bottom of page 495, there's this:
>>
>>
>>>Where NetBIOS technology uses WINS as well as UDP broadcast
>>>as key mechanisms for name resolution, Active Directory
>>>servers register their services with the Microsoft Dynamic DNS
>>>server. Windows clients must be able to query the correct DNS
>>>server to find the services (like which machines are domain controllers
>>>or which machines have the Netlogon service running).
>>>
>>>
>>So, sometime you HAVE to use DNS....
>>
>>
>
>For ADS DNS is essential.
>
>
>
>>Later there's a note that you don't have to do this [DNS] if you're in a
>>SAMBA domain.
>>
>>
>
>Correct - You must use NetBIOS over TCP/IP.
>
>
>
>>But... Does this mean I can disable Netbios/Netbeui?
>>
>>
>
>Well, yes you can, but your network wil not be browseable and some SMB
>operations will fail.
>
>
>
>>There's A direct answer to Julius' question in section
>>"16.5 Questions and Answers"
>>at the bottom of page 554
>>
>>
>>
>>>6. Q: Is it possible to reduce network broadcast activity with
>>>Samba-3?
>>>A: Yes, there are two ways to do this. The first involves
>>>use of WINS (See TOSHARG2, Chapter 9, Section 9.5, “WINS
>>>— The Windows Inter-networking Name Server”); the alternate
>>>method involves disabling the use of NetBIOS over TCP/IP. This
>>>second method requires a correctly configured DNS server (see
>>>TOSHARG2, Chapter 9, Section 9.3, “Discussion”)
>>>
>>>
>
>WINS is part of NetBIOS over TCP/IP, DNS is integral to ADS. ADS reduces UDP
>broadcast traffic, but replaces what would have happened over UDP port 137
>with many times more traffic that now uses UDP/TCP ports 53 (DNS), TCP port
>88 (Kerberos), LDAP TCP ports 389 and 636, TCP port 139 and 445 (SMB) and TCP
>port 135 (MS DCE RPC).
>
>So turning off NetBIOS does not reduce network traffic with Windows! It
>increases the overall traffic. Which is why the discussion about this gets
>rediculous.
>
>
>
>>Plus the following note:
>>
>>
>>>Note
>>>Use of SMB without NetBIOS is possible only
>>>on Windows 200x/XP Professional clients
>>>and servers, as well as with Samba-3.
>>>
>>>
>
>Correct. Outlined above.
>
>
>
>>Personally, I find the answer to question 6 a little confusing because I
>>*thought* that in Win'9x, disabling "NetBIOS over TCP/IP" meant that
>>you'd get no SMB traffic on the TCP/IP side of that client. (It'd be all
>>NetBEUI)
>>
>>
>
>NetBEUI has nothing to do with TCP/IP - it is a totally separate protocol that
>uses NetBIOS over LLC.
>
>When NetBIOS over TCP/IP on Windows 9x is disabled this stops the client from
>using any SMB over TCP/IP. Ergo, no ability to talk to Samba servers.
>
>
>
>>This Win' 9x "NetBIOS over TCP/IP" config feature does not exist in Win'
>>XP as such, but is provided by Win' XP's "TCP/IP NetBIOS Helper" in
>>Control-Panel/Services which "Enables support for NetBIOS over TCP/IP
>>(NetBT) service and NetBIOS name resolution"
>>This service sometimes inexplicably gets turned off, causing the Win'XP
>>client to fail to use DNS resolution to resolve SMB names.
>>
>>
>
>Correct.
>
>
>
>>But... it IS possible....
>>
>>
>
>Right! And you CAN also shoot your foot off, but then your foot does not work
>too well any more.
>
>
>
>>That brings us to this section
>>http://tr.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h
>>tml#id2551944 which is not numbered in the html version ??? but in the PDF
>>version has a section number:
>>http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
>>"9.3.2 TCP/IP without NetBIOS"
>>
>>
>
>Remember, this chapter deals with Network browsing and name resolution. It
>does not deal with domain control or with SMB session services.
>
>
>
>>On page 151 we learn:
>>
>>
>>>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 time not use NetBIOS.
>>>
>>>
>>But, it should be possible to do this w/ a stand-alone SAMBA server.
>>
>>
>
>Correct, see above. But note also that I did say that some SMB operations will
>fail, and thateffectively means that you can not use it.
>
>
>
>>And then, a very interesting statement:
>>
>>
>>>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.
>>>
>>>
>
>Correct, as explained above, Samba-3 can be an ADS member and thus must
>support all the protocols ADS clients use as a domain member.
>
>
>
>>This is interesting because I *thought* that I was concerned about
>>replacing NetBIOS w/ DNS name resolution on my Win'XP clients.
>>
>>
>
>Right! Only when Windows XP is an ADS domain member.
>
>
>
>>Is this also about how SAMBA resolves names?
>>
>>
>
>No.
>
>
>
>>I hadn't given any thought to the possibility that SAMBA might need to
>>resolve an IP from a PC name.., or even know the PC name at all...
>>IS this a requirement? I mean, isn't the smbd process passive? Maybe
>>not.....?
>>
>>
>
>No. All SMB operation must know the identity of the server and the client for
>security reasons.
>
>
>
>>>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.
>>>
>>>
>
>Right! Samba-3 acting as an ADS domain member may require that static entries
>be made for each of the names that may need to be capable of being resolved.
>
>
>
>>Now, it seems like I've been told that: if I want to have a SAMBA server
>>without NetBIOS (only DNS) name services enabled on the clients, my only
>>hope is to get a SAMBA member server into my Active Directory domain.
>>I'd expect to see the SRV records that I need to put into A.D. spelled
>>out...
>>Is that what's on page 152?
>>
>>
>
>Correct.
>
>
>
>>Instead, it looks like lots of stuff that an AD domain puts into DNS is
>>listed.
>>
>>
>
>Correct, this only works for all practical purposes with ADS.
>
>
>
>>I don't get the idea that these are the few things that I need to ADD to
>>an existing MS-DNS server in order to get my member server going.
>>(Am I wrong?)
>>
>>
>
>So long as you have ADS, correct.
>
>
>
>>Then I'm supposed to double-check my work by looking on a DNS server
>>named frodo for what provides LDAP service for
>>"_ldap._tcp.dc._msdcs.quenya.org" ?
>>
>>Phew... That was supposed to convince me that SAMBA/AD domain membership
>>is not for the faint-of-heart, right?
>>Either that, or it was supposed to encourage me (w/ a wink) to take on
>>the challenge of going straight to doing everything w/ a linux-based DNS
>>server in place of MS-DNS.
>>
>>
>
>Nope! You need to think in terms of how Microsoft implemented their networking
>technology. Your choice is NetBIOS over TCP/IP (aka NT4 style domains) or
>Active Directory. Only Samba-4 will offer the ability to not use NetBIOS over
>TCP/IP for a Samba-only domain controlled network.
>
>
>
>>Which.... Might cause me to look at the section on DDNS, and DHCP, where
>>I *think* Julius was looking....
>>And I might be encouraged to tilt at the ISC vs. MS DNS windmill. (It
>>would be cool, wouldn't it?)
>>
>>
>
>Julius nees to disable use of port 445, if I recall correctly. He also must
>use NetBIOS names - not DNS domain names - to connect to his MS DFS server.
>It is possible to use port 445 and DNS domain names only if his Samba server
>is an ADS domain member and DNS is correctly configured.
>
>
>
>>But I, as a non-unix-wizard, should really be looking back at:
>>http://us3.samba.org/samba/docs/Samba3-HOWTO.pdf
>>"6.3 Domain Member Server"
>>and
>>"6.4 Samba ADS Domain Membership"
>>on Page 107.
>>
>>
>>
>>>This is a rough guide to setting up Samba-3 with Kerberos authentication
>>>against a Windows 200x KDC. A familiarity with Kerberos is assumed.
>>>
>>>
>
>Correct - but only as an ADS domain member.
>
>
>
>>Where I can bite the kerberos configuration bullet, and refer to a few
>>microsoft documents to help me get a SAMBA server kerberized right into
>>an AD domain.
>>
>>
>
>Well, you can configure Samba-3 only as an ADS domain member. It can not be an
>ADS domain controller, nor can it be an ADS server.
>
>
>
>>And then, when I've got that done, I can turn off NetBIOS over TCP/IP on
>>my Win'XP clients.
>>
>>
>
>Sure! So long as you have MS ADS!
>
>
>
>>At least... I think that's the intent of the docs... If I was reading
>>that right.
>>
>>
>
>Correct! Samba-3 documentation guides the administrator in how to configure
>NT4-style domains and ADS domain member clients. Nowhere have I designed the
>documentation to guide administrators to do what is not supported.
>
>Now, please send me documentation updates as your contribution to help others
>like yourself from getting sucked into the same whirlpool.
>
>
>- John T.
>
>
More information about the samba
mailing list