diff options
| author | Gerald Carter <jerry@samba.org> | 2002-09-26 18:53:51 +0000 |
|---|---|---|
| committer | Gerald Carter <jerry@samba.org> | 2002-09-26 18:53:51 +0000 |
| commit | ef6f8197a3071996591f74f6d7b9d36dbcb19dc7 (patch) | |
| tree | a41e76fc0d8a93e701a10ddb3a99aa4cd91d8b82 /docs | |
| parent | d9729d81a993234db850fa733fd4591e1a5ae56e (diff) | |
| download | samba-ef6f8197a3071996591f74f6d7b9d36dbcb19dc7.tar.gz samba-ef6f8197a3071996591f74f6d7b9d36dbcb19dc7.tar.bz2 samba-ef6f8197a3071996591f74f6d7b9d36dbcb19dc7.zip | |
remove files not in HEAD
(This used to be commit 9d9f7bbf87bf9a0e003e6da482615fe040d00852)
Diffstat (limited to 'docs')
27 files changed, 0 insertions, 4897 deletions
diff --git a/docs/README.Win2kSP2 b/docs/README.Win2kSP2 deleted file mode 100644 index 49a8fbf4ae..0000000000 --- a/docs/README.Win2kSP2 +++ /dev/null @@ -1,56 +0,0 @@ -!== -!== README.Win2kSP2 -!== - -Author: Gerald (Jerry) Carter <jerry@samba.org> - -================================================================== - -There are several annoyances with Windows 2000 SP2. One of which -only appears when using a Samba server to host user profiles -to Windows 2000 SP2 clients in a Windows domain. This assumes -that Samba is a member of the domain, but the problem will -likely occur if it is not. - -In order to server profiles successfully to Windows 2000 SP2 -clients (when not operating as a PDC), Samba must have - - nt acl support = no - -added to the file share which houses the roaming profiles. -If this is not done, then the Windows 2000 SP2 client will -complain about not being able to access the profile (Access -Denied) and create multiple copies of it on disk (DOMAIN.user.001, -DOMAIN.user.002, etc...). See the smb.conf(5) man page -for more details on this option. Also note that the "nt acl support" -parameter was formally a global parameter in releases prior -to Samba 2.2.2. - -The following is a minimal profile share - - [profile] - path = /export/profile - create mask = 0600 - directory mask = 0700 - nt acl support = no - read only = no - -The reason for this bug is that the Win2k SP2 client copies -the security descriptor for the profile which contains -the Samba server's SID, and not the domain SID. The client -compares the SID for SAMBA\user and realizes it is -different that the one assigned to DOMAIN\user. Hence the reason -for the "access denied" message. - -By disabling the "nt acl support" parameter, Samba will send -the Win2k client a response to the QuerySecurityDescriptor -trans2 call which causes the client to set a default ACL -for the profile. This default ACL includes - - DOMAIN\user "Full Control" - - -NOTE : This bug does not occur when using winbind to -create accounts on the Samba host for Domain users. - - 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. diff --git a/docs/yodldocs/README-NOW b/docs/yodldocs/README-NOW deleted file mode 100644 index 592d38c135..0000000000 --- a/docs/yodldocs/README-NOW +++ /dev/null @@ -1,14 +0,0 @@ -!== -!== Notice of change of documentation format -!== - -Samba is no longer using yodl as the source markup -language for our documentation. As of release 2.2.0, -we are using DocBook V4.1 exclusively (assuming you are not -counting the ASCII files yet to be converted). - -Please see ../docbook/docbook.txt for more information -on this. - -jerry carter -SAMBA Team |