summaryrefslogtreecommitdiff
path: root/docs/textdocs
diff options
context:
space:
mode:
Diffstat (limited to 'docs/textdocs')
-rw-r--r--docs/textdocs/BROWSING.txt559
-rw-r--r--docs/textdocs/BUGS.txt135
-rw-r--r--docs/textdocs/DIAGNOSIS.txt321
-rw-r--r--docs/textdocs/DNIX.txt69
-rw-r--r--docs/textdocs/GROUP-MAPPING-HOWTO.txt60
-rw-r--r--docs/textdocs/INSTALL.sambatar33
-rw-r--r--docs/textdocs/Imprints.txt47
-rw-r--r--docs/textdocs/Macintosh_Clients.txt23
-rw-r--r--docs/textdocs/NetBIOS.txt152
-rw-r--r--docs/textdocs/Passwords.txt46
-rw-r--r--docs/textdocs/Printing.txt255
-rw-r--r--docs/textdocs/README.sambatar23
-rw-r--r--docs/textdocs/SCO.txt19
-rw-r--r--docs/textdocs/SMBTAR.notes46
-rw-r--r--docs/textdocs/Samba-OpenSSL.txt405
-rw-r--r--docs/textdocs/Speed.txt338
-rw-r--r--docs/textdocs/Speed2.txt57
-rw-r--r--docs/textdocs/Tracing.txt93
-rw-r--r--docs/textdocs/UNIX-SMB.txt231
-rw-r--r--docs/textdocs/Win95.txt74
-rw-r--r--docs/textdocs/WinNT.txt104
-rw-r--r--docs/textdocs/cifsntdomain.txt1498
-rw-r--r--docs/textdocs/outdated/NTDOMAIN.txt51
-rw-r--r--docs/textdocs/outdated/PROJECTS88
-rw-r--r--docs/textdocs/security_level.txt100
25 files changed, 0 insertions, 4827 deletions
diff --git a/docs/textdocs/BROWSING.txt b/docs/textdocs/BROWSING.txt
deleted file mode 100644
index 2ca41e5624..0000000000
--- a/docs/textdocs/BROWSING.txt
+++ /dev/null
@@ -1,559 +0,0 @@
-Author/s: Many (Thanks to Luke, Jeremy, Andrew, etc.)
-Updated: July 5, 1998
-Status: Current - For VERY Advanced Users ONLY
-
-Summary: This describes how to configure Samba for improved browsing.
-=====================================================================
-
-OVERVIEW:
-=========
-
-SMB networking provides a mechanism by which clients can access a list
-of machines in a network, a so-called "browse list". This list
-contains machines that are ready to offer file and/or print services
-to other machines within the network. Thus it does not include
-machines which aren't currently able to do server tasks. The browse
-list is heavily used by all SMB clients. Configuration of SMB
-browsing has been problematic for some Samba users, hence this
-document.
-
-Browsing will NOT work if name resolution from NetBIOS names to IP
-addresses does not function correctly. Use of a WINS server is highly
-recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
-WINS allows remote segment clients to obtain NetBIOS name_type information
-that can NOT be provided by any other means of name resolution.
-
-=====================================================================
-
-BROWSING
-========
-Samba now fully supports browsing. The browsing is supported by nmbd
-and is also controlled by options in the smb.conf file (see smb.conf(5)).
-
-Samba can act as a local browse master for a workgroup and the ability
-for samba to support domain logons and scripts is now available. See
-DOMAIN.txt for more information on domain logons.
-
-Samba can also act as a domain master browser for a workgroup. This
-means that it will collate lists from local browse masters into a
-wide area network server list. In order for browse clients to
-resolve the names they may find in this list, it is recommended that
-both samba and your clients use a WINS server.
-
-Note that you should NOT set Samba to be the domain master for a
-workgroup that has the same name as an NT Domain: on each wide area
-network, you must only ever have one domain master browser per workgroup,
-regardless of whether it is NT, Samba or any other type of domain master
-that is providing this service.
-
-[Note that nmbd can be configured as a WINS server, but it is not
-necessary to specifically use samba as your WINS server. NTAS can
-be configured as your WINS server. In a mixed NT server and
-samba environment on a Wide Area Network, it is recommended that
-you use the NT server's WINS server capabilities. In a samba-only
-environment, it is recommended that you use one and only one nmbd
-as your WINS server].
-
-To get browsing to work you need to run nmbd as usual, but will need
-to use the "workgroup" option in smb.conf to control what workgroup
-Samba becomes a part of.
-
-Samba also has a useful option for a Samba server to offer itself for
-browsing on another subnet. It is recommended that this option is only
-used for 'unusual' purposes: announcements over the internet, for
-example. See "remote announce" in the smb.conf man page.
-
-If something doesn't work then hopefully the log.nmb file will help
-you track down the problem. Try a debug level of 2 or 3 for finding
-problems. Also note that the current browse list usually gets stored
-in text form in a file called browse.dat.
-
-Note that if it doesn't work for you, then you should still be able to
-type the server name as \\SERVER in filemanager then hit enter and
-filemanager should display the list of available shares.
-
-Some people find browsing fails because they don't have the global
-"guest account" set to a valid account. Remember that the IPC$
-connection that lists the shares is done as guest, and thus you must
-have a valid guest account.
-
-Also, a lot of people are getting bitten by the problem of too many
-parameters on the command line of nmbd in inetd.conf. This trick is to
-not use spaces between the option and the parameter (eg: -d2 instead
-of -d 2), and to not use the -B and -N options. New versions of nmbd
-are now far more likely to correctly find your broadcast and network
-address, so in most cases these aren't needed.
-
-The other big problem people have is that their broadcast address,
-netmask or IP address is wrong (specified with the "interfaces" option
-in smb.conf)
-
-
-BROWSING ACROSS SUBNETS
-=======================
-
-With the release of Samba 1.9.17(alpha1 and above) Samba has been
-updated to enable it to support the replication of browse lists
-across subnet boundaries. New code and options have been added to
-achieve this. This section describes how to set this feature up
-in different settings.
-
-To see browse lists that span TCP/IP subnets (ie. networks separated
-by routers that don't pass broadcast traffic) you must set up at least
-one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing
-NetBIOS name to IP address translation to be done by doing a direct
-query of the WINS server. This is done via a directed UDP packet on
-port 137 to the WINS server machine. The reason for a WINS server is
-that by default, all NetBIOS name to IP address translation is done
-by broadcasts from the querying machine. This means that machines
-on one subnet will not be able to resolve the names of machines on
-another subnet without using a WINS server.
-
-Remember, for browsing across subnets to work correctly, all machines,
-be they Windows 95, Windows NT, or Samba servers must have the IP address
-of a WINS server given to them by a DHCP server, or by manual configuration
-(for Win95 and WinNT, this is in the TCP/IP Properties, under Network
-settings) for Samba this is in the smb.conf file.
-
-How does cross subnet browsing work ?
-=====================================
-
-Cross subnet browsing is a complicated dance, containing multiple
-moving parts. It has taken Microsoft several years to get the code
-that achieves this correct, and Samba lags behind in some areas.
-However, with the 1.9.17 release, Samba is capable of cross subnet
-browsing when configured correctly.
-
-Consider a network set up as follows :
-
- (DMB)
- N1_A N1_B N1_C N1_D N1_E
- | | | | |
- -------------------------------------------------------
- | subnet 1 |
- +---+ +---+
- |R1 | Router 1 Router 2 |R2 |
- +---+ +---+
- | |
- | subnet 2 subnet 3 |
- -------------------------- ------------------------------------
- | | | | | | | |
- N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
- (WINS)
-
-Consisting of 3 subnets (1, 2, 3) conneted by two routers
-(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines
-on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume
-for the moment that all these machines are configured to be in the
-same workgroup (for simplicities sake). Machine N1_C on subnet 1
-is configured as Domain Master Browser (ie. it will collate the
-browse lists for the workgroup). Machine N2_D is configured as
-WINS server and all the other machines are configured to register
-their NetBIOS names with it.
-
-As all these machines are booted up, elections for master browsers
-will take place on each of the three subnets. Assume that machine
-N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
-subnet 3 - these machines are known as local master browsers for
-their particular subnet. N1_C has an advantage in winning as the
-local master browser on subnet 1 as it is set up as Domain Master
-Browser.
-
-On each of the three networks, machines that are configured to
-offer sharing services will broadcast that they are offering
-these services. The local master browser on each subnet will
-receive these broadcasts and keep a record of the fact that
-the machine is offering a service. This list of records is
-the basis of the browse list. For this case, assume that
-all the machines are configured to offer services so all machines
-will be on the browse list.
-
-For each network, the local master browser on that network is
-considered 'authoritative' for all the names it receives via
-local broadcast. This is because a machine seen by the local
-master browser via a local broadcast must be on the same
-network as the local master browser and thus is a 'trusted'
-and 'verifiable' resource. Machines on other networks that
-the local master browsers learn about when collating their
-browse lists have not been directly seen - these records are
-called 'non-authoritative'.
-
-At this point the browse lists look as follows (these are
-the machines you would see in your network neighborhood if
-you looked in it on a particular network right now).
-
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
-
-Note that at this point all the subnets are separate, no
-machine is seen across any of the subnets.
-
-Now examine subnet 2. As soon as N2_B has become the local
-master browser it looks for a Domain master browser to synchronize
-its browse list with. It does this by querying the WINS server
-(N2_D) for the IP address associated with the NetBIOS name
-WORKGROUP<1B>. This name was registerd by the Domain master
-browser (N1_C) with the WINS server as soon as it was booted.
-
-Once N2_B knows the address of the Domain master browser it
-tells it that is the local master browser for subnet 2 by
-sending a MasterAnnouncement packet as a UDP port 138 packet.
-It then synchronizes with it by doing a NetServerEnum2 call. This
-tells the Domain Master Browser to send it all the server
-names it knows about. Once the domain master browser receives
-the MasterAnnouncement packet it schedules a synchronization
-request to the sender of that packet. After both synchronizations
-are done the browse lists look like :
-
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
-
-Servers with a (*) after them are non-authoritative names.
-
-At this point users looking in their network neighborhood on
-subnets 1 or 2 will see all the servers on both, users on
-subnet 3 will still only see the servers on their own subnet.
-
-The same sequence of events that occured for N2_B now occurs
-for the local master browser on subnet 3 (N3_D). When it
-synchronizes browse lists with the domain master browser (N1_A)
-it gets both the server entries on subnet 1, and those on
-subnet 2. After N3_D has synchronized with N1_C and vica-versa
-the browse lists look like.
-
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*),
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Servers with a (*) after them are non-authoritative names.
-
-At this point users looking in their network neighborhood on
-subnets 1 or 3 will see all the servers on all sunbets, users on
-subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
-
-Finally, the local master browser for subnet 2 (N2_B) will sync again
-with the domain master browser (N1_C) and will recieve the missing
-server entries. Finally - and as a steady state (if no machines
-are removed or shut off) the browse lists will look like :
-
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*),
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Servers with a (*) after them are non-authoritative names.
-
-Synchronizations between the domain master browser and local
-master browsers will continue to occur, but this should be a
-steady state situation.
-
-If either router R1 or R2 fails the following will occur:
-
-1) Names of computers on each side of the inaccessible network fragments
-will be maintained for as long as 36 minutes, in the network neighbourhood
-lists.
-
-2) Attempts to connect to these inaccessible computers will fail, but the
-names will not be removed from the network neighbourhood lists.
-
-3) If one of the fragments is cut off from the WINS server, it will only
-be able to access servers on its local subnet, by using subnet-isolated
-broadcast NetBIOS name resolution. The effects are similar to that of
-losing access to a DNS server.
-
-Setting up a WINS server
-========================
-
-Either a Samba machine or a Windows NT Server machine may be set up
-as a WINS server. To set a Samba machine to be a WINS server you must
-add the following option to the smb.conf file on the selected machine :
-in the [globals] section add the line
-
- wins support = yes
-
-Versions of Samba previous to 1.9.17 had this parameter default to
-yes. If you have any older versions of Samba on your network it is
-strongly suggested you upgrade to 1.9.17 or above, or at the very
-least set the parameter to 'no' on all these machines.
-
-Machines with "wins support = yes" will keep a list of all NetBIOS
-names registered with them, acting as a DNS for NetBIOS names.
-
-You should set up only ONE wins server. Do NOT set the
-"wins support = yes" option on more than one Samba server.
-
-To set up a Windows NT Server as a WINS server you need to set up
-the WINS service - see your NT documentation for details. Note that
-Windows NT WINS Servers can replicate to each other, allowing more
-than one to be set up in a complex subnet environment. As Microsoft
-refuse to document these replication protocols Samba cannot currently
-participate in these replications. It is possible in the future that
-a Samba->Samba WINS replication protocol may be defined, in which
-case more than one Samba machine could be set up as a WINS server
-but currently only one Samba server should have the "wins support = yes"
-parameter set.
-
-After the WINS server has been configured you must ensure that all
-machines participating on the network are configured with the address
-of this WINS server. If your WINS server is a Samba machine, fill in
-the Samba machine IP address in the "Primary WINS Server" field of
-the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs
-in Windows 95 or Windows NT. To tell a Samba server the IP address
-of the WINS server add the following line to the [global] section of
-all smb.conf files :
-
- wins server = <name or IP address>
-
-where <name or IP address> is either the DNS name of the WINS server
-machine or its IP address.
-
-Note that this line MUST NOT BE SET in the smb.conf file of the Samba
-server acting as the WINS server itself. If you set both the
-"wins support = yes" option and the "wins server = <name>" option then
-nmbd will fail to start.
-
-There are two possible scenarios for setting up cross subnet browsing.
-The first details setting up cross subnet browsing on a network containing
-Windows 95, Samba and Windows NT machines that are not configured as
-part of a Windows NT Domain. The second details setting up cross subnet
-browsing on networks that contain NT Domains.
-
-Setting up Browsing in a WORKGROUP
-==================================
-
-To set up cross subnet browsing on a network containing machines
-in up to be in a WORKGROUP, not an NT Domain you need to set up one
-Samba server to be the Domain Master Browser (note that this is *NOT*
-the same as a Primary Domain Controller, although in an NT Domain the
-same machine plays both roles). The role of a Domain master browser is
-to collate the browse lists from local master browsers on all the
-subnets that have a machine participating in the workgroup. Without
-one machine configured as a domain master browser each subnet would
-be an isolated workgroup, unable to see any machines on any other
-subnet. It is the presense of a domain master browser that makes
-cross subnet browsing possible for a workgroup.
-
-In an WORKGROUP environment the domain master browser must be a
-Samba server, and there must only be one domain master browser per
-workgroup name. To set up a Samba server as a domain master browser,
-set the following option in the [global] section of the smb.conf file :
-
- domain master = yes
-
-The domain master browser should also preferrably be the local master
-browser for its own subnet. In order to achieve this set the following
-options in the [global] section of the smb.conf file :
-
- domain master = yes
- local master = yes
- preferred master = yes
- os level = 65
-
-The domain master browser may be the same machine as the WINS
-server, if you require.
-
-Next, you should ensure that each of the subnets contains a
-machine that can act as a local master browser for the
-workgroup. Any NT machine should be able to do this, as will
-Windows 95 machines (although these tend to get rebooted more
-often, so it's not such a good idea to use these). To make a
-Samba server a local master browser set the following
-options in the [global] section of the smb.conf file :
-
- domain master = no
- local master = yes
- preferred master = yes
- os level = 65
-
-Do not do this for more than one Samba server on each subnet,
-or they will war with each other over which is to be the local
-master browser.
-
-The "local master" parameter allows Samba to act as a local master
-browser. The "preferred master" causes nmbd to force a browser
-election on startup and the "os level" parameter sets Samba high
-enough so that it should win any browser elections.
-
-If you have an NT machine on the subnet that you wish to
-be the local master browser then you can disable Samba from
-becoming a local master browser by setting the following
-options in the [global] section of the smb.conf file :
-
- domain master = no
- local master = no
- preferred master = no
- os level = 0
-
-Setting up Browsing in a DOMAIN
-===============================
-
-If you are adding Samba servers to a Windows NT Domain then
-you must not set up a Samba server as a domain master browser.
-By default, a Windows NT Primary Domain Controller for a Domain
-name is also the Domain master browser for that name, and many
-things will break if a Samba server registers the Domain master
-browser NetBIOS name (DOMAIN<1B>) with WINS instead of the PDC.
-
-For subnets other than the one containing the Windows NT PDC
-you may set up Samba servers as local master browsers as
-described. To make a Samba server a local master browser set
-the following options in the [global] section of the smb.conf
-file :
-
- domain master = no
- local master = yes
- preferred master = yes
- os level = 65
-
-If you wish to have a Samba server fight the election with machines
-on the same subnet you may set the "os level" parameter to lower
-levels. By doing this you can tune the order of machines that
-will become local master browsers if they are running. For
-more details on this see the section "FORCING SAMBA TO BE THE MASTER"
-below.
-
-If you have Windows NT machines that are members of the domain
-on all subnets, and you are sure they will always be running then
-you can disable Samba from taking part in browser elections and
-ever becoming a local master browser by setting following options
-in the [global] section of the smb.conf file :
-
- domain master = no
- local master = no
- preferred master = no
- os level = 0
-
-FORCING SAMBA TO BE THE MASTER
-==============================
-
-Who becomes the "master browser" is determined by an election process
-using broadcasts. Each election packet contains a number of parameters
-which determine what precedence (bias) a host should have in the
-election. By default Samba uses a very low precedence and thus loses
-elections to just about anyone else.
-
-If you want Samba to win elections then just set the "os level" global
-option in smb.conf to a higher number. It defaults to 0. Using 34
-would make it win all elections over every other system (except other
-samba systems!)
-
-A "os level" of 2 would make it beat WfWg and Win95, but not NTAS. A
-NTAS domain controller uses level 32.
-
-The maximum os level is 255
-
-If you want samba to force an election on startup, then set the
-"preferred master" global option in smb.conf to "yes". Samba will
-then have a slight advantage over other potential master browsers
-that are not preferred master browsers. Use this parameter with
-care, as if you have two hosts (whether they are windows 95 or NT or
-samba) on the same local subnet both set with "preferred master" to
-"yes", then periodically and continually they will force an election
-in order to become the local master browser.
-
-If you want samba to be a "domain master browser", then it is
-recommended that you also set "preferred master" to "yes", because
-samba will not become a domain master browser for the whole of your
-LAN or WAN if it is not also a local master browser on its own
-broadcast isolated subnet.
-
-It is possible to configure two samba servers to attempt to become
-the domain master browser for a domain. The first server that comes
-up will be the domain master browser. All other samba servers will
-attempt to become the domain master browser every 5 minutes. They
-will find that another samba server is already the domain master
-browser and will fail. This provides automatic redundancy, should
-the current domain master browser fail.
-
-
-MAKING SAMBA THE DOMAIN MASTER
-==============================
-
-The domain master is responsible for collating the browse lists of
-multiple subnets so that browsing can occur between subnets. You can
-make samba act as the domain master by setting "domain master = yes"
-in smb.conf. By default it will not be a domain master.
-
-Note that you should NOT set Samba to be the domain master for a
-workgroup that has the same name as an NT Domain.
-
-When samba is the domain master and the master browser it will listen
-for master announcements (made roughly every twelve minutes) from local
-master browsers on other subnets and then contact them to synchronise
-browse lists.
-
-If you want samba to be the domain master then I suggest you also set
-the "os level" high enough to make sure it wins elections, and set
-"preferred master" to "yes", to get samba to force an election on
-startup.
-
-Note that all your servers (including samba) and clients should be
-using a WINS server to resolve NetBIOS names. If your clients are only
-using broadcasting to resolve NetBIOS names, then two things will occur:
-
-a) your local master browsers will be unable to find a domain master
- browser, as it will only be looking on the local subnet.
-
-b) if a client happens to get hold of a domain-wide browse list, and
- a user attempts to access a host in that list, it will be unable to
- resolve the NetBIOS name of that host.
-
-If, however, both samba and your clients are using a WINS server, then:
-
-a) your local master browsers will contact the WINS server and, as long as
- samba has registered that it is a domain master browser with the WINS
- server, your local master browser will receive samba's ip address
- as its domain master browser.
-
-b) when a client receives a domain-wide browse list, and a user attempts
- to access a host in that list, it will contact the WINS server to
- resolve the NetBIOS name of that host. as long as that host has
- registered its NetBIOS name with the same WINS server, the user will
- be able to see that host.
-
-NOTE ABOUT BROADCAST ADDRESSES
-==============================
-
-If your network uses a "0" based broadcast address (for example if it
-ends in a 0) then you will strike problems. Windows for Workgroups
-does not seem to support a 0's broadcast and you will probably find
-that browsing and name lookups won't work.
-
-
-MULTIPLE INTERFACES
-===================
-
-Samba now supports machines with multiple network interfaces. If you
-have multiple interfaces then you will need to use the "interfaces"
-option in smb.conf to configure them. See smb.conf(5) for details.
-
diff --git a/docs/textdocs/BUGS.txt b/docs/textdocs/BUGS.txt
deleted file mode 100644
index 247998c6c7..0000000000
--- a/docs/textdocs/BUGS.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-Contributor: Samba Team
-Updated: June 27, 1997
-
-Subject: This file describes how to report Samba bugs.
-============================================================================
-
->> The email address for bug reports is samba@samba.org <<
-
-Please take the time to read this file before you submit a bug
-report. Also, please see if it has changed between releases, as we
-may be changing the bug reporting mechanism at some time.
-
-Please also do as much as you can yourself to help track down the
-bug. Samba is maintained by a dedicated group of people who volunteer
-their time, skills and efforts. We receive far more mail about it than
-we can possibly answer, so you have a much higher chance of an answer
-and a fix if you send us a "developer friendly" bug report that lets
-us fix it fast.
-
-Do not assume that if you post the bug to the comp.protocols.smb
-newsgroup or the mailing list that we will read it. If you suspect that your
-problem is not a bug but a configuration problem then it is better to send
-it to the Samba mailing list, as there are (at last count) 5000 other users on
-that list that may be able to help you.
-
-You may also like to look though the recent mailing list archives,
-which are conveniently accessible on the Samba web pages
-at http://samba.org/samba/
-
-
-GENERAL INFO
-------------
-
-Before submitting a bug report check your config for silly
-errors. Look in your log files for obvious messages that tell you that
-you've misconfigured something and run testparm to test your config
-file for correct syntax.
-
-Have you run through DIAGNOSIS.txt? This is very important.
-
-If you include part of a log file with your bug report then be sure to
-annotate it with exactly what you were doing on the client at the
-time, and exactly what the results were.
-
-
-DEBUG LEVELS
-------------
-
-If the bug has anything to do with Samba behaving incorrectly as a
-server (like refusing to open a file) then the log files will probably
-be very useful. Depending on the problem a log level of between 3 and
-10 showing the problem may be appropriate. A higher level givesmore
-detail, but may use too much disk space.
-
-To set the debug level use "log level =" in your smb.conf. You may
-also find it useful to set the log level higher for just one machine
-and keep separate logs for each machine. To do this use:
-
-log level = 10
-log file = /usr/local/samba/lib/log.%m
-include = /usr/local/samba/lib/smb.conf.%m
-
-then create a file "/usr/local/samba/lib/smb.conf.machine" where
-"machine" is the name of the client you wish to debug. In that file
-put any smb.conf commands you want, for example "log level=" may be
-useful. This also allows you to experiment with different security
-systems, protocol levels etc on just one machine.
-
-The smb.conf entry "log level =" is synonymous with the entry
-"debuglevel =" that has been used in older versions of Samba and
-is being retained for backwards compatibility of smb.conf files.
-
-As the "log level =" value is increased you will record a significantly
-increasing level of debugging information. For most debugging operations
-you may not need a setting higher than 3. Nearly all bugs can be tracked
-at a setting of 10, but be prepared for a VERY large volume of log data.
-
-
-INTERNAL ERRORs
----------------
-
-If you get a "INTERNAL ERROR" message in your log files it means that
-Samba got an unexpected signal while running. It is probably a
-segmentation fault and almost certainly means a bug in Samba (unless
-you have faulty hardware or system software)
-
-If the message came from smbd then it will probably be accompanied by
-a message which details the last SMB message received by smbd. This
-info is often very useful in tracking down the problem so please
-include it in your bug report.
-
-You should also detail how to reproduce the problem, if
-possible. Please make this reasonably detailed.
-
-You may also find that a core file appeared in a "corefiles"
-subdirectory of the directory where you keep your samba log
-files. This file is the most useful tool for tracking down the bug. To
-use it you do this:
-
-gdb smbd core
-
-adding appropriate paths to smbd and core so gdb can find them. If you
-don't have gdb then try "dbx". Then within the debugger use the
-command "where" to give a stack trace of where the problem
-occurred. Include this in your mail.
-
-If you known any assembly language then do a "disass" of the routine
-where the problem occurred (if its in a library routine then
-disassemble the routine that called it) and try to work out exactly
-where the problem is by looking at the surrounding code. Even if you
-don't know assembly then incuding this info in the bug report can be
-useful.
-
-
-ATTACHING TO A RUNNING PROCESS
-------------------------------
-
-Unfortunately some unixes (in particular some recent linux kernels)
-refuse to dump a core file if the task has changed uid (which smbd
-does often). To debug with this sort of system you could try to attach
-to the running process using "gdb smbd PID" where you get PID from
-smbstatus. Then use "c" to continue and try to cause the core dump
-using the client. The debugger should catch the fault and tell you
-where it occurred.
-
-
-PATCHES
--------
-
-The best sort of bug report is one that includes a fix! If you send us
-patches please use "diff -u" format if your version of diff supports
-it, otherwise use "diff -c4". Make sure your do the diff against a
-clean version of the source and let me know exactly what version you
-used.
-
diff --git a/docs/textdocs/DIAGNOSIS.txt b/docs/textdocs/DIAGNOSIS.txt
deleted file mode 100644
index 2816610a9c..0000000000
--- a/docs/textdocs/DIAGNOSIS.txt
+++ /dev/null
@@ -1,321 +0,0 @@
-Contributor: Andrew Tridgell
-Updated: November 1, 1999
-
-Subject: DIAGNOSING YOUR SAMBA SERVER
-===========================================================================
-
-This file contains a list of tests you can perform to validate your
-Samba server. It also tells you what the likely cause of the problem
-is if it fails any one of these steps. If it passes all these tests
-then it is probably working fine.
-
-You should do ALL the tests, in the order shown. I have tried to
-carefully choose them so later tests only use capabilities verified in
-the earlier tests.
-
-If you send me an email saying "it doesn't work" and you have not
-followed this test procedure then you should not be surprised if I
-ignore your email.
-
-
-ASSUMPTIONS
------------
-
-In all of the tests I assume you have a Samba server called BIGSERVER
-and a PC called ACLIENT both in workgroup TESTGROUP. I also assume the
-PC is running windows for workgroups with a recent copy of the
-microsoft tcp/ip stack. Alternatively, your PC may be running Windows
-95 or Windows NT (Workstation or Server).
-
-The procedure is similar for other types of clients.
-
-I also assume you know the name of an available share in your
-smb.conf. I will assume this share is called "tmp". You can add a
-"tmp" share like by adding the following to smb.conf:
-
-[tmp]
- comment = temporary files
- path = /tmp
- read only = yes
-
-
-THESE TESTS ASSUME VERSION 2.0.6 OR LATER OF THE SAMBA SUITE. SOME
-COMMANDS SHOWN DID NOT EXIST IN EARLIER VERSIONS
-
-Please pay attention to the error messages you receive. If any error message
-reports that your server is being unfriendly you should first check that you
-IP name resolution is correctly set up. eg: Make sure your /etc/resolv.conf
-file points to name servers that really do exist.
-
-Also, if you do not have DNS server access for name resolution please check
-that the settings for your smb.conf file results in "dns proxy = no". The
-best way to check this is with "testparm smb.conf"
-
-
-TEST 1:
--------
-
-In the directory in which you store your smb.conf file, run the command
-"testparm smb.conf". If it reports any errors then your smb.conf
-configuration file is faulty.
-
-Note: Your smb.conf file may be located in: /etc
- Or in: /usr/local/samba/lib
-
-
-TEST 2:
--------
-
-run the command "ping BIGSERVER" from the PC and "ping ACLIENT" from
-the unix box. If you don't get a valid response then your TCP/IP
-software is not correctly installed.
-
-Note that you will need to start a "dos prompt" window on the PC to
-run ping.
-
-If you get a message saying "host not found" or similar then your DNS
-software or /etc/hosts file is not correctly setup. It is possible to
-run samba without DNS entries for the server and client, but I assume
-you do have correct entries for the remainder of these tests.
-
-Another reason why ping might fail is if your host is running firewall
-software. You will need to relax the rules to let in the workstation
-in question, perhaps by allowing access from another subnet (on Linux
-this is done via the ipfwadm program.)
-
-
-TEST 3:
--------
-
-Run the command "smbclient -L BIGSERVER" on the unix box. You
-should get a list of available shares back.
-
-If you get a error message containing the string "Bad password" then
-you probably have either an incorrect "hosts allow", "hosts deny" or
-"valid users" line in your smb.conf, or your guest account is not
-valid. Check what your guest account is using "testparm" and
-temporarily remove any "hosts allow", "hosts deny", "valid users" or
-"invalid users" lines.
-
-If you get a "connection refused" response then the smbd server may
-not be running. If you installed it in inetd.conf then you probably edited
-that file incorrectly. If you installed it as a daemon then check that
-it is running, and check that the netbios-ssn port is in a LISTEN
-state using "netstat -a".
-
-If you get a "session request failed" then the server refused the
-connection. If it says "Your server software is being unfriendly" then
-its probably because you have invalid command line parameters to smbd,
-or a similar fatal problem with the initial startup of smbd. Also
-check your config file (smb.conf) for syntax errors with "testparm"
-and that the various directories where samba keeps its log and lock
-files exist.
-
-There are a number of reasons for which smbd may refuse or decline
-a session request. The most common of these involve one or more of
-the following smb.conf file entries:
- hosts deny = ALL
- hosts allow = xxx.xxx.xxx.xxx/yy
- bind interfaces only = Yes
-
-In the above, no allowance has been made for any session requests that
-will automatically translate to the loopback adaptor address 127.0.0.1.
-To solve this problem change these lines to:
- hosts deny = ALL
- hosts allow = xxx.xxx.xxx.xxx/yy 127.
-Do NOT use the "bind interfaces only" parameter where you may wish to
-use the samba password change facility, or where smbclient may need to
-access local service for name resolution or for local resource
-connections. (Note: the "bind interfaces only" parameter deficiency
-where it will not allow connections to the loopback address will be
-fixed soon).
-
-Another common cause of these two errors is having something already running
-on port 139, such as Samba (ie: smbd is running from inetd already) or
-something like Digital's Pathworks. Check your inetd.conf file before trying
-to start smbd as a daemon, it can avoid a lot of frustration!
-
-And yet another possible cause for failure of TEST 3 is when the subnet mask
-and / or broadcast address settings are incorrect. Please check that the
-network interface IP Address / Broadcast Address / Subnet Mask settings are
-correct and that Samba has correctly noted these in the log.nmb file.
-
-TEST 4:
--------
-
-Run the command "nmblookup -B BIGSERVER __SAMBA__". You should get the
-IP address of your Samba server back.
-
-If you don't then nmbd is incorrectly installed. Check your inetd.conf
-if you run it from there, or that the daemon is running and listening
-to udp port 137.
-
-One common problem is that many inetd implementations can't take many
-parameters on the command line. If this is the case then create a
-one-line script that contains the right parameters and run that from
-inetd.
-
-
-TEST 5:
--------
-
-run the command "nmblookup -B ACLIENT '*'"
-
-You should get the PCs IP address back. If you don't then the client
-software on the PC isn't installed correctly, or isn't started, or you
-got the name of the PC wrong.
-
-If ACLIENT doesn't resolve via DNS then use the IP address of the
-client in the above test.
-
-
-TEST 6:
--------
-
-Run the command "nmblookup -d 2 '*'"
-
-This time we are trying the same as the previous test but are trying
-it via a broadcast to the default broadcast address. A number of
-Netbios/TCPIP hosts on the network should respond, although Samba may
-not catch all of the responses in the short time it listens. You
-should see "got a positive name query response" messages from several
-hosts.
-
-If this doesn't give a similar result to the previous test then
-nmblookup isn't correctly getting your broadcast address through its
-automatic mechanism. In this case you should experiment use the
-"interfaces" option in smb.conf to manually configure your IP
-address, broadcast and netmask.
-
-If your PC and server aren't on the same subnet then you will need to
-use the -B option to set the broadcast address to the that of the PCs
-subnet.
-
-This test will probably fail if your subnet mask and broadcast address are
-not correct. (Refer to TEST 3 notes above).
-
-TEST 7:
--------
-
-Run the command "smbclient //BIGSERVER/TMP". You should then be
-prompted for a password. You should use the password of the account
-you are logged into the unix box with. If you want to test with
-another account then add the -U <accountname> option to the end of
-the command line. eg: smbclient //bigserver/tmp -Ujohndoe
-
-Note: It is possible to specify the password along with the username
-as follows:
- smbclient //bigserver/tmp -Ujohndoe%secret
-
-Once you enter the password you should get the "smb>" prompt. If you
-don't then look at the error message. If it says "invalid network
-name" then the service "tmp" is not correctly setup in your smb.conf.
-
-If it says "bad password" then the likely causes are:
-
-- you have shadow passords (or some other password system) but didn't
-compile in support for them in smbd
-- your "valid users" configuration is incorrect
-- you have a mixed case password and you haven't enabled the "password
-level" option at a high enough level
-- the "path =" line in smb.conf is incorrect. Check it with testparm
-- you enabled password encryption but didn't create the SMB encrypted
-password file
-
-Once connected you should be able to use the commands "dir" "get"
-"put" etc. Type "help <command>" for instructions. You should
-especially check that the amount of free disk space shown is correct
-when you type "dir".
-
-
-TEST 8:
--------
-
-On the PC type the command "net view \\BIGSERVER". You will need to do
-this from within a "dos prompt" window. You should get back a list of
-available shares on the server.
-
-If you get a "network name not found" or similar error then netbios
-name resolution is not working. This is usually caused by a problem in
-nmbd. To overcome it you could do one of the following (you only need
-to choose one of them):
-
-- fixup the nmbd installation
-- add the IP address of BIGSERVER to the "wins server" box in the
-advanced tcp/ip setup on the PC.
-- enable windows name resolution via DNS in the advanced section of
-the tcp/ip setup
-- add BIGSERVER to your lmhosts file on the PC.
-
-If you get a "invalid network name" or "bad password error" then the
-same fixes apply as they did for the "smbclient -L" test above. In
-particular, make sure your "hosts allow" line is correct (see the man
-pages)
-
-Also, do not overlook that fact that when the workstation requests the
-connection to the samba server it will attempt to connect using the
-name with which you logged onto your Windows machine. You need to make
-sure that an account exists on your Samba server with that exact same
-name and password.
-
-If you get "specified computer is not receiving requests" or similar
-it probably means that the host is not contactable via tcp services.
-Check to see if the host is running tcp wrappers, and if so add an entry in
-the hosts.allow file for your client (or subnet, etc.)
-
-
-TEST 9:
---------
-
-Run the command "net use x: \\BIGSERVER\TMP". You should be prompted
-for a password then you should get a "command completed successfully"
-message. If not then your PC software is incorrectly installed or your
-smb.conf is incorrect. make sure your "hosts allow" and other config
-lines in smb.conf are correct.
-
-It's also possible that the server can't work out what user name to
-connect you as. To see if this is the problem add the line "user =
-USERNAME" to the [tmp] section of smb.conf where "USERNAME" is the
-username corresponding to the password you typed. If you find this
-fixes things you may need the username mapping option.
-
-TEST 10:
---------
-
-Run the command "nmblookup -M TESTGROUP" where TESTGROUP is the name
-of the workgroup that your Samba server and Windows PCs belong to. You
-should get back the IP address of the master browser for that
-workgroup.
-
-If you don't then the election process has failed. Wait a minute to
-see if it is just being slow then try again. If it still fails after
-that then look at the browsing options you have set in smb.conf. Make
-sure you have "preferred master = yes" to ensure that an election is
-held at startup.
-
-TEST 11:
---------
-
-From file manager try to browse the server. Your samba server should
-appear in the browse list of your local workgroup (or the one you
-specified in smb.conf). You should be able to double click on the name
-of the server and get a list of shares. If you get a "invalid
-password" error when you do then you are probably running WinNT and it
-is refusing to browse a server that has no encrypted password
-capability and is in user level security mode. In this case either set
-"security = server" AND "password server = Windows_NT_Machine" in your
-smb.conf file, or enable encrypted passwords AFTER compiling in support
-for encrypted passwords (refer to the Makefile).
-
-
-Still having troubles?
-----------------------
-
-Try the mailing list or newsgroup, or use the tcpdump-smb utility to
-sniff the problem. The official samba mailing list can be reached at
-samba@samba.org. To find out more about samba and how to
-subscribe to the mailing list check out the samba web page at
- http://samba.org/samba
-
-Also look at the other docs in the Samba package!
-
diff --git a/docs/textdocs/DNIX.txt b/docs/textdocs/DNIX.txt
deleted file mode 100644
index 51005e6ec8..0000000000
--- a/docs/textdocs/DNIX.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-DNIX has a problem with seteuid() and setegid(). These routines are
-needed for Samba to work correctly, but they were left out of the DNIX
-C library for some reason.
-
-For this reason Samba by default defines the macro NO_EID in the DNIX
-section of includes.h. This works around the problem in a limited way,
-but it is far from ideal, some things still won't work right.
-
-To fix the problem properly you need to assemble the following two
-functions and then either add them to your C library or link them into
-Samba.
-
-put this in the file setegid.s:
-
- .globl _setegid
-_setegid:
- moveq #47,d0
- movl #100,a0
- moveq #1,d1
- movl 4(sp),a1
- trap #9
- bccs 1$
- jmp cerror
-1$:
- clrl d0
- rts
-
-
-put this in the file seteuid.s:
-
- .globl _seteuid
-_seteuid:
- moveq #47,d0
- movl #100,a0
- moveq #0,d1
- movl 4(sp),a1
- trap #9
- bccs 1$
- jmp cerror
-1$:
- clrl d0
- rts
-
-after creating the above files you then assemble them using
-
-as seteuid.s
-as setegid.s
-
-that should produce the files seteuid.o and setegid.o
-
-then you need to add these to the LIBSM line in the DNIX section of
-the Samba Makefile. Your LIBSM line will then look something like this:
-
-LIBSM = setegid.o seteuid.o -ln
-
-You should then remove the line:
-
-#define NO_EID
-
-from the DNIX section of includes.h
-
-Then recompile and try it out!
-
-Note that this file was derived from an email from Peter Olsson
-<pol@leissner.se>. I don't have DNIX myself, so you're probably better
-off contacting Peter if you have problems.
-
-Andrew
-
diff --git a/docs/textdocs/GROUP-MAPPING-HOWTO.txt b/docs/textdocs/GROUP-MAPPING-HOWTO.txt
deleted file mode 100644
index c266f56548..0000000000
--- a/docs/textdocs/GROUP-MAPPING-HOWTO.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Samba 3.0 prealpha guide to group mapping
----------------------------------------------------
-
-Jean François Micouleau (jfm@samba.org)
-
-Starting with Samba 3.0 alpha 2, a new group mapping function is available. The
-current method (likely to change) to manage the groups is a new command called
-smbgroupedit.
-
-The first immediate reason to use the group mapping on a PDC, is that
-the 'domain admin group' of smb.conf is now gone. This parameter was
-used to give the listed users local admin rights on their
-workstations. It was some magic stuff that simply worked but didn't
-scale very well for complex setups.
-
-Let me explain how it works on NT/W2K, to have this magic fade away.
-When installing NT/W2K on a computer, the installer program creates some users
-and groups. Notably the 'Administrators' group, and gives to that group some
-privileges like the ability to change the date and time or to kill any process
-(or close too) running on the local machine. The 'Administrator' user is a
-member of the 'Administrators' group, and thus 'inherit' the 'Administrators'
-group privileges. If a 'joe' user is created and become a member of the
-'Administrator' group, 'joe' has exactly the same rights as 'Administrator'.
-
-When a NT/W2K machine is joined to a domain, during that phase, the "Domain
-Administrators' group of the PDC is added to the 'Administrators' group of the
-workstation. Every members of the 'Domain Administrators' group 'inherit' the
-rights of the 'Administrators' group when logging on the workstation.
-
-
-You are now wondering how to make some of your samba PDC users members of the
-'Domain Administrators' ? That's really easy.
-
-1) create a unix group (usually in /etc/group), let's call it domadm
-2) add to this group the users that must be Administrators. For example if you
-want joe,john and mary, your entry in /etc/group will look like:
-
- domadm:x:502:joe,john,mary
-
-3) map this domadm group to the 'domain admins' group by running the command:
-
- smbgroupedit -c "Domain Admins" -u domadm
-
-you're set, joe, john and mary are domain administrators !
-
-
-
-Like the Domain Admins group, you can map any arbitrary Unix group to any NT
-group. You can also make any Unix group a domain group. For example, on a domain
-member machine (an NT/W2K or a samba server running winbind), you would like to
-give access to a certain directory to some users who are member of a group on
-your samba PDC. Flag that group as a domain group by running:
-
- smbgroupedit -a unixgroup -td
-
-
-You can list the various groups in the mapping database like this
-
- smbgroupedit -v
-
diff --git a/docs/textdocs/INSTALL.sambatar b/docs/textdocs/INSTALL.sambatar
deleted file mode 100644
index 413f54d3c6..0000000000
--- a/docs/textdocs/INSTALL.sambatar
+++ /dev/null
@@ -1,33 +0,0 @@
-Contributor: Ricky Poulten <poultenr@logica.co.uk>
-Date: Unknown
-Status: Current
-
-Subject: Using smbtar
-=============================================================================
-
-Please see the readme and the man page for general info.
-
-1) Follow the samba installation instructions.
-
-2) If all goes well, test it out by creating a share on your PC (called
-backup for example) then doing something like,
-
- ./smbtar -s mypc -t /dev/rmt/0ubn -x backup
-
-substituting whatever your tape drive is for the -t option, or set your
-tape environmental variable.
-
-If all does not go well, feel free to mail the author (poultenr@logica.co.uk)
-about bug reports / help / money / pizza / etc.
-
-3) Read the man page and the NOTES file for more information
-
-4) Work smbtar into your usual nightly backup scheme (presuming you
-have one :-}).
-
-
-NOTE:
-
-If you have problems with smbtar then it's probably best to contact the
-author Ricky Poulten (poultenr@logica.co.uk).
-
diff --git a/docs/textdocs/Imprints.txt b/docs/textdocs/Imprints.txt
deleted file mode 100644
index 4ea9782bd3..0000000000
--- a/docs/textdocs/Imprints.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-==================================================================
-
-
-Imprints (Installation Manager of Printer driver
-Retreival and Installation for Samba) is a project to
-implement a UNIX equivalent of the Windows NT APW.
-It has been taken on in part by the Samba Team, VA Linux
-Systems and Hewlett-Packard. The Imprints toolset seeks
-to provide central repository for users and administrators
-to locate, download, and install all variations Window
-95/98/NT printer drivers on Samba print servers.
-
-The server portion of Imprints is composed of a database
-server which contains information and locations of various
-printer driver packages. This server can be queried over
-standard HTTP get requests and should therefore be available
-to most administrators behind firewalls. The server's
-database consists of records containing data about each
-known printer driver package. For example, each driver
-record contains a URL from which the Imprints installation
-client can download the package as well as a public key which
-can be used to verify the package's integrity.
-
-Once downloaded, the installation client will attempt to
-install the printer driver on the defined remote server
-using the username and password provided by the administrator.
-If the username/password pair can be authenticated by the
-remote server (and has the appropriate authorization), then
-the printer driver(s) is (are) installed and the new Printer
-is created.
-
-From Samba's point of view, the process of creating a new
-printer via the Imprints installation client is identical to
-that of using the Windows NT APW. In fact, Imprints utilizes
-Samba's rpcclient and smbclient tools to issue the same MS-RPC
-and file copy operations as an NT client. This means that
-Imprints can also be used to install printers on remote Windows
-NT print servers.
-
-For more information on Imprints, visit the project homepage
-at
-
- http://imprints.sourceforge.net/.
-
-
-
-
diff --git a/docs/textdocs/Macintosh_Clients.txt b/docs/textdocs/Macintosh_Clients.txt
deleted file mode 100644
index dfac97e1aa..0000000000
--- a/docs/textdocs/Macintosh_Clients.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-> Are there any Macintosh clients for Samba?
-
-Yes. Thursby now have a CIFS Client / Server called DAVE - see
-http://www.thursby.com/
-
-They test it against Windows 95, Windows NT and samba for
-compatibility issues. At the time of writing, DAVE was at version
-1.0.1. The 1.0.0 to 1.0.1 update is available as a free download from
-the Thursby web site (the speed of finder copies has been greatly
-enhanced, and there are bug-fixes included).
-
-Alternatives - There are two free implementations of AppleTalk for
-several kinds of UNIX machnes, and several more commercial ones.
-These products allow you to run file services and print services
-natively to Macintosh users, with no additional support required on
-the Macintosh. The two free omplementations are Netatalk,
-http://www.umich.edu/~rsug/netatalk/, and CAP,
-http://www.cs.mu.oz.au/appletalk/atalk.html. What Samba offers MS
-Windows users, these packages offer to Macs. For more info on these
-packages, Samba, and Linux (and other UNIX-based systems) see
-http://www.eats.com/linux_mac_win.html
-
-
diff --git a/docs/textdocs/NetBIOS.txt b/docs/textdocs/NetBIOS.txt
deleted file mode 100644
index ca0dcc84b7..0000000000
--- a/docs/textdocs/NetBIOS.txt
+++ /dev/null
@@ -1,152 +0,0 @@
-Contributor: lkcl - samba@samba.org
- Copyright 1997 Luke Kenneth Casson Leighton
-Date: March 1997
-Status: Current
-Updated: 12jun97
-
-Subject: Definition of NetBIOS Protocol and Name Resolution Modes
-=============================================================================
-
-=======
-NETBIOS
-=======
-
-NetBIOS runs over the following tranports: TCP/IP; NetBEUI and IPX/SPX.
-Samba only uses NetBIOS over TCP/IP. For details on the TCP/IP NetBIOS
-Session Service NetBIOS Datagram Service, and NetBIOS Names, see
-rfc1001.txt and rfc1002.txt.
-
-NetBEUI is a raw NetBIOS frame protocol implementation that allows NetBIOS
-datagrams to be sent out over the 'wire' embedded within LLC frames.
-NetBEUI is not required when using NetBIOS over TCP/IP protocols and it
-is preferable NOT to install NetBEUI if it can be avoided.
-
-IPX/SPX is also not required when using NetBIOS over TCP/IP, and it is
-preferable NOT to install the IPX/SPX transport unless you are using Novell
-servers. At the very least, it is recommended that you do not install
-'NetBIOS over IPX/SPX'.
-
-[When installing Windows 95, you will find that NetBEUI and IPX/SPX are
-installed as the default protocols. This is because they are the simplest
-to manage: no Windows 95 user-configuration is required].
-
-
-NetBIOS applications (such as samba) offer their services (for example,
-SMB file and print sharing) on a NetBIOS name. They must claim this name
-on the network before doing so. The NetBIOS session service will then
-accept connections on the application's behalf (on the NetBIOS name
-claimed by the application). A NetBIOS session between the application
-and the client can then commence.
-
-NetBIOS names consist of 15 characters plus a 'type' character. This is
-similar, in concept, to an IP address and a TCP port number, respectively.
-A NetBIOS-aware application on a host will offer different services under
-different NetBIOS name types, just as a host will offer different TCP/IP
-services on different port numbers.
-
-NetBIOS names must be claimed on a network, and must be defended. The use
-of NetBIOS names is most suitable on a single subnet; a Local Area Network
-or a Wide Area Network.
-
-NetBIOS names are either UNIQUE or GROUP. Only one application can claim a
-UNIQUE NetBIOS name on a network.
-
-There are two kinds of NetBIOS Name resolution: Broadcast and Point-to-Point.
-
-
-=================
-BROADCAST NetBIOS
-=================
-
-Clients can claim names, and therefore offer services on successfully claimed
-names, on their broadcast-isolated subnet. One way to get NetBIOS services
-(such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
-SMB file/print sharing: see cifs4.txt) working on a LAN or WAN is to make
-your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
-
-This, however, is not recommended. If you have a large LAN or WAN, you will
-find that some of your hosts spend 95 percent of their time dealing with
-broadcast traffic. [If you have IPX/SPX on your LAN or WAN, you will find
-that this is already happening: a packet analyzer will show, roughly
-every twelve minutes, great swathes of broadcast traffic!].
-
-
-============
-NBNS NetBIOS
-============
-
-rfc1001.txt describes, amongst other things, the implementation and use
-of, a 'NetBIOS Name Service'. NT/AS offers 'Windows Internet Name Service'
-which is fully rfc1001/2 compliant, but has had to take specific action
-with certain NetBIOS names in order to make it useful. (for example, it
-deals with the registration of <1c> <1d> <1e> names all in different ways.
-I recommend the reading of the Microsoft WINS Server Help files for full
-details).
-
-Samba also offers WINS server capabilities. Samba does not interact
-with NT/AS (WINS replication), so if you have a mixed NT server and
-Samba server environment, it is recommended that you use the NT server's
-WINS capabilities, instead of samba's WINS server capabilities.
-
-The use of a WINS server cuts down on broadcast network traffic for
-NetBIOS name resolution. It has the effect of pulling all the broadcast
-isolated subnets together into a single NetBIOS scope, across your LAN
-or WAN, while avoiding the use of TCP/IP broadcast packets.
-
-When you have a WINS server on your LAN, WINS clients will be able to
-contact the WINS server to resolve NetBIOS names. Note that only those
-WINS clients that have registered with the same WINS server will be
-visible. The WINS server _can_ have static NetBIOS entries added to its
-database (usually for security reasons you might want to consider putting
-your domain controllers or other important servers as static entries,
-but you should not rely on this as your sole means of security), but for
-the most part, NetBIOS names are registered dynamically.
-
-[It is important to mention that samba's browsing capabilities (as a WINS
-client) must have access to a WINS server. if you are using samba also
-as a WINS server, then it will have a direct short-cut into the WINS
-database.
-
-This provides some confusion for lots of people, and is worth mentioning
-here: a Browse Server is NOT a WINS Server, even if these services are
-implemented in the same application. A Browse Server _needs_ a WINS server
-because a Browse Server is a WINS client, which is _not_ the same thing].
-
-Clients can claim names, and therefore offer services on successfully claimed
-names, on their broadcast-isolated subnet. One way to get NetBIOS services
-(such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
-SMB file/print sharing: see cifs6.txt) working on a LAN or WAN is to make
-your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
-You will find, however, if you do this on a large LAN or a WAN, that your
-network is completely swamped by NetBIOS and browsing packets, which is why
-WINS was developed to minimise the necessity of broadcast traffic.
-
-WINS Clients therefore claim names from the WINS server. If the WINS
-server allows them to register a name, the client's NetBIOS session service
-can then offer services on this name. Other WINS clients will then
-contact the WINS server to resolve a NetBIOS name.
-
-
-=======================
-Samba WINS Capabilities
-=======================
-
-To configure samba as a WINS server, you must add "wins support = yes" to
-the [global] section of your smb.conf file. This will enable WINS server
-capabilities in nmbd.
-
-To configure samba as a WINS client, you must add "wins server = x.x.x.x"
-to the [global] section of your smb.conf file, where x.x.x.x is the TCP/IP
-address of your WINS server. The browsing capabilities in nmbd will then
-register (and resolve) WAN-wide NetBIOS names with this WINS server.
-
-Note that if samba has "wins support = yes", then the browsing capabilities
-will _not_ use the "wins server" option to resolve NetBIOS names: it will
-go directly to the internal WINS database for NetBIOS name resolution. It
-is therefore invalid to have both "wins support = yes" and
-"wins server = x.x.x.x". Note, in particular, that if you configure the
-"wins server" parameter to be the ip address of your samba server itself
-(as might one intuitively think), that you will run into difficulties.
-Do not use both parameters!
-
-
diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt
deleted file mode 100644
index 25d4c816f0..0000000000
--- a/docs/textdocs/Passwords.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Contributor: Unknown
-Date: Updated April 19th 1999.
-Status: Current
-
-Subject: NOTE ABOUT PASSWORDS
-=============================================================================
-
-Unix systems use a wide variety of methods for checking the validity
-of a password. This is primarily controlled with the Makefile defines
-mentioned in the Makefile.
-
-Also note that some clients (notably WfWg) uppercase the password
-before sending it. The server tries the password as it receives it and
-also after lowercasing it.
-
-The Samba server can also be configured to try different
-upper/lowercase combinations. This is controlled by the [global]
-parameter "password level". A level of N means to try all combinations
-up to N uppercase characters in the password. A high value can chew a
-fair bit of CPU time and can lower the security of your system. Do not
-use this options unless you really need it - the time taken for
-password checking can become so high that clients time out.
-
-If you do use the "password level" option then you might like to use
--DUFC_CRYPT in your Makefile. On some machine this makes password
-checking _much_ faster. This is also useful if you use the @group
-syntax in the user= option.
-
-If your site uses AFS (the Andrew File System), you can use the AFS section
-in the Makefile. This will first attempt to authenticate a username and
-password to AFS. If that succeeds, then the associated AFS rights will be
-granted. Otherwise, the password checking routine falls back to whatever
-Unix password checking method you are using. Note that the AFS code is
-only written and tested for AFS 3.3 and later.
-
-
-SECURITY = SERVER or DOMAIN
-===========================
-
-Samba can use a remote server to do its username/password
-validation. This allows you to have one central machine (for example a
-NT box) control the passwords for the Unix box.
-
-See the section on "security =" in smb.conf(5) for details.
-
-
diff --git a/docs/textdocs/Printing.txt b/docs/textdocs/Printing.txt
deleted file mode 100644
index 2c50e5f4fe..0000000000
--- a/docs/textdocs/Printing.txt
+++ /dev/null
@@ -1,255 +0,0 @@
-Contributor: Unknown <samba@samba.org>
-Revised by: Patrick Powell <papowell@lprng.org>
-Date: August 11, 2000
-Status: Current
-
-Subject: Debugging Printing Problems
-=============================================================================
-
-This is a short description of how to debug printing problems with
-Samba. This describes how to debug problems with printing from a SMB
-client to a Samba server, not the other way around. For the reverse
-see the examples/printing directory.
-
-Please send enhancements to this file to samba@samba.org
-
-Ok, so you want to print to a Samba server from your PC. The first
-thing you need to understand is that Samba does not actually do any
-printing itself, it just acts as a middleman between your PC client
-and your Unix printing subsystem. Samba receives the file from the PC
-then passes the file to a external "print command". What print command
-you use is up to you.
-
-The whole things is controlled using options in smb.conf. The most
-relevant options (which you should look up in the smb.conf man page)
-are:
- [global]
- print command - send a file to a spooler
- lpq command - get spool queue status
- lprm command - remove a job
- [printers]
- path = /var/spool/lpd/samba
-
-The following are nice to know about:
-
- queuepause command - stop a printer or print queue
- queueresume command - start a printer or print queue
-
-Example:
- print command = /usr/bin/lpr -r -P%p %s
- lpq command = /usr/bin/lpq -P%p %s
- lprm command = /usr/bin/lprm -P%p %j
- queuepause command = /usr/sbin/lpc -P%p stop
- queuepause command = /usr/sbin/lpc -P%p start
-
-Samba should set reasonable defaults for these depending on your
-system type, but it isn't clairvoyant. It is not uncommon that you
-have to tweak these for local conditions. The commands should
-always have fully specified pathnames, as the smdb may not have
-the correct PATH values.
-
-When you send a job to Samba to be printed, it will make a temporary
-copy of it in the directory specified in the [printers] section.
-and it should be periodically cleaned out. The lpr -r option
-requests that the temporary copy be removed after printing; If
-printing fails then you might find leftover files in this directory,
-and it should be periodically cleaned out. Samba used the lpq
-command to determine the "job number" assigned to your print job
-by the spooler.
-
-The %<letter> are "macros" that get dynamically replaced with appropriate
-values when they are used. The %s gets replaced with the name of the spool
-file that Samba creates and the %p gets replaced with the name of the
-printer. The %j gets replaced with the "job number" which comes from
-the lpq output.
-
-DEBUGGING PRINTER PROBLEMS
-
-One way to debug printing problems is to start by replacing these
-command with shell scripts that record the arguments and the contents
-of the print file. A simple example of this kind of things might
-be:
-
- print command = /tmp/saveprint %p %s
-
- #!/bin/saveprint
- # we make sure that we are the right user
- /usr/bin/id -p >/tmp/tmp.print
- # we run the command and save the error messages
- # replace the command with the one appropriate for your system
- /usr/bin/lpr -r -P$1 $2 2>>&/tmp/tmp.print
-
-Then you print a file and try removing it. You may find that the
-print queue needs to be stopped in order to see the queue status
-and remove the job:
-
-h4: {42} % echo hi >/tmp/hi
-h4: {43} % smbclient //localhost/lw4
-added interface ip=10.0.0.4 bcast=10.0.0.255 nmask=255.255.255.0
-Password:
-Domain=[ASTART] OS=[Unix] Server=[Samba 2.0.7]
-smb: \> print /tmp/hi
-putting file /tmp/hi as hi-17534 (0.0 kb/s) (average 0.0 kb/s)
-smb: \> queue
-1049 3 hi-17534
-smb: \> cancel 1049
-Error cancelling job 1049 : code 0
-smb: \> cancel 1049
-Job 1049 cancelled
-smb: \> queue
-smb: \> exit
-
-The 'code 0' indicates that the job was removed. The comment
-by the smbclient is a bit misleading on this.
-You can observe the command output and then and look at the
-/tmp/tmp.print file to see what the results are. You can quickly
-find out if the problem is with your printing system. Often people
-have problems with their /etc/printcap file or permissions on
-various print queues.
-
-WHAT PRINTERS DO I HAVE
-
-You can use the 'testprns' program to check to see if the printer
-name you are using is recognized by Samba. For example, you can
-use:
-
- testprns printer /etc/printcap
-
-Samba can get its printcap information from a file or from a program.
-You can try the following to see the format of the extracted
-information:
-
- testprns -a printer /etc/printcap
-
- testprns -a printer '|/bin/cat printcap'
-
-SETTING UP PRINTCAP AND PRINT SERVERS
-
-You may need to set up some printcaps for your Samba system to use.
-It is strongly recommended that you use the facilities provided by
-the print spooler to set up queues and printcap information.
-
-Samba requires either a printcap or program to deliver printcap
-information. This printcap information has the format:
-
- name|alias1|alias2...:option=value:...
-
-For almost all printing systems, the printer 'name' must be composed
-only of alphanumeric or underscore '_' characters. Some systems also
-allow hyphens ('-') as well. An alias is an alternative name for the
-printer, and an alias with a space in it is used as a 'comment'
-about the printer. The printcap format optionally uses a \ at the end of lines
-to extend the printcap to multiple lines.
-
-
-Here are some examples of printcap files:
-
-pr just printer name
-pr|alias printer name and alias
-pr|My Printer printer name, alias used as comment
-pr:sh:\ Same as pr:sh:cm= testing
- :cm= \
- testing
-pr:sh Same as pr:sh:cm= testing
- :cm= testing
-
-Samba reads the printcap information when first started. If you make
-changes in the printcap information, then you must do the following:
-
-a) make sure that the print spooler is aware of these changes.
- The LPRng system uses the 'lpc reread' command to do this.
-
-b) make sure that the spool queues, etc., exist and have the
- correct permissions. The LPRng system uses the 'checkpc -f'
- command to do this.
-
-c) You now should send a SIGHUP signal to the smbd server to have
- it reread the printcap information.
-
-JOB SENT, NO OUTPUT
-
-This is the most frustrating part of printing. You may have sent the
-job, verified that the job was forwarded, set up a wrapper around
-the command to send the file, but there was no output from the printer.
-
-First, check to make sure that the job REALLY is getting to the
-right print queue. If you are using a BSD or LPRng print spooler,
-you can temporarily stop the printing of jobs. Jobs can still be
-submitted, but they will not be printed. Use:
-
- lpc -Pprinter stop
-
-Now submit a print job and then use 'lpq -Pprinter' to see if the
-job is in the print queue. If it is not in the print queue then
-you will have to find out why it is not being accepted for printing.
-
-Next, you may want to check to see what the format of the job really
-was. With the assistance of the system administrator you can view
-the submitted jobs files. You may be surprised to find that these
-are not in what you would expect to call a printable format.
-You can use the UNIX 'file' utitily to determine what the job
-format actually is:
-
- cd /var/spool/lpd/printer # spool directory of print jobs
- ls # find job files
- file dfA001myhost
-
-You should make sure that your printer supports this format OR that
-your system administrator has installed a 'print filter' that will
-convert the file to a format appropriate for your printer.
-
-JOB SENT, STRANGE OUTPUT
-
-Once you have the job printing, you can then start worrying about
-making it print nicely.
-
-The most common problem is extra pages of output: banner pages
-OR blank pages at the end.
-
-If you are getting banner pages, check and make sure that the
-printcap option or printer option is configured for no banners.
-If you have a printcap, this is the :sh (suppress header or banner
-page) option. You should have the following in your printer.
-
- printer: ... :sh
-
-If you have this option and are still getting banner pages, there
-is a strong chance that your printer is generating them for you
-automatically. You should make sure that banner printing is disabled
-for the printer. This usually requires using the printer setup software
-or procedures supplied by the printer manufacturer.
-
-If you get an extra page of output, this could be due to problems
-with your job format, or if you are generating PostScript jobs,
-incorrect setting on your printer driver on the MicroSoft client.
-For example, under Win95 there is a option:
-
- Printers|Printer Name|(Right Click)Properties|Postscript|Advanced|
-
-that allows you to choose if a Ctrl-D is appended to all jobs.
-This is a very bad thing to do, as most spooling systems will
-automatically add a ^D to the end of the job if it is detected as
-PostScript. The multiple ^D may cause an additional page of output.
-
-RAW POSTSCRIPT PRINTED
-
-This is a problem that is usually caused by either the print spooling
-system putting information at the start of the print job that makes
-the printer think the job is a text file, or your printer simply
-does not support PostScript. You may need to enable 'Automatic
-Format Detection' on your printer.
-
-ADVANCED PRINTING
-
-Note that you can do some pretty magic things by using your
-imagination with the "print command" option and some shell scripts.
-Doing print accounting is easy by passing the %U option to a print
-command shell script. You could even make the print command detect
-the type of output and its size and send it to an appropriate
-printer.
-
-DEBUGGING
-
-If the above debug tips don't help, then maybe you need to bring in
-the bug guns, system tracing. See Tracing.txt in this directory.
------------------------------------------------------------------------------
diff --git a/docs/textdocs/README.sambatar b/docs/textdocs/README.sambatar
deleted file mode 100644
index af7250c2a4..0000000000
--- a/docs/textdocs/README.sambatar
+++ /dev/null
@@ -1,23 +0,0 @@
-Contributor/s: Martin.Kraemer <Martin.Kraemer@mch.sni.de>
- and Ricky Poulten (ricky@logcam.co.uk)
-Date: Unknown - circa 1994
-Status: Obsoleted - smbtar has been a stable part of Samba
- since samba-1.9.13
-
-Subject: Sambatar (now smbtar)
-=============================================================================
-
-This is version 1.4 of my small extension to samba that allows PC shares
-to be backed up directly to a UNIX tape. It only has been tested under
-Solaris 2.3, Linux 1.1.59 and DG/UX 5.4r3.10 with version 1.9.13 of samba.
-
-See the file INSTALL for installation instructions, and
-the man page and NOTES file for some basic usage. Please let me know if you
-have any problems getting it to work under your flavour of Unix.
-
-This is only (yet another) intermediate version of sambatar.
-This version also comes with an extra gift, zen.bas, written in
-microsoft qbasic by a colleague. It is (apparently) based on a 70s
-British sci-fi series known as Blake's 7. If you have any questions
-about this program, or any suggestions (e.g. what about servillan.bas
-?), feel free to mail the author (of zen.bas) greenm@lilhd.logica.com.
diff --git a/docs/textdocs/SCO.txt b/docs/textdocs/SCO.txt
deleted file mode 100644
index 7c01aa57c6..0000000000
--- a/docs/textdocs/SCO.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Contributor: Geza Makay <makayg@math.u-szeged.hu>
-Date: Unknown
-Status: Obsolete - Dates to SCO Unix v3.2.4 approx.
-
-Subject: TCP/IP Bug in SCO Unix
-============================================================================
-
-There is an annoying TCPIP bug in SCO Unix. This causes corruption when
-transferring files with Samba.
-
-Geza Makay (makayg@math.u-szeged.hu) sends this information:
-
-The patch you need is UOD385 Connection Drivers SLS. It is available from
-SCO (ftp.sco.com, directory SLS, files uod385a.Z and uod385a.ltr.Z).
-
-You do not need anything else but the above patch. It installs in seconds,
-and corrected the Excel problem. We also had some other minor problems (not
-only with Samba) that disappeared by installing this patch.
-
diff --git a/docs/textdocs/SMBTAR.notes b/docs/textdocs/SMBTAR.notes
deleted file mode 100644
index 679d776f56..0000000000
--- a/docs/textdocs/SMBTAR.notes
+++ /dev/null
@@ -1,46 +0,0 @@
-Contributor: Unknown
-Date: 1994
-Status: Mostly Current - refer man page
-
-Subject: Smbtar
-============================================================================
-
-Intro
------
-
-sambatar is just a small extension to the smbclient program distributed with
-samba. A basic front end shell script, smbtar, is provided as an interface
-to the smbclient extensions.
-
-Extensions
-----------
-
-This release adds the following extensions to smbclient,
-
-tar [c|x] filename
- creates or restores from a tar file. The tar file may be a tape
-or a unix tar file. tar's behaviour is modified with the newer and tarmode
-commands.
-
-tarmode [full|inc|reset|noreset]
- With no arguments, tarmode prints the current tar mode (by default full,
-noreset). In full mode, every file is backed up during a tar command.
-In incremental, only files with the dos archive bit set are backed up.
-The archive bit is reset if in reset mode, or left untouched if in noreset.
-In reset mode, the share has to be writable, which makes sambatar even
-less secure. An alternative might be to use tarmode inc noreset which
-would implement an "expanding incremental" backup (which some may prefer
-anyway).
-
-setmode <setmode string> filename
- This is a "freebie" - nothing really to do with sambatar. This
-is a crude attrib like command (only the other way around). Setmode string
-is a combination of +-rhsa. So for example -rh would reset the read only
-bit on filename.
-
-newer filename
- This is in fact part of the 1.9.13 samba distribution, but comes
-into its own with sambatar. This causes tar (or get, mget, etc) to
-only copy files newer than the specified file name. Could be used
-against the previous nights (or whatever) log file to implement incremental
-backups.
diff --git a/docs/textdocs/Samba-OpenSSL.txt b/docs/textdocs/Samba-OpenSSL.txt
deleted file mode 100644
index e1b54b1a03..0000000000
--- a/docs/textdocs/Samba-OpenSSL.txt
+++ /dev/null
@@ -1,405 +0,0 @@
-Contributor: Christian Starkjohann <cs@obdev.at>
-Date: May 29, 1998
-Status:
-
-Comment: Updated by Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>
-Date: July 16, 2001
-
-Subject: Compiling and using samba with SSL support
-============================================================================
-
-What is SSL and SSLeay/OpenSSL?
-===============================
-SSL (Secure Socket Layer) is a protocol for encrypted and authenticated data
-transport. It is used by secure web servers for shopping malls, telebanking
-and things like that.
-
-SSLeay is a free implementation of the SSL protocol. The successor of it is
-OpenSSL, available from
-
- http://www.openssl.org/
-
-The current version while these lines are written is 0.9.6b. In some countries
-encryption is plagued by legal problems, even though things have relaxed a
-lot in the last years.
-
-To compile samba with SSL support, you must first compile and install OpenSSL.
-At least version 0.9.5 of OpenSSL is required. Version 0.9.6b is the latest
-version and is strongly recommended.
-OpenSSL consists of a library (which can be linked to other applications like
-samba) and several utility programs needed for key generation, certification
-etc. OpenSSL installs to /usr/local/ssl/ by default.
-
-
-Compiling samba with OpenSSL
-============================
-1. Get and install OpenSSL. The rest of this documentation assumes that you
- have installed it at the default location, which is /usr/local/ssl/.
-2. Call "configure" with the "--with-ssl" flag. If OpenSSL is not installed in
- the default directory, you can use the "--with-sslinc" and "--with-ssllib"
- flags to specify the location.
-3. Compile and install as usual.
-
-
-Configuring SSL in samba
-========================
-Before you configure SSL, you should know the basics of cryptography and how
-SSL relates to all of this. A basic introduction can be found further down in
-this document. The following variables in the "[global]" section of the
-configuration file are used to configure SSL:
-
-ssl = yes
- This variable enables or disables the entire SSL mode. If it is set to
- "no", the SSL enabled samba behaves exactly like the non-SSL samba. If set
- to "yes", it depends on the variables "ssl hosts" and "ssl hosts resign"
- whether an SSL connection will be required.
-ssl hosts =
-ssl hosts resign = 192.168.
- These two variables define whether samba will go into SSL mode or not. If
- none of them is defined, samba will allow only SSL connections. If the
- "ssl hosts" variable lists hosts (by IP-address, IP-address range, net
- group or name), only these hosts will be forced into SSL mode. If the
- "ssl hosts resign" variable lists hosts, only these hosts will NOT be
- forced into SSL mode. The syntax for these two variables is the same as
- for the "hosts allow" and "hosts deny" pair of variables, only that the
- subject of the decision is different: It's not the access right but
- whether SSL is used or not. See the man page of smb.conf (section about
- "allow hosts") for details. The above example requires SSL connections
- from all hosts outside the local net (which is 192.168.*.*).
-ssl CA certDir = /usr/local/ssl/certs
- This variable defines where to look up the Certification Autorities. The
- given directory should contain one file for each CA that samba will trust.
- The file name must be the hash value over the "Distinguished Name" of the
- CA. How this directory is set up is explained later in this document. All
- files within the directory that don't fit into this naming scheme are
- ignored. You don't need this variable if you don't verify client
- certificates.
-ssl CA certFile = /usr/local/ssl/certs/trustedCAs.pem
- This variable is a second way to define the trusted CAs. The certificates
- of the trusted CAs are collected in one big file and this variable points
- to the file. You will probably only use one of the two ways to define your
- CAs. The first choice is preferable if you have many CAs or want to be
- flexible, the second is perferable if you only have one CA and want to
- keep things simple (you won't need to create the hashed file names). You
- don't need this variable if you don't verify client certificates.
-ssl server cert = /usr/local/ssl/certs/samba.pem
- This is the file containing the server's certificate. The server _must_
- have a certificate. The file may also contain the server's private key.
- See later for how certificates and private keys are created.
-ssl server key = /usr/local/ssl/private/samba.pem
- This file contains the private key of the server. If this variable is not
- defined, the key is looked up in the certificate file (it may be appended
- to the certificate). The server _must_ have a private key and the
- certificate _must_ match this private key.
-ssl client cert = /usr/local/ssl/certs/smbclient.pem
- The certificate in this file is used by smbclient if it exists. It's needed
- if the server requires a client certificate.
-ssl client key = /usr/local/ssl/private/smbclient.pem
- This is the private key for smbclient. It's only needed if the client
- should have a certificate.
-ssl require clientcert = yes
- If this variable is set to "yes", the server will not tolerate connections
- from clients that don't have a valid certificate. The directory/file
- given in "ssl CA certDir" and "ssl CA certFile" will be used to look up
- the CAs that issued the client's certificate. If the certificate can't be
- verified positively, the connection will be terminated.
- If this variable is set to "no", clients don't need certificates. Contrary
- to web applications you really _should_ require client certificates. In
- the web environment the client's data is sensitive (credit card numbers)
- and the server must prove to be trustworthy. In a file server environment
- the server's data will be sensitive and the clients must prove to be
- trustworthy.
-ssl require servercert = yes
- If this variable is set to "yes", the smbclient will request a certificate
- from the server. Same as "ssl require clientcert" for the server.
-ssl ciphers = ???
- This variable defines the ciphers that should be offered during SSL
- negotiation. You should not set this variable unless you know what you do.
-ssl version = ssl2or3
- This enumeration variable defines the versions of the SSL protocol that
- will be used. "ssl2or3" allows dynamic negotiation of SSL v2 or v3, "ssl2"
- results SSL v2, "ssl3" results in SSL v3 and "tls1" results in TLS v1. TLS
- (Transport Layer Security) is the (proposed?) new standard for SSL. The
- default value is "ssl2or3".
-ssl compatibility = no
- This variable defines whether SSLeay should be configured for bug
- compatibility with other SSL implementations. This is probably not
- desirable because currently no clients with SSL implementations other than
- SSLeay exist.
-ssl entropy file =
- Specifies a file from which processes will read "random bytes" on startup.
- In order to seed the internal pseudo random number generator, entropy
- must be provided. On system with a /dev/urandom device file, the processes
- will retrieve its entropy from the kernel. On systems without kernel
- entropy support, a file can be supplied that will be read on startup
- and that will be used to seed the PRNG.
-ssl entropy bytes = 256
- Number of bytes that will be read from entropy file. If -1 is given, the
- complete file will be read.
-ssl egd socket =
- Location of the communiation socket of an EGD or PRNGD daemon, from which
- entropy can be retrieved. This option can be used instead of or together
- with the "ssl entropy file" directive. 255bytes of entropy will be
- retrieved from the daemon.
-
-
-Running samba with OpenSSL
-==========================
-Samba is started as usual. The daemon will ask for the private key's pass
-phrase before it goes to background if the private key has been encrypted.
-If you start smbd from inetd, this won't work. Therefore you must not encrypt
-your private key if you run smbd from inetd.
-
-Windows clients will try to connect to the SSL enabled samba daemon and they
-will fail. This can fill your log with failed SSL negotiation messages. To
-avoid this, you can either not run nmbd (if all clients use DNS to look up
-the server), which will leave the Windows machine unaware of the server, or
-list all (local) Windows machines in the "ssl hosts resign" variable.
-
-
-About certificates
-==================
-Secure samba servers will not be set up for public use as it is the case with
-secure web servers. Most installations will probably use it for distributed
-offices that use parts of the internet for their intranet, for access to a
-web server that's physically hosted by the provider or simply for teleworking.
-All these applications work with a known group of users that can easily agree
-on a certification authority. The CA can be operated by the company and the
-policy for issuing certificates can be determined by the company. If samba is
-configured to verify client certificates, it (currently) only verifies
-whether a valid certificate exists. It does not verify any of the data within
-the certificate (although it prints some of the data to the log file).
-
-
-Which clients are available that support SSL?
-=============================================
-Currently there are only smbclient which is part of the samba package and
-Sharity. Shariy versions newer than 0.14 in the beta branch and 1.01 in the
-main branch can be compiled with SSLeay. Sharity is a CIFS/SMB client
-implementation for Unix. It is a commercial product, but it is available in
-source code and the demo-mode allows access to the first three layers of the
-mounted directory hierarchy. Licenses for universities and students are free.
-Sharity is available at
-
- http://www.obdev.at/Products/Sharity.html
-
-
-
-###########################################################################
-Basics about Cryptography and SSL(eay)
-###########################################################################
-
-There are many good introductions to cryptography. I assume that the reader
-is familiar with the words "encryption", "digital signature" and RSA. If you
-don't know these terms, please read the cryptography FAQ part 6 and 7, which
-is posted to the usenet newsgroup sci.crypt. It is also available from
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/cryptography-faq
-and
- http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq
-
-I'll concentrate on the questions specific to SSL and samba here.
-
-
-What is a certificate?
-======================
-A certificate is issued by an issuer, usually a "Certification Authority"
-(CA), who confirms something by issuing the certificate. The subject of this
-confirmation depends on the CA's policy. CAs for secure web servers (used for
-shopping malls etc.) usually only attest that the given public key belongs the
-the given domain name. Company-wide CAs might attest that you are an employee
-of the company, that you have permissions to use a server or whatever.
-
-
-What is an X.509 certificate technically?
-=========================================
-Technically, the certificate is a block of data signed by the certificate
-issuer (the CA). The relevant fields are:
- - unique identifier (name) of the certificate issuer
- - time range during that the certificate is valid
- - unique identifier (name) of the certified subject
- - public key of the certified subject
- - the issuer's signature over all of the above
-If this certificate should be verified, the verifier must have a table of the
-names and public keys of trusted CAs. For simplicity, these tables are lists
-of certificates issued by the respective CAs for themselves (self-signed
-certificates).
-
-
-What are the implications of this certificate structure?
-========================================================
- - Because the certificate contains the subject's public key, the
- certificate and the private key together are all that's needed to encrypt
- and decrypt.
- - To verify certificates, you need the certificates of all CAs you trust.
- - The simplest form of a dummy-certificate is one that's signed by the
- subject itself.
- - A CA is needed. The client can't simply issue local certificates for
- servers it trusts because the server determines which certificate it
- presents.
-
-
-
-###########################################################################
-Setting up files and directories for OpenSSL
-###########################################################################
-
-The first thing you should do is to change your PATH environment variable to
-include the bin directory of OpenSSL. E.g.:
-
- PATH=$PATH:/usr/local/ssl/bin
-
-If your system's kernel supports a /dev/urandom device, all OpenSSL operations
-will automatically retrieve its entropy from it. If your system does not
-support /dev/urandom, you may install an EGD/PRNGD daemon for entropy
-supply or can generate seed from reading files (that should contain information
-unpredictable/unknown to attackers). Use the "-rand" option to the openssl
-commands to specify the entropy source (if /dev/urandom is not available).
-
-OpenSSL additionally keeps random seed in the $HOME/.rnd file. You can
-initialize this file using:
-
- openssl rand -rand /tmp/rfile.txt > $HOME/.rnd
- rm -f /tmp/rfile.txt # nobody must know!!
-
-or
-
- openssl rand -rand /path/to/egd-socket > $HOME/.rnd
-
-How to create a keypair
-=======================
-This is done with 'genrsa' for RSA keys and 'gendsa' for DSA keys. For an RSA
-key with 1024 bits which is written to the file "key.pem" type:
-
- openssl genrsa -des3 -rand /path/to/source 1024 > key.pem
-
-You will be asked for a pass phrase to protect this key. If you don't want to
-protect your private key with a pass phrase, just omit the parameter "-des3".
-If you want a different key size, replace the parameter "1024". You really
-should use a pass phrase.
-
-If you want to remove the pass phrase from a key use:
-
- openssl rsa -in key.pem -out newkey.pem
-
-And to add or change a pass phrase:
-
- openssl rsa -des3 -in key.pem -out newkey.pem
-
-
-How to create a dummy certificate
-=================================
-If you still have your keypair in the file "key.pem", the command
-
- openssl req -new -x509 -key key.pem -out cert.pem
-
-will write a self-signed dummy certificate to the file "cert.pem". This can
-be used for testing or if only encryption and no certification is needed.
-Please bear in mind that encryption without authentication (certification)
-can never be secure. It's open to (at least) "man-in-the-middle" attacks.
-
-
-How to create a certificate signing request
-===========================================
-You must not simply send your keypair to the CA for signing because it
-contains the private key which _must_ be kept secret. A signing request
-consists of your public key and some additional information you want to have
-bound to that key by the certificate. If you operate a secure web server,
-this additional information will (among other things) contain the URL of
-your server in the field "Common Name". The certificate signing request is
-created from the keypair with the following command (assuming that the key
-pair is still in "key.pem"):
-
- openssl req -new -key key.pem -out csr.pem
-
-This command will ask you for the information which must be included in the
-certificate and will write the signing request to the file "csr.pem". This
-signing request is all the CA needs for signing, at least technically. Most
-CAs will demand bureaucratic material and money, too.
-
-
-How to set up a Certification Authority (CA)
-============================================
-Being a certification authority requires a database that holds the CA's
-keypair, the CA's certificate, a list of all signed certificates and other
-information. This database is kept in a directory hierarchy below a
-configurable starting point. The starting point must be configured in the
-ssleay.conf file. This file is at /usr/local/ssl/lib/ssleay.conf if you have
-not changed the default installation path.
-
-The first thing you should do is to edit this file according to your needs.
-Let's assume that you want to hold the CA's database at the directory
-"/usr/local/ssl/CA". Change the variable "dir" in section "CA_default" to
-this path. You may also want to edit the default settings for some variables,
-but the values given should be OK. This path is also contained in the shell
-script CA.sh, which should be at "/usr/local/ssl/bin/CA.sh". Change the path
-in the shell script:
-
- CATOP=/usr/local/ssl/CA
- CAKEY=./cakey.pem # relative to $CATOP/
- CACERT=./cacert.pem # relative to $CATOP/private/
-
-Then create the directory "/usr/local/ssl/CA" and make it writable for the
-user that operates the CA. You should also initialize SSLeay as CA user (set
-up the random number generator). Now you should call the shell script CA.sh
-to set up the initial database:
-
- CA.sh -newca
-
-This command will ask you whether you want to use an existing certificate or
-create one. Just press enter to create a new key pair and certificate. You
-will be asked the usual questions for certificates: the country, state, city,
-"Common Name", etc. Enter the appropriate values for the CA. When CA.sh
-finishes, it has set up a bunch of directories and files. A CA must publish
-it's certificate, which is in the file "/usr/local/ssl/CA/cacert.pem".
-
-
-How to sign a certificate request
-=================================
-After setting up the CA stuff, you can start signing certificate requests.
-Make sure that the SSLeay utilities know where the configuration file is.
-The default is compiled in, if you don't use the default location, add the
-parameter "-config <cfg-file>". Make also sure that the configuration file
-contains the correct path to the CA database. If all this is set up properly,
-you can sign the request in the file "csr.pem" with the command:
-
- openssl ca -policy policy_anything -days 365 -infiles csr.pem >cert.pem
-
-The resulting certificate (and additional information) will be in "cert.pem".
-If you want the certificate to be valid for a period different from 365 days,
-simply change the "-days" parameter.
-
-
-How to install a new CA certificate
-===================================
-Whereever a certificate must be checked, the CA's certificate must be
-available. Let's take the common case where the client verifies the server's
-certificate. The case where the server verfies the client's certificate works
-the same way. The client receives the server's certificate, which contains
-the "Distinguished Name" of the CA. To verify whether the signature in this
-certificate is OK, it must look up the public key of that CA. Therefore each
-client must hold a database of CAs, indexed by CA name. This database is best
-kept in a directory where each file contains the certificate of one CA and is
-named after the hashvalue (checksum) of the CA's name. This section describes
-how such a database is managed technically. Whether or not to install (and
-thereby trust) a CA is a totally different matter.
-
-The client must know the directory of the CA database. This can be configured.
-There may also be a configuration option to set up a CA database file which
-contains all CA certs in one file. Let's assume that the CA database is kept
-in the directory "/usr/local/ssl/certs". The following example assumes that
-the CA's certificate is in the file "cacert.pem" and the CA is known as
-"myCA". To install the certificate, do the following:
-
- cp cacert.pem /usr/local/ssl/cers/myCA.pem
- cd /usr/local/ssl/certs
- ln -s myCA.pem `openssl x509 -noout -hash < myCA.pem`.0
-
-The last command creates a link from the hashed name to the real file.
-
-From now on all certificates signed by the myCA authority will be accepted by
-clients that use the directory "/usr/local/ssl/certs/" as their CA certificate
-database.
-
-
-
diff --git a/docs/textdocs/Speed.txt b/docs/textdocs/Speed.txt
deleted file mode 100644
index b82db8f8f4..0000000000
--- a/docs/textdocs/Speed.txt
+++ /dev/null
@@ -1,338 +0,0 @@
-
-Subject: Samba performance issues
-============================================================================
-
-This file tries to outline the ways to improve the speed of a Samba server.
-
-COMPARISONS
------------
-
-The Samba server uses TCP to talk to the client. Thus if you are
-trying to see if it performs well you should really compare it to
-programs that use the same protocol. The most readily available
-programs for file transfer that use TCP are ftp or another TCP based
-SMB server.
-
-If you want to test against something like a NT or WfWg server then
-you will have to disable all but TCP on either the client or
-server. Otherwise you may well be using a totally different protocol
-(such as Netbeui) and comparisons may not be valid.
-
-Generally you should find that Samba performs similarly to ftp at raw
-transfer speed. It should perform quite a bit faster than NFS,
-although this very much depends on your system.
-
-Several people have done comparisons between Samba and Novell, NFS or
-WinNT. In some cases Samba performed the best, in others the worst. I
-suspect the biggest factor is not Samba vs some other system but the
-hardware and drivers used on the various systems. Given similar
-hardware Samba should certainly be competitive in speed with other
-systems.
-
-
-OPLOCKS
--------
-
-Oplocks are the way that SMB clients get permission from a server to
-locally cache file operations. If a server grants an oplock
-(opportunistic lock) then the client is free to assume that it is the
-only one accessing the file and it will agressively cache file
-data. With some oplock types the client may even cache file open/close
-operations. This can give enormous performance benefits.
-
-With the release of Samba 1.9.18 we now correctly support opportunistic
-locks. This is turned on by default, and can be turned off on a share-
-by-share basis by setting the parameter :
-
-oplocks = False
-
-We recommend that you leave oplocks on however, as current benchmark
-tests with NetBench seem to give approximately a 30% improvement in
-speed with them on. This is on average however, and the actual
-improvement seen can be orders of magnitude greater, depending on
-what the client redirector is doing.
-
-Previous to Samba 1.9.18 there was a 'fake oplocks' option. This
-option has been left in the code for backwards compatibility reasons
-but it's use is now deprecated. A short summary of what the old
-code did follows.
-
-LEVEL2 OPLOCKS
---------------
-
-With Samba 2.0.5 a new capability - level2 (read only) oplocks is
-supported (although the option is off by default - see the smb.conf
-man page for details). Turning on level2 oplocks (on a share-by-share basis)
-by setting the parameter :
-
-level2 oplocks = true
-
-should speed concurrent access to files that are not commonly written
-to, such as application serving shares (ie. shares that contain common
-.EXE files - such as a Microsoft Office share) as it allows clients to
-read-ahread cache copies of these files.
-
-Old 'fake oplocks' option - deprecated.
----------------------------------------
-
-Samba can also fake oplocks, by granting a oplock whenever a client
-asks for one. This is controlled using the smb.conf option "fake
-oplocks". If you set "fake oplocks = yes" then you are telling the
-client that it may agressively cache the file data for all opens.
-
-Enabling 'fake oplocks' on all read-only shares or shares that you know
-will only be accessed from one client at a time you will see a big
-performance improvement on many operations. If you enable this option
-on shares where multiple clients may be accessing the files read-write
-at the same time you can get data corruption.
-
-SOCKET OPTIONS
---------------
-
-There are a number of socket options that can greatly affect the
-performance of a TCP based server like Samba.
-
-The socket options that Samba uses are settable both on the command
-line with the -O option, or in the smb.conf file.
-
-The "socket options" section of the smb.conf manual page describes how
-to set these and gives recommendations.
-
-Getting the socket options right can make a big difference to your
-performance, but getting them wrong can degrade it by just as
-much. The correct settings are very dependent on your local network.
-
-The socket option TCP_NODELAY is the one that seems to make the
-biggest single difference for most networks. Many people report that
-adding "socket options = TCP_NODELAY" doubles the read performance of
-a Samba drive. The best explanation I have seen for this is that the
-Microsoft TCP/IP stack is slow in sending tcp ACKs.
-
-
-READ SIZE
----------
-
-The option "read size" affects the overlap of disk reads/writes with
-network reads/writes. If the amount of data being transferred in
-several of the SMB commands (currently SMBwrite, SMBwriteX and
-SMBreadbraw) is larger than this value then the server begins writing
-the data before it has received the whole packet from the network, or
-in the case of SMBreadbraw, it begins writing to the network before
-all the data has been read from disk.
-
-This overlapping works best when the speeds of disk and network access
-are similar, having very little effect when the speed of one is much
-greater than the other.
-
-The default value is 16384, but very little experimentation has been
-done yet to determine the optimal value, and it is likely that the best
-value will vary greatly between systems anyway. A value over 65536 is
-pointless and will cause you to allocate memory unnecessarily.
-
-
-MAX XMIT
---------
-
-At startup the client and server negotiate a "maximum transmit" size,
-which limits the size of nearly all SMB commands. You can set the
-maximum size that Samba will negotiate using the "max xmit = " option
-in smb.conf. Note that this is the maximum size of SMB request that
-Samba will accept, but not the maximum size that the *client* will accept.
-The client maximum receive size is sent to Samba by the client and Samba
-honours this limit.
-
-It defaults to 65536 bytes (the maximum), but it is possible that some
-clients may perform better with a smaller transmit unit. Trying values
-of less than 2048 is likely to cause severe problems.
-
-In most cases the default is the best option.
-
-
-LOCKING
--------
-
-By default Samba does not implement strict locking on each read/write
-call (although it did in previous versions). If you enable strict
-locking (using "strict locking = yes") then you may find that you
-suffer a severe performance hit on some systems.
-
-The performance hit will probably be greater on NFS mounted
-filesystems, but could be quite high even on local disks.
-
-
-SHARE MODES
------------
-
-Some people find that opening files is very slow. This is often
-because of the "share modes" code needed to fully implement the dos
-share modes stuff. You can disable this code using "share modes =
-no". This will gain you a lot in opening and closing files but will
-mean that (in some cases) the system won't force a second user of a
-file to open the file read-only if the first has it open
-read-write. For many applications that do their own locking this
-doesn't matter, but for some it may. Most Windows applications
-depend heavily on "share modes" working correctly and it is
-recommended that the Samba share mode support be left at the
-default of "on".
-
-The share mode code in Samba has been re-written in the 1.9.17
-release following tests with the Ziff-Davis NetBench PC Benchmarking
-tool. It is now believed that Samba 1.9.17 implements share modes
-similarly to Windows NT.
-
-NOTE: In the most recent versions of Samba there is an option to use
-shared memory via mmap() to implement the share modes. This makes
-things much faster. See the Makefile for how to enable this.
-
-
-LOG LEVEL
----------
-
-If you set the log level (also known as "debug level") higher than 2
-then you may suffer a large drop in performance. This is because the
-server flushes the log file after each operation, which can be very
-expensive.
-
-
-WIDE LINKS
-----------
-
-The "wide links" option is now enabled by default, but if you disable
-it (for better security) then you may suffer a performance hit in
-resolving filenames. The performance loss is lessened if you have
-"getwd cache = yes", which is now the default.
-
-
-READ RAW
---------
-
-The "read raw" operation is designed to be an optimised, low-latency
-file read operation. A server may choose to not support it,
-however. and Samba makes support for "read raw" optional, with it
-being enabled by default.
-
-In some cases clients don't handle "read raw" very well and actually
-get lower performance using it than they get using the conventional
-read operations.
-
-So you might like to try "read raw = no" and see what happens on your
-network. It might lower, raise or not affect your performance. Only
-testing can really tell.
-
-
-WRITE RAW
----------
-
-The "write raw" operation is designed to be an optimised, low-latency
-file write operation. A server may choose to not support it,
-however. and Samba makes support for "write raw" optional, with it
-being enabled by default.
-
-Some machines may find "write raw" slower than normal write, in which
-case you may wish to change this option.
-
-READ PREDICTION
----------------
-
-Samba can do read prediction on some of the SMB commands. Read
-prediction means that Samba reads some extra data on the last file it
-read while waiting for the next SMB command to arrive. It can then
-respond more quickly when the next read request arrives.
-
-This is disabled by default. You can enable it by using "read
-prediction = yes".
-
-Note that read prediction is only used on files that were opened read
-only.
-
-Read prediction should particularly help for those silly clients (such
-as "Write" under NT) which do lots of very small reads on a file.
-
-Samba will not read ahead more data than the amount specified in the
-"read size" option. It always reads ahead on 1k block boundaries.
-
-
-MEMORY MAPPING
---------------
-
-Samba supports reading files via memory mapping them. One some
-machines this can give a large boost to performance, on others it
-makes not difference at all, and on some it may reduce performance.
-
-To enable you you have to recompile Samba with the -DUSE_MMAP option
-on the FLAGS line of the Makefile.
-
-Note that memory mapping is only used on files opened read only, and
-is not used by the "read raw" operation. Thus you may find memory
-mapping is more effective if you disable "read raw" using "read raw =
-no".
-
-
-SLOW CLIENTS
-------------
-
-One person has reported that setting the protocol to COREPLUS rather
-than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).
-
-I suspect that his PC's (386sx16 based) were asking for more data than
-they could chew. I suspect a similar speed could be had by setting
-"read raw = no" and "max xmit = 2048", instead of changing the
-protocol. Lowering the "read size" might also help.
-
-
-SLOW LOGINS
------------
-
-Slow logins are almost always due to the password checking time. Using
-the lowest practical "password level" will improve things a lot. You
-could also enable the "UFC crypt" option in the Makefile.
-
-CLIENT TUNING
--------------
-
-Often a speed problem can be traced to the client. The client (for
-example Windows for Workgroups) can often be tuned for better TCP
-performance.
-
-See your client docs for details. In particular, I have heard rumours
-that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a
-large impact on performance.
-
-Also note that some people have found that setting DefaultRcvWindow in
-the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a
-big improvement. I don't know why.
-
-My own experience wth DefaultRcvWindow is that I get much better
-performance with a large value (16384 or larger). Other people have
-reported that anything over 3072 slows things down enourmously. One
-person even reported a speed drop of a factor of 30 when he went from
-3072 to 8192. I don't know why.
-
-It probably depends a lot on your hardware, and the type of unix box
-you have at the other end of the link.
-
-
-MY RESULTS
-----------
-
-Some people want to see real numbers in a document like this, so here
-they are. I have a 486sx33 client running WfWg 3.11 with the 3.11b
-tcp/ip stack. It has a slow IDE drive and 20Mb of ram. It has a SMC
-Elite-16 ISA bus ethernet card. The only WfWg tuning I've done is to
-set DefaultRcvWindow in the [MSTCP] section of system.ini to 16384. My
-server is a 486dx3-66 running Linux. It also has 20Mb of ram and a SMC
-Elite-16 card. You can see my server config in the examples/tridge/
-subdirectory of the distribution.
-
-I get 490k/s on reading a 8Mb file with copy.
-I get 441k/s writing the same file to the samba server.
-
-Of course, there's a lot more to benchmarks than 2 raw throughput
-figures, but it gives you a ballpark figure.
-
-I've also tested Win95 and WinNT, and found WinNT gave me the best
-speed as a samba client. The fastest client of all (for me) is
-smbclient running on another linux box. Maybe I'll add those results
-here someday ...
-
-
diff --git a/docs/textdocs/Speed2.txt b/docs/textdocs/Speed2.txt
deleted file mode 100644
index a8c3e7381f..0000000000
--- a/docs/textdocs/Speed2.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Contributor: Paul Cochrane <paulc@dth.scot.nhs.uk>
-Organization: Dundee Limb Fitting Centre
-Date: Fri, 10 Apr 1998
-Subject: Samba SPEED.TXT comment
-=============================================================================
-
-This might be relevant to Client Tuning. I have been trying various methods
-of getting win95 to talk to Samba quicker. The results I have come up with
-are:
-
-1. Install the W2setup.exe file from www.microsoft.com. This is an
-update for the winsock stack and utilities which improve performance.
-
-2. Configure the win95 TCPIP registry settings to give better
-perfomance. I use a program called MTUSPEED.exe which I got off the
-net. There are various other utilities of this type freely available.
-The setting which give the best performance for me are:
-
-(a) MaxMTU Remove
-(b) RWIN Remove
-(c) MTUAutoDiscover Disable
-(d) MTUBlackHoleDetect Disable
-(e) Time To Live Enabled
-(f) Time To Live - HOPS 32
-(g) NDI Cache Size 0
-
-3. I tried virtually all of the items mentioned in the document and
-the only one which made a difference to me was the socket options. It
-turned out I was better off without any!!!!!
-
-In terms of overall speed of transfer, between various win95 clients
-and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE
-drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.
-
-The figures are: Put Get
-P166 client 3Com card: 420-440kB/s 500-520kB/s
-P100 client 3Com card: 390-410kB/s 490-510kB/s
-DX4-75 client NE2000: 370-380kB/s 330-350kB/s
-
-I based these test on transfer two files a 4.5MB text file and a 15MB
-textfile. The results arn't bad considering the hardware Samba is
-running on. It's a crap machine!!!!
-
-The updates mentioned in 1 and 2 brought up the transfer rates from
-just over 100kB/s in some clients.
-
-A new client is a P333 connected via a 100MB/s card and hub. The
-transfer rates from this were good: 450-500kB/s on put and 600+kB/s
-on get.
-
-Looking at standard FTP throughput, Samba is a bit slower (100kB/s
-upwards). I suppose there is more going on in the samba protocol, but
-if it could get up to the rate of FTP the perfomance would be quite
-staggering.
-
-Paul Cochrane
-
diff --git a/docs/textdocs/Tracing.txt b/docs/textdocs/Tracing.txt
deleted file mode 100644
index 6cc1d69258..0000000000
--- a/docs/textdocs/Tracing.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-Contributor: Andrew Tridgell <samba@samba.org>
-Date: Old
-Status: Questionable
-
-Subject: How to trace samba system calls for debugging purposes
-=============================================================================
-
-This file describes how to do a system call trace on Samba to work out
-what its doing wrong. This is not for the faint of heart, but if you
-are reading this then you are probably desperate.
-
-Actually its not as bad as the the above makes it sound, just don't
-expect the output to be very pretty :-)
-
-Ok, down to business. One of the big advantages of unix systems is
-that they nearly all come with a system trace utility that allows you
-to monitor all system calls that a program is making. This is
-extremely using for debugging and also helps when trying to work out
-why something is slower than you expect. You can use system tracing
-without any special compilation options.
-
-The system trace utility is called different things on different
-systems. On Linux systems its called strace. Under SunOS 4 its called
-trace. Under SVR4 style systems (including solaris) its called
-truss. Under many BSD systems its called ktrace.
-
-The first thing you should do is read the man page for your native
-system call tracer. In the discussion below I'll assume its called
-strace as strace is the only portable system tracer (its available for
-free for many unix types) and its also got some of the nicest
-features.
-
-Next, try using strace on some simple commands. For example, "strace
-ls" or "strace echo hello".
-
-You'll notice that it produces a LOT of output. It is showing you the
-arguments to every system call that the program makes and the
-result. Very little happens in a program without a system call so you
-get lots of output. You'll also find that it produces a lot of
-"preamble" stuff showing the loading of shared libraries etc. Ignore
-this (unless its going wrong!)
-
-For example, the only line that really matters in the "strace echo
-hello" output is:
-
-write(1, "hello\n", 6) = 6
-
-all the rest is just setting up to run the program.
-
-Ok, now you're famialiar with strace. To use it on Samba you need to
-strace the running smbd daemon. The way I tend ot use it is to first
-login from my Windows PC to the Samba server, then use smbstatus to
-find which process ID that client is attached to, then as root I do
-"strace -p PID" to attach to that process. I normally redirect the
-stderr output from this command to a file for later perusal. For
-example, if I'm using a csh style shell:
-
- strace -f -p 3872 >& strace.out
-
-or with a sh style shell:
-
- strace -f -p 3872 > strace.out 2>&1
-
-Note the "-f" option. This is only available on some systems, and
-allows you to trace not just the current process, but any children it
-forks. This is great for finding printing problems caused by the
-"print command" being wrong.
-
-Once you are attached you then can do whatever it is on the client
-that is causing problems and you will capture all the system calls
-that smbd makes.
-
-So how do you interpret the results? Generally I search through the
-output for strings that I know will appear when the problem
-happens. For example, if I am having touble with permissions on a file
-I would search for that files name in the strace output and look at
-the surrounding lines. Another trick is to match up file descriptor
-numbers and "follow" what happens to an open file until it is closed.
-
-Beyond this you will have to use your initiative. To give you an idea
-of wehat you are looking for here is a piece of strace output that
-shows that /dev/null is not world writeable, which causes printing to
-fail with Samba:
-
-[pid 28268] open("/dev/null", O_RDWR) = -1 EACCES (Permission denied)
-[pid 28268] open("/dev/null", O_WRONLY) = -1 EACCES (Permission denied)
-
-the process is trying to first open /dev/null read-write then
-read-only. Both fail. This means /dev/null has incorrect permissions.
-
-Have fun!
-
-(please send updates/fixes to this file to samba@samba.org)
diff --git a/docs/textdocs/UNIX-SMB.txt b/docs/textdocs/UNIX-SMB.txt
deleted file mode 100644
index c3d7643cbc..0000000000
--- a/docs/textdocs/UNIX-SMB.txt
+++ /dev/null
@@ -1,231 +0,0 @@
-Contributor: Andrew Tridgell <samba@samba.org>
-Date: April 1995
-
-Subject: Discussion of NetBIOS in a Unix World
-============================================================================
-
-This is a short document that describes some of the issues that
-confront a SMB implementation on unix, and how Samba copes with
-them. They may help people who are looking at unix<->PC
-interoperability.
-
-It was written to help out a person who was writing a paper on unix to
-PC connectivity.
-
-
-Usernames
-=========
-
-The SMB protocol has only a loose username concept. Early SMB
-protocols (such as CORE and COREPLUS) have no username concept at
-all. Even in later protocols clients often attempt operations
-(particularly printer operations) without first validating a username
-on the server.
-
-Unix security is based around username/password pairs. A unix box
-should not allow clients to do any substantive operation without some
-sort of validation.
-
-The problem mostly manifests itself when the unix server is in "share
-level" security mode. This is the default mode as the alternative
-"user level" security mode usually forces a client to connect to the
-server as the same user for each connected share, which is
-inconvenient in many sites.
-
-In "share level" security the client normally gives a username in the
-"session setup" protocol, but does not supply an accompanying
-password. The client then connects to resources using the "tree
-connect" protocol, and supplies a password. The problem is that the
-user on the PC types the username and the password in different
-contexts, unaware that they need to go together to give access to the
-server. The username is normally the one the user typed in when they
-"logged onto" the PC (this assumes Windows for Workgroups). The
-password is the one they chose when connecting to the disk or printer.
-
-The user often chooses a totally different username for their login as
-for the drive connection. Often they also want to access different
-drives as different usernames. The unix server needs some way of
-divining the correct username to combine with each password.
-
-Samba tries to avoid this problem using several methods. These succeed
-in the vast majority of cases. The methods include username maps, the
-service%user syntax, the saving of session setup usernames for later
-validation and the derivation of the username from the service name
-(either directly or via the user= option).
-
-File Ownership
-==============
-
-The commonly used SMB protocols have no way of saying "you can't do
-that because you don't own the file". They have, in fact, no concept
-of file ownership at all.
-
-This brings up all sorts of interesting problems. For example, when
-you copy a file to a unix drive, and the file is world writeable but
-owned by another user the file will transfer correctly but will
-receive the wrong date. This is because the utime() call under unix
-only succeeds for the owner of the file, or root, even if the file is
-world writeable. For security reasons Samba does all file operations
-as the validated user, not root, so the utime() fails. This can stuff
-up shared development diectories as programs like "make" will not get
-file time comparisons right.
-
-There are several possible solutions to this problem, including
-username mapping, and forcing a specific username for particular
-shares.
-
-Passwords
-=========
-
-Many SMB clients uppercase passwords before sending them. I have no
-idea why they do this. Interestingly WfWg uppercases the password only
-if the server is running a protocol greater than COREPLUS, so
-obviously it isn't just the data entry routines that are to blame.
-
-Unix passwords are case sensitive. So if users use mixed case
-passwords they are in trouble.
-
-Samba can try to cope with this by either using the "password level"
-option which causes Samba to try the offered password with up to the
-specified number of case changes, or by using the "password server"
-option which allows Samba to do its validation via another machine
-(typically a WinNT server).
-
-Samba supports the password encryption method used by SMB
-clients. Note that the use of password encryption in Microsoft
-networking leads to password hashes that are "plain text equivalent".
-This means that it is *VERY* important to ensure that the Samba
-smbpasswd file containing these password hashes is only readable
-by the root user. See the documentation ENCRYPTION.txt for more
-details.
-
-
-Locking
-=======
-
-The locking calls available under a DOS/Windows environment are much
-richer than those available in unix. This means a unix server (like
-Samba) choosing to use the standard fcntl() based unix locking calls
-to implement SMB locking has to improvise a bit.
-
-One major problem is that dos locks can be in a 32 bit (unsigned)
-range. Unix locking calls are 32 bits, but are signed, giving only a 31
-bit range. Unfortunately OLE2 clients use the top bit to select a
-locking range used for OLE semaphores.
-
-To work around this problem Samba compresses the 32 bit range into 31
-bits by appropriate bit shifting. This seems to work but is not
-ideal. In a future version a separate SMB lockd may be added to cope
-with the problem.
-
-It also doesn't help that many unix lockd daemons are very buggy and
-crash at the slightest provocation. They normally go mostly unused in
-a unix environment because few unix programs use byte range
-locking. The stress of huge numbers of lock requests from dos/windows
-clients can kill the daemon on some systems.
-
-The second major problem is the "opportunistic locking" requested by
-some clients. If a client requests opportunistic locking then it is
-asking the server to notify it if anyone else tries to do something on
-the same file, at which time the client will say if it is willing to
-give up its lock. Unix has no simple way of implementing
-opportunistic locking, and currently Samba has no support for it.
-
-Deny Modes
-==========
-
-When a SMB client opens a file it asks for a particular "deny mode" to
-be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE,
-DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be
-allowed by anyone else who tries to use the file at the same time. If
-DENY_READ is placed on the file, for example, then any attempt to open
-the file for reading should fail.
-
-Unix has no equivalent notion. To implement this Samba uses either lock
-files based on the files inode and placed in a separate lock
-directory or a shared memory implementation. The lock file method
-is clumsy and consumes processing and file resources,
-the shared memory implementation is vastly prefered and is turned on
-by default for those systems that support it.
-
-Trapdoor UIDs
-=============
-
-A SMB session can run with several uids on the one socket. This
-happens when a user connects to two shares with different
-usernames. To cope with this the unix server needs to switch uids
-within the one process. On some unixes (such as SCO) this is not
-possible. This means that on those unixes the client is restricted to
-a single uid.
-
-Note that you can also get the "trapdoor uid" message for other
-reasons. Please see the FAQ for details.
-
-Port numbers
-============
-
-There is a convention that clients on sockets use high "unprivilaged"
-port numbers (>1000) and connect to servers on low "privilaged" port
-numbers. This is enforced in Unix as non-root users can't open a
-socket for listening on port numbers less than 1000.
-
-Most PC based SMB clients (such as WfWg and WinNT) don't follow this
-convention completely. The main culprit is the netbios nameserving on
-udp port 137. Name query requests come from a source port of 137. This
-is a problem when you combine it with the common firewalling technique
-of not allowing incoming packets on low port numbers. This means that
-these clients can't query a netbios nameserver on the other side of a
-low port based firewall.
-
-The problem is more severe with netbios node status queries. I've
-found that WfWg, Win95 and WinNT3.5 all respond to netbios node status
-queries on port 137 no matter what the source port was in the
-request. This works between machines that are both using port 137, but
-it means it's not possible for a unix user to do a node status request
-to any of these OSes unless they are running as root. The answer comes
-back, but it goes to port 137 which the unix user can't listen
-on. Interestingly WinNT3.1 got this right - it sends node status
-responses back to the source port in the request.
-
-
-Protocol Complexity
-===================
-
-There are many "protocol levels" in the SMB protocol. It seems that
-each time new functionality was added to a Microsoft operating system,
-they added the equivalent functions in a new protocol level of the SMB
-protocol to "externalise" the new capabilities.
-
-This means the protocol is very "rich", offering many ways of doing
-each file operation. This means SMB servers need to be complex and
-large. It also means it is very difficult to make them bug free. It is
-not just Samba that suffers from this problem, other servers such as
-WinNT don't support every variation of every call and it has almost
-certainly been a headache for MS developers to support the myriad of
-SMB calls that are available.
-
-There are about 65 "top level" operations in the SMB protocol (things
-like SMBread and SMBwrite). Some of these include hundreds of
-sub-functions (SMBtrans has at least 120 sub-functions, like
-DosPrintQAdd and NetSessionEnum). All of them take several options
-that can change the way they work. Many take dozens of possible
-"information levels" that change the structures that need to be
-returned. Samba supports all but 2 of the "top level" functions. It
-supports only 8 (so far) of the SMBtrans sub-functions. Even NT
-doesn't support them all.
-
-Samba currently supports up to the "NT LM 0.12" protocol, which is the
-one preferred by Win95 and WinNT3.5. Luckily this protocol level has a
-"capabilities" field which specifies which super-duper new-fangled
-options the server suports. This helps to make the implementation of
-this protocol level much easier.
-
-There is also a problem with the SMB specications. SMB is a X/Open
-spec, but the X/Open book is far from ideal, and fails to cover many
-important issues, leaving much to the imagination. Microsoft recently
-renamed the SMB protocol CIFS (Common Internet File System) and have
-published new specifications. These are far superior to the old
-X/Open documents but there are still undocumented calls and features.
-This specification is actively being worked on by a CIFS developers
-mailing list hosted by Microsft.
-
diff --git a/docs/textdocs/Win95.txt b/docs/textdocs/Win95.txt
deleted file mode 100644
index 69330c512d..0000000000
--- a/docs/textdocs/Win95.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Copyright (C) 1997 - Samba-Team
-Contributed Date: August 20, 1997
-Last Update: August 20, 1997
-
-Subject: Windows 95 and Samba Interoperability
-===============================================================================
-
-Password Handling:
-------------------
-Microsoft periodically release updates to all their operating systems. Some of
-these are welcomed while others cause us to change the way we do things. Few
-people like change, particularly if the change is unexpected. The best advice
-always is to read the documentation provided BEFORE applying an update.
-
-One of the recent Win95 updates (VRDRUPD.EXE) disables plain text (also called
-clear text) password authentication. The effects of this updates are desirable
-where MS Windows NT is providing the password authentication service. This
-update is most undesirable where Samba must provide the authentication service
-unless Samba has been specifically configured to use encrypted passwords _AND_
-has been linked with the libdes library.
-
-If the above conditions have not been complied with, and you are using Samba,
-then Windows 95 clients will NOT be able to authenticate to a Samba server.
-
-To re-enable plain text password capabilities AFTER applying this update
-you must create a new value in the Windows 95 registry.
-
-Either foillow the following procedure or just double click on the
-file Win95_PlainPassword.reg for an easier way to do this.
-
-Procedure:
-1) Launch the Registry Editor as follows:
- Click on: /Start/Run
- Type "regedit" and press enter.
-
-2) Double click on: HKEY_LOCAL_MACHINE
-
-3) Locate the following Key:
- /HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/VxD/VNETSUP
-
-4) From the menu bar select Edit/New/DWORD Value
-
-5) Rename the entry from "New Value #1" to:
- EnablePlainTextPassword
-
-6) Press Enter, then double click on the new entry.
- A dialog box will pop up and enable you to set a value.
- You must set this value to 1.
-
--------------------------------------------------------------------------------
-
-Windows 95 Updates:
--------------------
-When using Windows 95 OEM SR2 the following updates are recommended where Samba
-is being used. Please NOTE that the above change will affect you once these
-updates have been installed.
-
-There are more updates than the ones mentioned here. You are referred to the
-Microsoft Web site for all currently available updates to your specific version
-of Windows 95.
-
-Kernel Update: KRNLUPD.EXE
-Ping Fix: PINGUPD.EXE
-RPC Update: RPCRTUPD.EXE
-TCP/IP Update: VIPUPD.EXE
-Redirector Update: VRDRUPD.EXE
-
-Also, if using MS OutLook it is desirable to install the OLEUPD.EXE fix. This
-fix may stop your machine from hanging for an extended period when exiting
-OutLook and you may also notice a significant speedup when accessing network
-neighborhood services.
-
--------------------------------------------------------------------------------
-The above password information was provided by: Jochen Huppertz <jhu@nrh.de>
diff --git a/docs/textdocs/WinNT.txt b/docs/textdocs/WinNT.txt
deleted file mode 100644
index 5c72fb08aa..0000000000
--- a/docs/textdocs/WinNT.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-Contributors: Various
- Password Section - Copyright (C) 1997 - John H Terpstra
- Printing Section - Copyright (C) 1997 - Matthew Harrell
- Priting Info - Copyright (C) 1997 - Frank Varnavas
-Updated: October 16, 1997
-Status: Current
-
-Subject: Samba and Windows NT Password Handling
-=============================================================================
-
-There are some particular issues with Samba and Windows NT.
-
-Passwords:
-==========
-One of the most annoying problems with WinNT is that NT refuses to
-connect to a server that is in user level security mode and that
-doesn't support password encryption unless it first prompts the user
-for a password.
-
-This means even if you have the same password on the NT box and the
-Samba server you will get prompted for a password. Entering the
-correct password will get you connected only if Windows NT can
-communicate with Samba using a compatible mode of password security.
-
-All versions of Windows NT prior to 4.0 Service Pack 3 could negotiate
-plain text (clear text) passwords. Windows NT 4.0 Service Pack 3 changed
-this default behaviour so it now will only handle encrypted passwords.
-The following registry entry change will re-enable clear text password
-handling:
-
-Run regedt32.exe and locate the hive key entry:
-HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\Rdr\Parameters\
-
-Add the following value:
- EnablePlainTextPassword:REG_DWORD=1
-
-Alternatively, use the NT4_PlainPassword.reg file in this directory (either
-by double clicking on it, or run regedt32.exe and select "Import Registry
-File" from the "Registry" Menu).
-
-The other major ramification of this feature of NT is that it can't
-browse a user level non-encrypted server unless it already has a
-connection open. This is because there is no spot for a password
-prompt in the browser window. It works fine if you already have a
-drive mounted (for example, one auto mounted on startup).
-=====================================================================
-
-Printing:
-=========
-When you mount a printer using the print manager in NT you may find
-the following info from Matthew Harrell <harrell@leech.nrl.navy.mil>
-useful:
-
-------------
- I noticed in your change-log you noted that some people were
-still unable to use print manager under NT. If this is the same problem
-that I encountered, it's caused by the length of time it takes NT to
-determine if the printer is ready.
-
-The problem occurs when you double-click on a printer to connect it to
-the NT machine. Because it's unable to determine if the printer is ready
-in the short span of time it has, it assumes it isn't and gives some
-strange error about not having enough resources (I forget what the error
-is). A solution to this that seems to work fine for us is to click
-once on the printer, look at the bottom of the window and wait until
-it says it's ready, then clilck on "OK".
-
-By the way, this problem probably occurs in our group because the
-Samba server doesn't actually have the printers - it queues them to
-remote printers either on other machines or using their own network
-cards. Because of this "middle layer", it takes an extra amount of
-time for the NT machine to get verification that the printer queue
-actually exists.
-
-I hope this helped in some way...
-
-=====================================================================
-Printing Info:
---------------
-
-From: Frank Varnavas <varnavas@ny.ubs.com>
-Subject: RE: Samba as a print server
-
-When an NT client attempts to connect to a printer on a non-NT print
-server the attempt is failed with an error, something like:
-
- "You have insufficient access to your computer to perform the
- operation because a driver needs to be installed"
-
-This is because domain users must have 'Power User' status on the
-desktop to connect to printers on a non-NT print server.
-
-This error occurs regardless of whether the driver in question is
-already installed or not. What it really means is that the server is
-a non-NT server and the client does not have permission to create
-printers locally. Apparently when a connection to a non-NT print
-server is made the printer is defined locally. Such an action can be
-performed by either a local administrator or a Power User.
-Unfortunately there is no way to limit the powers of a Power User, nor
-is there any way to grant the Printer Creation right to another group.
-
-This permission policy is documented in PSS database WINNT, ID Q101874
-
-Frank Varnavas (varnavas@ny.ubs.com)
diff --git a/docs/textdocs/cifsntdomain.txt b/docs/textdocs/cifsntdomain.txt
deleted file mode 100644
index 643b8957c9..0000000000
--- a/docs/textdocs/cifsntdomain.txt
+++ /dev/null
@@ -1,1498 +0,0 @@
-NT Domain Authentication
-------------------------
-
-Authors: - Luke Kenneth Casson Leighton (lkcl@switchboard.net)
--------- - Paul Ashton (paul@argo.demon.co.uk)
- - Duncan Stansfield (duncans@sco.com)
-
- Copyright (C) 1997 Luke Kenneth Casson Leighton
- Copyright (C) 1997 Paul Ashton
- Copyright (C) 1997 Duncan Stansfield
-
-Version: 0.024 (01Nov97)
---------
-
-Distribution: Unlimited and encouraged, for the purposes of implementation
-------------- and comments. Feedback welcomed by the authors.
-
-Liability: Absolutely none accepted implicitly or explicitly, direct
----------- or consequentially, for use, abuse, misuse, lack of use,
- misunderstandings, mistakes, omissions, mis-information for
- anything in or not in, related to or not related to, or
- pertaining to this document, or anything else that a lawyer
- can think of or not think of.
-
-Warning: Please bear in mind that an incorrect implementation of this
--------- protocol can cause NT workstation to fail irrevocably, for
- which the authors accept no liability (see above). Please
- contact your vendor if you have any problems.
-
-Sources: - Packet Traces from Netmonitor (Service Pack 1 and above)
--------- - Paul Ashton and Luke Leighton's other "NT Domain" doc.
- - CIFS documentation - cifs6.txt
- - CIFS documentation - cifsrap2.txt
-
-Original: http://mailhost.cb1.com/~lkcl/cifsntdomain.txt.
---------- (Controlled copy maintained by lkcl@switchboard.net)
-
-Credits: - Paul Ashton: loads of work with Net Monitor;
--------- understanding the NT authentication system;
- reference implementation of the NT domain support on which
- this document is originally based.
- - Duncan Stansfield: low-level analysis of MSRPC Pipes.
- - Linus Nordberg: producing c-code from Paul's crypto spec.
- - Windows Sourcer development team
-
-
-Contents:
----------
-
- 1) Introduction
-
- 2) Structures and notes
-
- 2.1) Notes
- 2.3) Enumerations
- 2.3) Structures
-
- 3) Transact Named Pipe Header/Tail
-
- 3.1) MSRPC Pipes
- 3.2) Header
- 3.3) Tail
-
- 4) NTLSA Transact Named Pipe
-
- 4.1) LSA Open Policy
- 4.2) LSA Query Info Policy
- 4.3) LSA Enumerate Trusted Domains
- 4.4) LSA Open Secret
- 4.5) LSA Close
- 4.6) LSA Lookup SIDS
- 4.7) LSA Lookup Names
-
- 5) NETLOGON rpc Transact Named Pipe
-
- 5.1) LSA Request Challenge
- 5.2) LSA Authenticate 2
- 5.3) LSA Server Password Set
- 5.4) LSA SAM Logon
- 5.5) LSA SAM Logoff
-
- 6) \\MAILSLOT\NET\NTLOGON
-
- 6.1) Query for PDC
- 6.2) SAM Logon
-
- 7) SRVSVC Transact Named Pipe
-
- 7.1) Net Share Enum
- 7.2) Net Server Get Info
-
-
-Appendix:
----------
-
- A1) Cryptographic side of NT Domain Authentication
-
- A1.1) Definitions
- A1.2) Protocol
- A1.3) Comments
-
- A2) SIDs and RIDs
-
- A2.1) Well-known SIDs
-
- A2.1.1) Universal well-known SIDs
- A2.1.2) NT well-known SIDs
-
- A2.2) Well-known RIDS
-
- A2.2.1) Well-known RID users
- A2.2.2) Well-known RID groups
- A2.2.3) Well-known RID aliases
-
-
-
-1) Introduction
----------------
-
-
-This document contains information to provide an NT workstation with login
-services, without the need for an NT server.
-
-It should be possible to select a domain instead of a workgroup (in the NT
-workstation's TCP/IP settings) and after the obligatory reboot, type in a
-username, password, select a domain and successfully log in. I would
-appreciate any feedback on your experiences with this process, and any
-comments, corrections and additions to this document.
-
-
-The packets described here can be easily derived from (and are probably
-better understood using) Netmon.exe. You will need to use the version
-of Netmon that matches your system, in order to correctly decode the
-NETLOGON, lsarpc and srvsvc Transact pipes. This document is derived from
-NT Service Pack 1 and its corresponding version of Netmon. It is intended
-that an annotated packet trace be produced, which will likely be more
-instructive than this document.
-
-Also needed, to fully implement NT Domain Login Services, is the
-document describing the cryptographic part of the NT authentication.
-This document is available from comp.protocols.smb; from the ntsecurity.net
-digest and from the samba digest, amongst other sources.
-
-A copy is available from:
-
-http://ntbugtraq.rc.on.ca/SCRIPTS/WA.EXE?A2=ind9708&L=ntbugtraq&O=A&P=2935
-http://mailhost.cb1.com/~lkcl/crypt.html
-
-
-A c-code implementation, provided by Linus Nordberg <linus@incolumitas.se>
-of this protocol is available from:
-
-http://samba.org/cgi-bin/mfs/01/digest/1997/97aug/0391.html
-http://mailhost.cb1.com/~lkcl/crypt.txt
-
-
-Also used to provide debugging information is the Check Build version of
-NT workstation, and enabling full debugging in NETLOGON. This is
-achieved by setting the following REG_SZ registry key to 0x1ffffff:
-
-HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
-
-- Incorrect direct editing of the registry can cause your machine to fail.
- Then again, so can incorrect implementation of this protocol.
- See "Liability:" above.
-
-
-Bear in mind that each packet over-the-wire will have its origin in an
-API call. Therefore, there are likely to be structures, enumerations
-and defines that are usefully documented elsewhere.
-
-
-This document is by no means complete or authoritative. Missing sections
-include, but are not limited to:
-
-- the meaning (and use by NT) of SIDs and RIDs.
-
-- mappings of RIDs to usernames (and vice-versa).
-
-- what a User ID is and what a Group ID is.
-
-- the exact meaning/definition of various magic constants or enumerations.
-
-- the reply error code and use of that error code when a workstation
- becomes a member of a domain (to be described later). Failure to
- return this error code will make the workstation report that it is
- already a member of the domain.
-
-- the cryptographic side of the NetrServerPasswordSet command, which would
- allow the workstation to change its password. This password is used to
- generate the long-term session key. [It is possible to reject this
- command, and keep the default workstation password].
-
-
-2) Notes and Structures
------------------------
-
-
-2.1) Notes
-----------
-
-- In the SMB Transact pipes, some "Structures", described here, appear to be
- 4-byte aligned with the SMB header, at their start. Exactly which
- "Structures" need aligning is not precisely known or documented.
-
-- In the UDP NTLOGON Mailslots, some "Structures", described here, appear to be
- 2-byte aligned with the start of the mailslot, at their start.
-
-- Domain SID is of the format S-revision-version-auth1-auth2...authN.
- e.g S-1-5-123-456-789-123-456. the 5 could be a sub-revision.
-
-- any undocumented buffer pointers must be non-zero if the string buffer it
- refers to contains characters. exactly what value they should be is unknown.
- 0x0000 0002 seems to do the trick to indicate that the buffer exists. a
- NULL buffer pointer indicates that the string buffer is of zero length.
- If the buffer pointer is NULL, then it is suspected that the structure it
- refers to is NOT put into (or taken out of) the SMB data stream. This is
- empirically derived from, for example, the LSA SAM Logon response packet,
- where if the buffer pointer is NULL, the user information is not inserted
- into the data stream. Exactly what happens with an array of buffer pointers
- is not known, although an educated guess can be made.
-
-- an array of structures (a container) appears to have a count and a pointer.
- if the count is zero, the pointer is also zero. no further data is put
- into or taken out of the SMB data stream. if the count is non-zero, then
- the pointer is also non-zero. immediately following the pointer is the
- count again, followed by an array of container sub-structures. the count
- appears a third time after the last sub-structure.
-
-
-2.2) Enumerations
------------------
-
-- MSRPC Header type. command number in the msrpc packet header
-
- MSRPC_Request: 0x00
- MSRPC_Response: 0x02
- MSRPC_Bind: 0x0B
- MSRPC_BindAck: 0x0C
-
-- MSRPC Packet info. the meaning of these flags is undocumented
-
- FirstFrag: 0x01
- LastFrag: 0x02
- NotaFrag: 0x04
- RecRespond: 0x08
- NoMultiplex: 0x10
- NotForIdemp: 0x20
- NotforBcast: 0x40
- NoUuid: 0x80
-
-
-2.3) Structures
----------------
-
-- sizeof VOID* is 32 bits.
-
-- sizeof char is 8 bits.
-
-- UTIME is 32 bits, indicating time in seconds since 01jan1970. documented
- in cifs6.txt (section 3.5 page, page 30).
-
-- NTTIME is 64 bits. documented in cifs6.txt (section 3.5 page, page 30).
-
-- DOM_SID (domain SID structure) :
-
- UINT32 num of sub-authorities in domain SID
- UINT8 SID revision number
- UINT8 num of sub-authorities in domain SID
- UINT8[6] 6 bytes for domain SID - Identifier Authority.
- UINT16[n_subauths] domain SID sub-authorities
-
- Note: the domain SID is documented elsewhere.
-
-- STR (string) :
-
- char[] null-terminated string of ascii characters.
-
-- UNIHDR (unicode string header) :
-
- UINT16 length of unicode string
- UINT16 max length of unicode string
- UINT32 4 - undocumented.
-
-- UNIHDR2 (unicode string header plus buffer pointer) :
-
- UNIHDR unicode string header
- VOID* undocumented buffer pointer
-
-- UNISTR (unicode string) :
-
- UINT16[] null-terminated string of unicode characters.
-
-- NAME (length-indicated unicode string) :
-
- UINT32 length of unicode string
- UINT16[] null-terminated string of unicode characters.
-
-- UNISTR2 (aligned unicode string) :
-
- UINT8[] padding to get unicode string 4-byte aligned
- with the start of the SMB header.
- UINT32 max length of unicode string
- UINT32 0 - undocumented
- UINT32 length of unicode string
- UINT16[] string of uncode characters.
-
-- OBJ_ATTR (object attributes) :
-
- UINT32 0x18 - length (in bytes) including the length field.
- VOID* 0 - root directory (pointer)
- VOID* 0 - object name (pointer)
- UINT32 0 - attributes (undocumented)
- VOID* 0 - security descriptior (pointer)
- UINT32 0 - security quality of service
-
-- POL_HND (LSA policy handle) :
-
- char[20] policy handle
-
-- DOM_SID2 (domain SID structure, SIDS stored in unicode) :
-
- UINT32 5 - SID type
- UINT32 0 - undocumented
- UNIHDR2 domain SID unicode string header
- UNISTR domain SID unicode string
-
- Note: there is a conflict between the unicode string header and the
- unicode string itself as to which to use to indicate string
- length. this will need to be resolved.
-
- Note: the SID type indicates, for example, an alias; a well-known group etc.
- this is documented somewhere.
-
-- DOM_RID (domain RID structure) :
-
- UINT32 5 - well-known SID. 1 - user SID (see ShowACLs)
- UINT32 5 - undocumented
- UINT32 domain RID
- UINT32 0 - domain index out of above reference domains
-
-
-- LOG_INFO (server, account, client structure) :
-
- Note: logon server name starts with two '\' characters and is upper case.
-
- Note: account name is the logon client name from the LSA Request Challenge,
- with a $ on the end of it, in upper case.
-
- VOID* undocumented buffer pointer
- UNISTR2 logon server unicode string
- UNISTR2 account name unicode string
- UINT16 sec_chan - security channel type
- UNISTR2 logon client machine unicode string
-
-- CLNT_SRV (server, client names structure) :
-
- Note: logon server name starts with two '\' characters and is upper case.
-
- VOID* undocumented buffer pointer
- UNISTR2 logon server unicode string
- VOID* undocumented buffer pointer
- UNISTR2 logon client machine unicode string
-
-- CREDS (credentials + time stamp)
-
- char[8] credentials
- UTIME time stamp
-
-- CLNT_INFO2 (server, client structure, client credentials) :
-
- Note: whenever this structure appears in a request, you must take a copy
- of the client-calculated credentials received, because they will be
- used in subsequent credential checks. the presumed intention is to
- maintain an authenticated request/response trail.
-
- CLNT_SRV client and server names
- UINT8[] ???? padding, for 4-byte alignment with SMB header.
- VOID* pointer to client credentials.
- CREDS client-calculated credentials + client time
-
-- CLNT_INFO (server, account, client structure, client credentials) :
-
- Note: whenever this structure appears in a request, you must take a copy
- of the client-calculated credentials received, because they will be
- used in subsequent credential checks. the presumed intention is to
- maintain an authenticated request/response trail.
-
- LOG_INFO logon account info
- CREDS client-calculated credentials + client time
-
-- ID_INFO_1 (id info structure, auth level 1) :
-
- VOID* ptr_id_info_1
- UNIHDR domain name unicode header
- UINT32 param control
- UINT64 logon ID
- UNIHDR user name unicode header
- UNIHDR workgroup name unicode header
- char[16] arc4 LM OWF Password
- char[16] arc4 NT OWF Password
- UNISTR2 domain name unicode string
- UNISTR2 user name unicode string
- UNISTR2 workstation name unicode string
-
-- SAM_INFO (sam logon/logoff id info structure) :
-
- Note: presumably, the return credentials is supposedly for the server to
- verify that the credential chain hasn't been compromised.
-
- CLNT_INFO2 client identification/authentication info
- VOID* pointer to return credentials.
- CRED return credentials - ignored.
- UINT16 logon level
- UINT16 switch value
-
- switch (switch_value)
- case 1:
- {
- ID_INFO_1 id_info_1;
- }
-
-- GID (group id info) :
-
- UINT32 group id
- UINT32 user attributes (only used by NT 3.1 and 3.51)
-
-- DOM_REF (domain reference info) :
-
- VOID* undocumented buffer pointer.
- UINT32 num referenced domains?
- VOID* undocumented domain name buffer pointer.
- UINT32 32 - max number of entries
- UINT32 4 - num referenced domains?
-
- UNIHDR2 domain name unicode string header
- UNIHDR2[num_ref_doms-1] referenced domain unicode string headers
-
- UNISTR domain name unicode string
- DOM_SID[num_ref_doms] referenced domain SIDs
-
-- DOM_INFO (domain info, levels 3 and 5 are the same)) :
-
- UINT8[] ??? padding to get 4-byte alignment with start of SMB header
- UINT16 domain name string length * 2
- UINT16 domain name string length * 2
- VOID* undocumented domain name string buffer pointer
- VOID* undocumented domain SID string buffer pointer
- UNISTR2 domain name (unicode string)
- DOM_SID domain SID
-
-- USER_INFO (user logon info) :
-
- Note: it would be nice to know what the 16 byte user session key is for.
-
- NTTIME logon time
- NTTIME logoff time
- NTTIME kickoff time
- NTTIME password last set time
- NTTIME password can change time
- NTTIME password must change time
-
- UNIHDR username unicode string header
- UNIHDR user's full name unicode string header
- UNIHDR logon script unicode string header
- UNIHDR profile path unicode string header
- UNIHDR home directory unicode string header
- UNIHDR home directory drive unicode string header
-
- UINT16 logon count
- UINT16 bad password count
-
- UINT32 User ID
- UINT32 Group ID
- UINT32 num groups
- VOID* undocumented buffer pointer to groups.
-
- UINT32 user flags
- char[16] user session key
-
- UNIHDR logon server unicode string header
- UNIHDR logon domain unicode string header
- VOID* undocumented logon domain id pointer
- char[40] 40 undocumented padding bytes. future expansion?
-
- UINT32 0 - num_other_sids?
- VOID* NULL - undocumented pointer to other domain SIDs.
-
- UNISTR2 username unicode string
- UNISTR2 user's full name unicode string
- UNISTR2 logon script unicode string
- UNISTR2 profile path unicode string
- UNISTR2 home directory unicode string
- UNISTR2 home directory drive unicode string
-
- UINT32 num groups
- GID[num_groups] group info
-
- UNISTR2 logon server unicode string
- UNISTR2 logon domain unicode string
-
- DOM_SID domain SID
- DOM_SID[num_sids] other domain SIDs?
-
-- SH_INFO_1_PTR (pointers to level 1 share info strings):
-
-Note: see cifsrap2.txt section5, page 10.
-
- 0 for shi1_type indicates a Disk.
- 1 for shi1_type indicates a Print Queue.
- 2 for shi1_type indicates a Device.
- 3 for shi1_type indicates an IPC pipe.
- 0x8000 0000 (top bit set in shi1_type) indicates a hidden share.
-
- VOID* shi1_netname - pointer to net name
- UINT32 shi1_type - type of share. 0 - undocumented.
- VOID* shi1_remark - pointer to comment.
-
-- SH_INFO_1_STR (level 1 share info strings) :
-
- UNISTR2 shi1_netname - unicode string of net name
- UNISTR2 shi1_remark - unicode string of comment.
-
-- SHARE_INFO_1_CTR :
-
- share container with 0 entries:
-
- UINT32 0 - EntriesRead
- UINT32 0 - Buffer
-
- share container with > 0 entries:
-
- UINT32 EntriesRead
- UINT32 non-zero - Buffer
- UINT32 EntriesRead
-
- SH_INFO_1_PTR[EntriesRead] share entry pointers
- SH_INFO_1_STR[EntriesRead] share entry strings
-
- UINT8[] padding to get unicode string 4-byte
- aligned with start of the SMB header.
- UINT32 EntriesRead
- UINT32 0 - padding
-
-- SERVER_INFO_101 :
-
-Note: see cifs6.txt section 6.4 - the fields described therein will be
- of assistance here. for example, the type listed below is the
- same as fServerType, which is described in 6.4.1.
-
- SV_TYPE_WORKSTATION 0x00000001 All workstations
- SV_TYPE_SERVER 0x00000002 All servers
- SV_TYPE_SQLSERVER 0x00000004 Any server running with SQL
- server
- SV_TYPE_DOMAIN_CTRL 0x00000008 Primary domain controller
- SV_TYPE_DOMAIN_BAKCTRL 0x00000010 Backup domain controller
- SV_TYPE_TIME_SOURCE 0x00000020 Server running the timesource
- service
- SV_TYPE_AFP 0x00000040 Apple File Protocol servers
- SV_TYPE_NOVELL 0x00000080 Novell servers
- SV_TYPE_DOMAIN_MEMBER 0x00000100 Domain Member
- SV_TYPE_PRINTQ_SERVER 0x00000200 Server sharing print queue
- SV_TYPE_DIALIN_SERVER 0x00000400 Server running dialin service.
- SV_TYPE_XENIX_SERVER 0x00000800 Xenix server
- SV_TYPE_NT 0x00001000 NT server
- SV_TYPE_WFW 0x00002000 Server running Windows for
-
- SV_TYPE_SERVER_NT 0x00008000 Windows NT non DC server
- SV_TYPE_POTENTIAL_BROWSER 0x00010000 Server that can run the browser
- service
- SV_TYPE_BACKUP_BROWSER 0x00020000 Backup browser server
- SV_TYPE_MASTER_BROWSER 0x00040000 Master browser server
- SV_TYPE_DOMAIN_MASTER 0x00080000 Domain Master Browser server
- SV_TYPE_LOCAL_LIST_ONLY 0x40000000 Enumerate only entries marked
- "local"
- SV_TYPE_DOMAIN_ENUM 0x80000000 Enumerate Domains. The pszServer
- and pszDomain parameters must be
- NULL.
-
- UINT32 500 - platform_id
- VOID* pointer to name
- UINT32 5 - major version
- UINT32 4 - minor version
- UINT32 type (SV_TYPE_... bit field)
- VOID* pointer to comment
-
- UNISTR2 sv101_name - unicode string of server name
- UNISTR2 sv_101_comment - unicode string of server comment.
-
- UINT8[] padding to get unicode string 4-byte
- aligned with start of the SMB header.
-
-
-
-3) MSRPC over Transact Named Pipe
----------------------------------
-
-For details on the SMB Transact Named Pipe, see cifs6.txt
-
-
-3.1) MSRPC Pipes
-----------------
-
-The MSRPC is conducted over an SMB Transact Pipe with a name of "\PIPE\".
-You must first obtain a 16 bit file handle, by sending a SMBopenX with the
-pipe name "\PIPE\srvsvc" for example. You can then perform an SMB Trans,
-and must carry out an SMBclose on the file handle once you are finished.
-
-Trans Requests must be sent with two setup UINT16s, no UINT16 params (none
-known about), and UINT8 data parameters sufficient to contain the MSRPC
-header, and MSRPC data. The first UINT16 setup parameter must be either
-0x0026 to indicate an RPC, or 0x0001 to indicate Set Named Pipe Handle
-state. The second UINT16 parameter must be the file handle for the pipe,
-obtained above.
-
-The Data section for an API Command of 0x0026 (RPC pipe) in the Trans
-Request is the RPC Header, followed by the RPC Data. The Data section for
-an API Command of 0x0001 (Set Named Pipe Handle state) is two bytes. The
-only value seen for these two bytes is 0x00 0x43.
-
-
-MSRPC Responses are sent as response data inside standard SMB Trans
-responses, with the MSRPC Header, MSRPC Data and MSRPC tail.
-
-
-It is suspected that the Trans Requests will need to be at least 2-byte
-aligned (probably 4-byte). This is standard practice for SMBs. It is also
-independent of the observed 4-byte alignments with the start of the MSRPC
-header, including the 4-byte alignment between the MSRPC header and the
-MSRPC data.
-
-
-First, an SMBtconX connection is made to the IPC$ share. The connection
-must be made using encrypted passwords, not clear-text. Then, an SMBopenX
-is made on the pipe. Then, a Set Named Pipe Handle State must be sent,
-after which the pipe is ready to accept API commands. Lastly, and SMBclose
-is sent.
-
-
-To be resolved:
-
- lkcl/01nov97 there appear to be two additional bytes after the null-
- terminated \PIPE\ name for the RPC pipe. Values seen so far are
- listed below:
-
- initial SMBopenX request: RPC API command 0x26 params:
-
- "\\PIPE\\lsarpc" 0x65 0x63; 0x72 0x70; 0x44 0x65;
- "\\PIPE\\srvsvc" 0x73 0x76; 0x4E 0x00; 0x5C 0x43;
-
-
-3.2) Header
------------
-
-[section to be rewritten, following receipt of work by Duncan Stansfield]
-
-
-Interesting note: if you set packed data representation to 0x0100 0000
-then all 4-byte and 2-byte word ordering is turned around!
-
-The start of each of the NTLSA and NETLOGON named pipes begins with:
-
-00 UINT8 5 - RPC major version
-01 UINT8 0 - RPC minor version
-02 UINT8 2 - RPC response packet
-03 UINT8 3 - (FirstFrag bit-wise or with LastFrag)
-04 UINT32 0x1000 0000 - packed data representation
-08 UINT16 fragment length - data size (bytes) inc header and tail.
-0A UINT16 0 - authentication length
-0C UINT32 call identifier. matches 12th UINT32 of incoming RPC data.
-10 UINT32 allocation hint - data size (bytes) minus header and tail.
-14 UINT16 0 - presentation context identifier
-16 UINT8 0 - cancel count
-17 UINT8 in replies: 0 - reserved; in requests: opnum - see #defines.
-18 ...... start of data (goes on for allocation_hint bytes)
-
-
-RPC_Packet for request, response, bind and bind acknowledgement.
-{
-
- UINT8 versionmaj # reply same as request (0x05)
- UINT8 versionmin # reply same as request (0x00)
- UINT8 type # one of the MSRPC_Type enums
- UINT8 flags # reply same as request (0x00 for Bind, 0x03 for Request)
- UINT32 representation # reply same as request (0x00000010)
- UINT16 fraglength # the length of the data section of the SMB trans packet
- UINT16 authlength
- UINT32 callid # call identifier. (e.g. 0x00149594)
-
- * stub USE TvPacket # the remainder of the packet depending on the "type"
-}
-
-
-# the interfaces are numbered. as yet I haven't seen more than one interface
-# used on the same pipe name
-# srvsvc
-# abstract (0x4B324FC8, 0x01D31670, 0x475A7812, 0x88E16EBF, 0x00000003)
-# transfer (0x8A885D04, 0x11C91CEB, 0x0008E89F, 0x6048102B, 0x00000002)
-RPC_Iface RW
-{
- UINT8 byte[16] # 16 bytes of number
- UINT32 version # the interface number
-}
-
-
-# the remainder of the packet after the header if "type" was Bind
-# in the response header, "type" should be BindAck
-RPC_ReqBind RW
-{
- UINT16 maxtsize # maximum transmission fragment size (0x1630)
- UINT16 maxrsize # max receive fragment size (0x1630)
- UINT32 assocgid # associated group id (0x0)
- UINT32 numelements # the number of elements (0x1)
- UINT16 contextid # presentation context identifier (0x0)
- UINT8 numsyntaxes # the number of syntaxes (has always been 1?)(0x1)
- UINT8[] # 4-byte alignment padding, against SMB header
-
- * abstractint USE RPC_Iface # num and vers. of interface client is using
- * transferint USE RPC_Iface # num and vers. of interface to use for replies
-}
-
-
-RPC_Address RW
-{
- UINT16 length # length of the string including null terminator
- * port USE string # the string above in single byte, null terminated form
-}
-
-
-# the response to place after the header in the reply packet
-RPC_ResBind RW
-{
- UINT16 maxtsize # same as request
- UINT16 maxrsize # same as request
- UINT32 assocgid # zero
-
- * secondaddr USE RPC_Address # the address string, as described earlier
-
- UINT8[] # 4-byte alignment padding, against SMB header
-
- UINT8 numresults # the number of results (0x01)
-
- UINT8[] # 4-byte alignment padding, against SMB header
- UINT16 result # result (0x00 = accept)
- UINT16 reason # reason (0x00 = no reason specified)
-
- * transfersyntax USE RPC_Iface # the transfer syntax from the request
-}
-
-
-# the remainder of the packet after the header for every other other
-# request
-RPC_ReqNorm RW
-{
- UINT32 allochint # the size of the stub data in bytes
- UINT16 prescontext # presentation context identifier (0x0)
- UINT16 opnum # operation number (0x15)
-
- * stub USE TvPacket # a packet dependent on the pipe name
- # (probably the interface) and the op number)
-}
-
-
-# response to a request
-RPC_ResNorm RW
-{
- UINT32 allochint # size of the stub data in bytes
- UINT16 prescontext # presentation context identifier (same as request)
- UINT8 cancelcount # cancel count? (0x0)
- UINT8 reserved # 0 - one byte padding
-
- * stub USE TvPacket # the remainder of the reply
-}
-
-
-3.3) Tail
----------
-
-The end of each of the NTLSA and NETLOGON named pipes ends with:
-
- ...... end of data
- UINT32 return code
-
-
-
-3.4 RPC Bind / Bind Ack
------------------------
-
-RPC Binds are the process of associating an RPC pipe (e.g \PIPE\lsarpc)
-with a "transfer syntax" (see RPC_Iface structure). The purpose for doing
-this is unknown.
-
-Note: The RPC_ResBind SMB Transact request is sent with two uint16 setup
- parameters. The first is 0x0026; the second is the file handle
- returned by the SMBopenX Transact response.
-
-Note: The RPC_ResBind members maxtsize, maxrsize and assocgid are the
- same in the response as the same members in the RPC_ReqBind. The
- RPC_ResBind member transfersyntax is the same in the response as
- the
-
-Note: The RPC_ResBind response member secondaddr contains the name
- of what is presumed to be the service behind the RPC pipe. The
- mapping identified so far is:
-
- initial SMBopenX request: RPC_ResBind response:
-
- "\\PIPE\\srvsvc" "\\PIPE\\ntsvcs"
- "\\PIPE\\samr" "\\PIPE\\lsass"
- "\\PIPE\\lsarpc" "\\PIPE\\lsass"
- "\\PIPE\\wkssvc" "\\PIPE\\wksvcs"
- "\\PIPE\\NETLOGON" "\\PIPE\\NETLOGON"
-
-Note: The RPC_Packet fraglength member in both the Bind Request and Bind
- Acknowledgment must contain the length of the entire RPC data,
- including the RPC_Packet header.
-
-Request:
-
- RPC_Packet
- RPC_ReqBind
-
-Response:
-
- RPC_Packet
- RPC_ResBind
-
-
-
-4) NTLSA Transact Named Pipe
-----------------------------
-
-The sequence of actions taken on this pipe are:
-
-- Establish a connection to the IPC$ share (SMBtconX). use encrypted passwords.
-- Open an RPC Pipe with the name "\\PIPE\\lsarpc". Store the file handle.
-- Using the file handle, send a Set Named Pipe Handle state to 0x4300.
-- Send an LSA Open Policy request. Store the Policy Handle.
-- Using the Policy Handle, send LSA Query Info Policy requests, etc.
-- Using the Policy Handle, send an LSA Close.
-- Close the IPC$ share.
-
-
-Defines for this pipe, identifying the query are:
-
-- LSA Open Policy: 0x2c
-- LSA Query Info Policy: 0x07
-- LSA Enumerate Trusted Domains: 0x0d
-- LSA Open Secret: 0xff
-- LSA Lookup SIDs: 0xfe
-- LSA Lookup Names: 0xfd
-- LSA Close: 0x00
-
-
-4.1) LSA Open Policy
---------------------
-
-Note: The policy handle can be anything you like.
-
-Request:
-
- VOID* buffer pointer
- UNISTR2 server name - unicode string starting with two '\'s
- OBJ_ATTR object attributes
- UINT32 1 - desired access
-
-Response:
-
- POL_HND LSA policy handle
-
- return 0 - indicates success
-
-
-4.2) LSA Query Info Policy
---------------------------
-
-Note: The info class in response must be the same as that in the request.
-
-Request:
-
- POL_HND LSA policy handle
- UINT16 info class (also a policy handle?)
-
-Response:
-
- VOID* undocumented buffer pointer
- UINT16 info class (same as info class in request).
-
- switch (info class)
- case 3:
- case 5:
- {
- DOM_INFO domain info, levels 3 and 5 (are the same).
- }
-
- return 0 - indicates success
-
-
-4.3) LSA Enumerate Trusted Domains
-----------------------------------
-
-Request:
-
- no extra data
-
-Response:
-
- UINT32 0 - enumeration context
- UINT32 0 - entries read
- UINT32 0 - trust information
-
- return 0x8000 001a - "no trusted domains" success code
-
-
-4.4) LSA Open Secret
---------------------
-
-Request:
-
- no extra data
-
-Response:
-
- UINT32 0 - undocumented
- UINT32 0 - undocumented
- UINT32 0 - undocumented
- UINT32 0 - undocumented
- UINT32 0 - undocumented
-
- return 0x0C00 0034 - "no such secret" success code
-
-
-4.5) LSA Close
---------------
-
-Request:
-
- POL_HND policy handle to be closed
-
-Response:
-
- POL_HND 0s - closed policy handle (all zeros)
-
- return 0 - indicates success
-
-
-4.6) LSA Lookup SIDS
---------------------
-
-Note: num_entries in response must be same as num_entries in request.
-
-Request:
-
- POL_HND LSA policy handle
- UINT32 num_entries
- VOID* undocumented domain SID buffer pointer
- VOID* undocumented domain name buffer pointer
- VOID*[num_entries] undocumented domain SID pointers to be looked up.
- DOM_SID[num_entries] domain SIDs to be looked up.
- char[16] completely undocumented 16 bytes.
-
-Response:
-
- DOM_REF domain reference response
-
- UINT32 num_entries (listed above)
- VOID* undocumented buffer pointer
-
- UINT32 num_entries (listed above)
- DOM_SID2[num_entries] domain SIDs (from Request, listed above).
-
- UINT32 num_entries (listed above)
-
- return 0 - indicates success
-
-
-4.7) LSA Lookup Names
----------------------
-
-Note: num_entries in response must be same as num_entries in request.
-
-Request:
-
- POL_HND LSA policy handle
- UINT32 num_entries
- UINT32 num_entries
- VOID* undocumented domain SID buffer pointer
- VOID* undocumented domain name buffer pointer
- NAME[num_entries] names to be looked up.
- char[] undocumented bytes - falsely translated SID structure?
-
-Response:
-
- DOM_REF domain reference response
-
- UINT32 num_entries (listed above)
- VOID* undocumented buffer pointer
-
- UINT32 num_entries (listed above)
- DOM_RID[num_entries] domain SIDs (from Request, listed above).
-
- UINT32 num_entries (listed above)
-
- return 0 - indicates success
-
-
-
-5) NETLOGON rpc Transact Named Pipe
------------------------------------
-
-The sequence of actions taken on this pipe are:
-
-- Establish a connection to the IPC$ share (SMBtconX). use encrypted passwords.
-- Open an RPC Pipe with the name "\\PIPE\\NETLOGON". Store the file handle.
-- Using the file handle, send a Set Named Pipe Handle state to 0x4300.
-- Create Client Challenge. Send LSA Request Challenge. Store Server Challenge.
-- Calculate Session Key. Send an LSA Auth 2 Challenge. Store Auth2 Challenge.
-- Calc/Verify Client Creds. Send LSA Srv PW Set. Calc/Verify Server Creds.
-- Calc/Verify Client Creds. Send LSA SAM Logon . Calc/Verify Server Creds.
-- Calc/Verify Client Creds. Send LSA SAM Logoff. Calc/Verify Server Creds.
-- Close the IPC$ share.
-
-
-Defines for this pipe, identifying the query are:
-
-- LSA Request Challenge: 0x04
-- LSA Server Password Set: 0x06
-- LSA SAM Logon: 0x02
-- LSA SAM Logoff: 0x03
-- LSA Auth 2: 0x0f
-- LSA Logon Control: 0x0e
-
-
-5.1) LSA Request Challenge
---------------------------
-
-Note: logon server name starts with two '\' characters and is upper case.
-
-Note: logon client is the machine, not the user.
-
-Note: the initial LanManager password hash, against which the challenge
- is issued, is the machine name itself (lower case). there will be
- calls issued (LSA Server Password Set) which will change this, later.
- refusing these calls allows you to always deal with the same password
- (i.e the LM# of the machine name in lower case).
-
-Request:
-
- VOID* undocumented buffer pointer
- UNISTR2 logon server unicode string
- UNISTR2 logon client unicode string
- char[8] client challenge
-
-Response:
-
- char[8] server challenge
-
- return 0 - indicates success
-
-
-
-5.2) LSA Authenticate 2
------------------------
-
-Note: in between request and response, calculate the client credentials,
- and check them against the client-calculated credentials (this
- process uses the previously received client credentials).
-
-Note: neg_flags in the response is the same as that in the request.
-
-Note: you must take a copy of the client-calculated credentials received
- here, because they will be used in subsequent authentication packets.
-
-Request:
-
- LOG_INFO client identification info
-
- char[8] client-calculated credentials
- UINT8[] padding to 4-byte align with start of SMB header.
- UINT32 neg_flags - negotiated flags (usual value is 0x0000 01ff)
-
-Response:
-
- char[8] server credentials.
- UINT32 neg_flags - same as neg_flags in request.
-
- return 0 - indicates success. failure value unknown.
-
-
-5.3) LSA Server Password Set
-----------------------------
-
-Note: the new password is suspected to be a DES encryption using the old
- password to generate the key.
-
-Note: in between request and response, calculate the client credentials,
- and check them against the client-calculated credentials (this
- process uses the previously received client credentials).
-
-Note: the server credentials are constructed from the client-calculated
- credentials and the client time + 1 second.
-
-Note: you must take a copy of the client-calculated credentials received
- here, because they will be used in subsequent authentication packets.
-
-Request:
-
- CLNT_INFO client identification/authentication info
- char[] new password - undocumented.
-
-Response:
-
- CREDS server credentials. server time stamp appears to be ignored.
-
- return 0 - indicates success; 0xC000 006a indicates failure
-
-
-5.4) LSA SAM Logon
-------------------
-
-Note: valid_user is True iff the username and password hash are valid for
- the requested domain.
-
-Request:
-
- SAM_INFO sam_id structure
-
-Response:
-
- VOID* undocumented buffer pointer
- CREDS server credentials. server time stamp appears to be ignored.
-
- if (valid_user)
- {
- UINT16 3 - switch value indicating USER_INFO structure.
- VOID* non-zero - pointer to USER_INFO structure
- USER_INFO user logon information
-
- UINT32 1 - Authoritative response; 0 - Non-Auth?
-
- return 0 - indicates success
- }
- else
- {
- UINT16 0 - switch value. value to indicate no user presumed.
- VOID* 0x0000 0000 - indicates no USER_INFO structure.
-
- UINT32 1 - Authoritative response; 0 - Non-Auth?
-
- return 0xC000 0064 - NT_STATUS_NO_SUCH_USER.
- }
-
-
-5.5) LSA SAM Logoff
---------------------
-
-Note: presumably, the SAM_INFO structure is validated, and a (currently
- undocumented) error code returned if the Logoff is invalid.
-
-Request:
-
- SAM_INFO sam_id structure
-
-Response:
-
- VOID* undocumented buffer pointer
- CREDS server credentials. server time stamp appears to be ignored.
-
- return 0 - indicates success. undocumented failure indication.
-
-
-6) \\MAILSLOT\NET\NTLOGON
--------------------------
-
-Note: mailslots will contain a response mailslot, to which the response
- should be sent. the target NetBIOS name is REQUEST_NAME<20>, where
- REQUEST_NAME is the name of the machine that sent the request.
-
-
-6.1) Query for PDC
-------------------
-
-Note: NTversion, LMNTtoken, LM20token in response are the same as those
- given in the request.
-
-Request:
-
- UINT16 0x0007 - Query for PDC
- STR machine name
- STR response mailslot
- UINT8[] padding to 2-byte align with start of mailslot.
- UNISTR machine name
- UINT32 NTversion
- UINT16 LMNTtoken
- UINT16 LM20token
-
-Response:
-
- UINT16 0x000A - Respose to Query for PDC
- STR machine name (in uppercase)
- UINT8[] padding to 2-byte align with start of mailslot.
- UNISTR machine name
- UNISTR domain name
- UINT32 NTversion (same as received in request)
- UINT16 LMNTtoken (same as received in request)
- UINT16 LM20token (same as received in request)
-
-
-6.2) SAM Logon
---------------
-
-Note: machine name in response is preceded by two '\' characters.
-
-Note: NTversion, LMNTtoken, LM20token in response are the same as those
- given in the request.
-
-Note: user name in the response is presumably the same as that in the request.
-
-Request:
-
- UINT16 0x0012 - SAM Logon
- UINT16 request count
- UNISTR machine name
- UNISTR user name
- STR response mailslot
- UINT32 alloweable account
- UINT32 domain SID size
- char[sid_size] domain SID, of sid_size bytes.
- UINT8[] ???? padding to 4? 2? -byte align with start of mailslot.
- UINT32 NTversion
- UINT16 LMNTtoken
- UINT16 LM20token
-
-Response:
-
- UINT16 0x0013 - Response to SAM Logon
- UNISTR machine name
- UNISTR user name - workstation trust account
- UNISTR domain name
- UINT32 NTversion
- UINT16 LMNTtoken
- UINT16 LM20token
-
-
-
-7) SRVSVC Transact Named Pipe
------------------------------
-
-
-Defines for this pipe, identifying the query are:
-
-- Net Share Enum : 0x0f
-- Net Server Get Info : 0x15
-
-
-7.1) Net Share Enum
-------------------
-
-Note: share level and switch value in the response are presumably the
- same as those in the request.
-
-Note: cifsrap2.txt (section 5) may be of limited assistance here.
-
-Request:
-
- VOID* pointer (to server name?)
- UNISTR2 server name
-
- UINT8[] padding to get unicode string 4-byte aligned
- with the start of the SMB header.
-
- UINT32 share level
- UINT32 switch value
-
- VOID* pointer to SHARE_INFO_1_CTR
- SHARE_INFO_1_CTR share info with 0 entries
-
- UINT32 preferred maximum length (0xffff ffff)
-
-Response:
-
- UINT32 share level
- UINT32 switch value
-
- VOID* pointer to SHARE_INFO_1_CTR
- SHARE_INFO_1_CTR share info (only added if share info ptr is non-zero)
-
- return 0 - indicates success
-
-
-7.2) Net Server Get Info
-------------------
-
-Note: level is the same value as in the request.
-
-Request:
-
- UNISTR2 server name
- UINT32 switch level
-
-Response:
-
- UINT32 switch level
- VOID* pointer to SERVER_INFO_101
-
- SERVER_INFO_101 server info (only added if server info ptr is non-zero)
-
- return 0 - indicates success
-
-
-
-Appendix
---------
-
-A1) Cryptographic side of NT Domain Authentication
---------------------------------------------------
-
-
-A1.1) Definitions
------------------
-
-Add(A1,A2): Intel byte ordered addition of corresponding 4 byte words
-in arrays A1 and A2
-
-E(K,D): DES ECB encryption of 8 byte data D using 7 byte key K
-
-lmowf(): Lan man hash
-
-ntowf(): NT hash
-
-PW: md4(machine_password) == md4(lsadump $machine.acc) ==
-pwdump(machine$) (initially) == md4(lmowf(unicode(machine)))
-
-ARC4(K,Lk,D,Ld): ARC4 encryption of data D of length Ld with key K of
-length Lk
-
-v[m..n(,l)]: subset of v from bytes m to n, optionally padded with
-zeroes to length l
-
-Cred(K,D): E(K[7..7,7],E(K[0..6],D)) computes a credential
-
-Time(): 4 byte current time
-
-Cc,Cs: 8 byte client and server challenges Rc,Rs: 8 byte client and
-server credentials
-
-
-A1.2) Protocol
---------------
-
-C->S ReqChal,Cc S->C Cs
-
-C & S compute session key Ks = E(PW[9..15],E(PW[0..6],Add(Cc,Cs)))
-
-C: Rc = Cred(Ks,Cc) C->S Authenticate,Rc S: Rs = Cred(Ks,Cs),
-assert(Rc == Cred(Ks,Cc)) S->C Rs C: assert(Rs == Cred(Ks,Cs))
-
-On joining the domain the client will optionally attempt to change its
-password and the domain controller may refuse to update it depending
-on registry settings. This will also occur weekly afterwards.
-
-C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S ServerPasswordSet,Rc',Tc,
-arc4(Ks[0..7,16],lmowf(randompassword()) C: Rc = Cred(Ks,Rc+Tc+1) S:
-assert(Rc' == Cred(Ks,Rc+Tc)), Ts = Time() S: Rs' = Cred(Ks,Rs+Tc+1)
-S->C Rs',Ts C: assert(Rs' == Cred(Ks,Rs+Tc+1)) S: Rs = Rs'
-
-User: U with password P wishes to login to the domain (incidental data
-such as workstation and domain omitted)
-
-C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S NetLogonSamLogon,Rc',Tc,U,
-arc4(Ks[0..7,16],16,ntowf(P),16), arc4(Ks[0..7,16],16,lmowf(P),16) S:
-assert(Rc' == Cred(Ks,Rc+Tc)) assert(passwords match those in SAM) S:
-Ts = Time()
-
-S->C Cred(Ks,Cred(Ks,Rc+Tc+1)),userinfo(logon script,UID,SIDs,etc) C:
-assert(Rs == Cred(Ks,Cred(Rc+Tc+1)) C: Rc = Cred(Ks,Rc+Tc+1)
-
-
-A1.3) Comments
---------------
-
-On first joining the domain the session key could be computed by
-anyone listening in on the network as the machine password has a well
-known value. Until the machine is rebooted it will use this session
-key to encrypt NT and LM one way functions of passwords which are
-password equivalents. Any user who logs in before the machine has been
-rebooted a second time will have their password equivalent exposed. Of
-course the new machine password is exposed at this time anyway.
-
-None of the returned user info such as logon script, profile path and
-SIDs *appear* to be protected by anything other than the TCP checksum.
-
-The server time stamps appear to be ignored.
-
-The client sends a ReturnAuthenticator in the SamLogon request which I
-can't find a use for. However its time is used as the timestamp
-returned by the server.
-
-The password OWFs should NOT be sent over the network reversibly
-encrypted. They should be sent using ARC4(Ks,md4(owf)) with the server
-computing the same function using the owf values in the SAM.
-
-
-A2) SIDs and RIDs
------------------
-
-SIDs and RIDs are well documented elsewhere.
-
-A SID is an NT Security ID (see DOM_SID structure). They are of the form:
-
- S-revision-NN-SubAuth1-SubAuth2-SubAuth3...
- S-revision-0xNNNNNNNNNNNN-SubAuth1-SubAuth2-SubAuth3...
-
-currently, the SID revision is 1.
-The Sub-Authorities are known as Relative IDs (RIDs).
-
-
-A2.1) Well-known SIDs
----------------------
-
-
-A2.1.1) Universal well-known SIDs
----------------------------------
-
- Null SID S-1-0-0
- World S-1-1-0
- Local S-1-2-0
- Creator Owner ID S-1-3-0
- Creator Group ID S-1-3-1
- Creator Owner Server ID S-1-3-2
- Creator Group Server ID S-1-3-3
-
- (Non-unique IDs) S-1-4
-
-
-A2.1.2) NT well-known SIDs
---------------------------
-
- NT Authority S-1-5
- Dialup S-1-5-1
-
- Network S-1-5-2
- Batch S-1-5-3
- Interactive S-1-5-4
- Service S-1-5-6
- AnonymousLogon S-1-5-7 (aka null logon session)
- Proxy S-1-5-8
- ServerLogon S-1-5-8 (aka domain controller account)
-
- (Logon IDs) S-1-5-5-X-Y
-
- (NT non-unique IDs) S-1-5-0x15-...
-
- (Built-in domain) s-1-5-0x20
-
-
-
-A2.2) Well-known RIDS
----------------------
-
-A RID is a sub-authority value, as part of either a SID, or in the case
-of Group RIDs, part of the DOM_GID structure, in the USER_INFO_1
-structure, in the LSA SAM Logon response.
-
-
-A2.2.1) Well-known RID users
-----------------------------
-
- DOMAIN_USER_RID_ADMIN 0x0000 01F4
- DOMAIN_USER_RID_GUEST 0x0000 01F5
-
-
-
-A2.2.2) Well-known RID groups
-----------------------------
-
- DOMAIN_GROUP_RID_ADMINS 0x0000 0200
- DOMAIN_GROUP_RID_USERS 0x0000 0201
- DOMAIN_GROUP_RID_GUESTS 0x0000 0202
-
-
-
-A2.2.3) Well-known RID aliases
-------------------------------
-
- DOMAIN_ALIAS_RID_ADMINS 0x0000 0220
- DOMAIN_ALIAS_RID_USERS 0x0000 0221
- DOMAIN_ALIAS_RID_GUESTS 0x0000 0222
- DOMAIN_ALIAS_RID_POWER_USERS 0x0000 0223
-
- DOMAIN_ALIAS_RID_ACCOUNT_OPS 0x0000 0224
- DOMAIN_ALIAS_RID_SYSTEM_OPS 0x0000 0225
- DOMAIN_ALIAS_RID_PRINT_OPS 0x0000 0226
- DOMAIN_ALIAS_RID_BACKUP_OPS 0x0000 0227
-
- DOMAIN_ALIAS_RID_REPLICATOR 0x0000 0228
-
-
diff --git a/docs/textdocs/outdated/NTDOMAIN.txt b/docs/textdocs/outdated/NTDOMAIN.txt
deleted file mode 100644
index 8408acb979..0000000000
--- a/docs/textdocs/outdated/NTDOMAIN.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-!==
-!== NTDOMAIN.txt for Samba release 2.0.4 18 May 1999
-!==
-Contributor: Luke Kenneth Casson Leighton (samba-bugs@samba.org)
- Copyright (C) 1997 Luke Kenneth Casson Leighton
-Created: October 20, 1997
-Updated: February 25, 1999 (Jerry Carter)
-
-Subject: NT Domain Logons
-===========================================================================
-
-As of 1.9.18alpha1, Samba supports logins for NT 3.51 and 4.0 Workstations,
-without the need, use or intervention of NT Server. This document describes
-how to set this up. Over the continued development of the 1.9.18alpha
-series, this process (and therefore this document) should become simpler.
-
-One useful thing to do is to get this version of Samba up and running
-with Win95 profiles, as you would for the current stable version of
-Samba (currently at 1.9.17p4), and is fully documented. You will need
-to set up encrypted passwords. Even if you don't have any Win95 machines,
-using your Samba Server to store the profile for one of your NT Workstation
-users is a good test that you have 1.9.18alpha1 correctly configured *prior*
-to attempting NT Domain Logons.
-
-The support is still experimental, so should be used at your own risk.
-
-NT is not as robust as you might have been led to believe: during the
-development of the Domain Logon Support, one person reported having to
-reinstall NT from scratch: their workstation had become totally unuseable.
-
-[further reports on ntsec@iss.net by independent administrators showing
- similar symptoms lead us to believe that the SAM database file may be
- corruptible. this _is_ recoverable (or, at least the machine is accessible),
- by deleting the SAM file, under which circumstances all user account details
- are lost, but at least the Administrator can log in with a blank password.
- this is *not* possible except if the NT system is installed in a FAT
- partition.]
-
-This *has* been reported to the NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM digest.
-
-==========================================================================
-Please note that Samba 2.0 does not **officially** support domain logons
-for Windows NT clients. Of course, domain logon support for Windows 9x
-clients is complete and official. These are two different issues.
-
-Samba's capability to act as a Primary Domain Controller for Windows NT
-domains is not advertised as it is not completed yet. For more information
-regarding how to obtain the latest development (HEAD branch) source code
-and what features are available, please refer to the NT Domain FAQ on-line
-at the Samba web site under the documentation page.
-
diff --git a/docs/textdocs/outdated/PROJECTS b/docs/textdocs/outdated/PROJECTS
deleted file mode 100644
index 3008bea430..0000000000
--- a/docs/textdocs/outdated/PROJECTS
+++ /dev/null
@@ -1,88 +0,0 @@
- Samba Projects Directory
- ========================
-
-
->>>>> NOTE: THIS FILE IS NOW VERY OUT OF DATE <<<<<
-
-
-This is a list of who's working on what in Samba. It's not guaranteed
-to be uptodate or accurate but I hope it will help us getting
-coordinated.
-
-If you are working on something to do with Samba and you aren't here
-then please let me know! Also, if you are listed below and you have
-any corrections or updates then please let me know.
-
-Email contact:
-samba-bugs@samba.org
-
-========================================================================
-Documentation and FAQ
-
-Docs and FAQ files for the Samba suite of software.
-
-Contact samba-bugs@samba.org with the diffs. These are urgently
-required.
-
-The FAQ is being added to on an ad hoc basis, see the web pages for info.
-
-Mark Preston was working on a set of formatted docs for Samba. Is this
-still happening? Contact mpreston@sghms.ac.uk
-
-Status last updated 2nd October 1996
-========================================================================
-
-========================================================================
-Netbeui support
-
-This aimed to produce patches so that Samba can be used with clients
-that do not have TCP/IP. It will try to remain as portable as possible.
-Contact Brian.Onn@Canada.Sun.COM (Brian Onn) Unfortunately it died, and
-although a lot of people have expressed interest nobody has come forward
-to do it. The Novell port (see Samba web pages) includes NetBEUI
-functionality in a proprietrary library which should still be helpful as
-we have the interfaces. Alan Cox (a.cox@li.org) has the information
-required to write the state machine if someone is going to do the work.
-
-Status last updated 2nd October 1996
-========================================================================
-
-========================================================================
-Smbfs
-
-A mountable smb filesystem for Linux using the userfs userspace filesystem
-
-Contact lendecke@namu01.gwdg.de (Volker Lendecke)
-
-This works really well, and is measurably more efficient than commercial
-client software. It is now part of the Linux kernel. Long filename support
-is in use.
-
-Status last updated June 1997
-========================================================================
-
-========================================================================
-Admin Tool
-
-Aims to produce a nice smb.conf editor and other useful tools for
-administering a Samba system.
-
-Contact: Steve Brown (steve@unicorn.dungeon.com)
-
-In the design phase.
-
-Status last updated 4th September 1994
-========================================================================
-
-
-========================================================================
-Lanman Client.
-
-Contact: john@amanda.xs4all.nl (John Stewart)
-
-Aims to produce a reliable LANMAN Client implementation for LINUX,
-and possibly other variations of UNIX. Project ably started by
-Tor Lillqvist; tml@hemuli.tte.vtt.fi
-
-Status last updated 17th January 1995
-========================================================================
diff --git a/docs/textdocs/security_level.txt b/docs/textdocs/security_level.txt
deleted file mode 100644
index f4e0df7139..0000000000
--- a/docs/textdocs/security_level.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Contributor: Andrew Tridgell
-Updated: June 27, 1997
-Status: Current
-
-Subject: Description of SMB security levels.
-===========================================================================
-
-Samba supports the following options to the global smb.conf parameter
-"security =":
- share, user, server
-
-Note: Samba-2.0.0 now adds the "domain" security mode. Please refer to
-the smb.conf man page for usage information and to the document
-docs/textdocs/DOMAIN_MEMBER.txt for further background details.
-
-Of the above, "security = server" means that Samba reports to clients that
-it is running in "user mode" but actually passes off all authentication
-requests to another "user mode" server. This requires an additional
-parameter "password server =" that points to the real authentication server.
-That real authentication server can be another Samba server or can be a
-Windows NT server, the later natively capable of encrypted password support.
-
-Below is a more complete description of security levels.
-===========================================================================
-
-A SMB server tells the client at startup what "security level" it is
-running. There are two options "share level" and "user level". Which
-of these two the client receives affects the way the client then tries
-to authenticate itself. It does not directly affect (to any great
-extent) the way the Samba server does security. I know this is
-strange, but it fits in with the client/server approach of SMB. In SMB
-everything is initiated and controlled by the client, and the server
-can only tell the client what is available and whether an action is
-allowed.
-
-I'll describe user level security first, as its simpler. In user level
-security the client will send a "session setup" command directly after
-the protocol negotiation. This contains a username and password. The
-server can either accept or reject that username/password
-combination. Note that at this stage the server has no idea what
-share the client will eventually try to connect to, so it can't base
-the "accept/reject" on anything other than:
-
-- the username/password
-- the machine that the client is coming from
-
-If the server accepts the username/password then the client expects to
-be able to mount any share (using a "tree connection") without
-specifying a password. It expects that all access rights will be as
-the username/password specified in the "session setup".
-
-It is also possible for a client to send multiple "session setup"
-requests. When the server responds it gives the client a "uid" to use
-as an authentication tag for that username/password. The client can
-maintain multiple authentication contexts in this way (WinDD is an
-example of an application that does this)
-
-
-Ok, now for share level security. In share level security the client
-authenticates itself separately for each share. It will send a
-password along with each "tree connection" (share mount). It does not
-explicitly send a username with this operation. The client is
-expecting a password to be associated with each share, independent of
-the user. This means that samba has to work out what username the
-client probably wants to use. It is never explicitly sent the
-username. Some commercial SMB servers such as NT actually associate
-passwords directly with shares in share level security, but samba
-always uses the unix authentication scheme where it is a
-username/password that is authenticated, not a "share/password".
-
-Many clients send a "session setup" even if the server is in share
-level security. They normally send a valid username but no
-password. Samba records this username in a list of "possible
-usernames". When the client then does a "tree connection" it also adds
-to this list the name of the share they try to connect to (useful for
-home directories) and any users listed in the "user =" smb.conf
-line. The password is then checked in turn against these "possible
-usernames". If a match is found then the client is authenticated as
-that user.
-
-Finally "server level" security. In server level security the samba
-server reports to the client that it is in user level security. The
-client then does a "session setup" as described earlier. The samba
-server takes the username/password that the client sends and attempts
-to login to the "password server" by sending exactly the same
-username/password that it got from the client. If that server is in
-user level security and accepts the password then samba accepts the
-clients connection. This allows the samba server to use another SMB
-server as the "password server".
-
-You should also note that at the very start of all this, where the
-server tells the client what security level it is in, it also tells
-the client if it supports encryption. If it does then it supplies the
-client with a random "cryptkey". The client will then send all
-passwords in encrypted form. You have to compile samba with encryption
-enabled to support this feature, and you have to maintain a separate
-smbpasswd file with SMB style encrypted passwords. It is
-cryptographically impossible to translate from unix style encryption
-to SMB style encryption, although there are some fairly simple management
-schemes by which the two could be kept in sync.