diff options
Diffstat (limited to 'docs/textdocs')
42 files changed, 5671 insertions, 1008 deletions
diff --git a/docs/textdocs/ADS-HOWTO.txt b/docs/textdocs/ADS-HOWTO.txt new file mode 100644 index 00000000000..7a066c69ecf --- /dev/null +++ b/docs/textdocs/ADS-HOWTO.txt @@ -0,0 +1,142 @@ +Samba 3.0 prealpha guide to Kerberos authentication +--------------------------------------------------- + +Andrew Tridgell +tridge@samba.org + +This is a VERY ROUGH guide to setting up the current (November 2001) +pre-alpha version of Samba 3.0 with kerberos authentication against a +Windows2000 KDC. The procedures listed here are likely to change as +the code develops. + +Pieces you need before you begin: + +- a Windows 2000 server +- the latest CVS source code for Samba. See http://cvs.samba.org/ for how to + fetch this. +- the MIT kerberos development libraries (either install from the + above sources or use a package). Under debian you need "libkrb5-dev" + and "krb5-user". The heimdal libraries will not work. +- the OpenLDAP development libraries. + +On RedHat this means you should have at least: + +krb5-workstation (for kinit) +krb5-libs (for linking with) +krb5-devel (because you are compiling from source) + +in addition to the standard development environment. + +Note that these are not standard on a RedHat install, and you may need +to get them off CD2. + +Also check that you have the latest copy of this HOWTO. It is +available from http://samba.org/ftp/tridge/kerberos/HOWTO + +Step 1: Compile Samba + + If your kerberos libraries are in a non-standard location then + remember to add the configure option --with-krb5=DIR. + + After you run configure make sure that include/config.h contains + lines like this: + + #define HAVE_KRB5 1 + #define HAVE_LDAP 1 + + If it doesn't then configure did not find your krb5 libraries or + your ldap libraries. Look in config.log to figure out why and fix + it. + + Then compile and install Samba as usual. You must use at least the + following 3 options in smb.conf: + + realm = YOUR.KERBEROS.REALM + ads server = your.kerberos.server + security = ADS + encrypt passwords = yes + + Strictly speaking, you can omit the realm name and you can use an IP + address for the ads server. In that case Samba will auto-detect these. + + You do *not* need a smbpasswd file, although it won't do any harm + and if you have one then Samba will be able to fall back to normal + password security for older clients. I expect that the above + required options will change soon when we get better active + directory integration. + + +Step 2: Setup your /etc/krb5.conf + + The minimal configuration for krb5.conf is: + + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } + + + Test your config by doing a "kinit USERNAME@REALM" and making sure that + your password is accepted by the Win2000 KDC. + + NOTE: The realm must be uppercase. + + You also must ensure that you can do a reverse DNS lookup on the IP + address of your KDC. Also, the name that this reverse lookup maps to + must either be the netbios name of the KDC (ie. the hostname with no + domain attached) or it can alternatively be the netbios name + followed by the realm. + + The easiest way to ensure you get this right is to add a /etc/hosts + entry mapping the IP address of your KDC to its netbios name. If you + don't get this right then you will get a "local error" when you try + to join the realm. + +* If all you want is kerberos support in smbclient then you can skip +* straight to step 5 now. Step 3 is only needed if you want kerberos +* support in smbd. + + +Step 3: Create the computer account + + Do a "kinit" as a user that has authority to change arbitrary + passwords on the KDC ("Administrator" is a good choice). Then as a + user that has write permission on the Samba private directory + (usually root) run: + + net ads join + + Possible errors: + - "bash: kinit: command not found": + - kinit is in the krb5-workstation RPM on RedHat systems, and is + in /usr/kerberos/bin, so it won't be in the path until + you log in again (or open a new terminal) + - "ADS support not compiled in" + - Samba must be reconfigured (remove config.cache) and + recompiled (make clean all install) after the kerberos libs + and headers are installed. + + +Step 4: Test your server setup + + On a Windows 2000 client try "net use * \\server\share". You should + be logged in with kerberos without needing to know a password. If + this fails then run "klist tickets". Did you get a ticket for the + server? Does it have an encoding type of DES-CBC-MD5 ? + +Step 5: Testing with smbclient + + On your Samba server try to login to a Win2000 server or your Samba + server using smbclient and kerberos. Use smbclient as usual, but + specify the -k option to choose kerberos authentication. + + +-------- + +NOTES: + - must change administrator password at least once after DC install, + to create the right encoding types + + - w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in + their defaults DNS setup. Maybe fixed in service packs? + diff --git a/docs/textdocs/Application_Serving.txt b/docs/textdocs/Application_Serving.txt new file mode 100644 index 00000000000..6a61a99d7e0 --- /dev/null +++ b/docs/textdocs/Application_Serving.txt @@ -0,0 +1,56 @@ +Contributed: January 7, 1997 +Updated: March 24, 1998 +Contributor: John H Terpstra <samba@samba.org> + Copyright (C) 1997 - John H Terpstra +Status: Current + +Subject: Using a Samba share as an administrative share for MS Office, etc. +============================================================================== + +Problem: +======== +Microsoft Office products can be installed as an administrative installation +from which the application can either be run off the administratively installed +product that resides on a shared resource, or from which that product can be +installed onto workstation clients. + +The general mechanism for implementing an adminstrative installation involves +running: + X:\setup /A, where X is the drive letter of either CDROM or floppy + +This installation process will NOT install the product for use per se, but +rather results in unpacking of the compressed distribution files into a target +shared folder. For this process you need write privilidge to the share and it +is desirable to enable file locking and share mode operation during this +process. + +Subsequent installation of MS Office from this share will FAIL unless certain +precautions are taken. This failure will be caused by share mode operation +which will prevent the MS Office installation process from re-opening various +dynamic link library files and will cause sporadic file not found problems. + +Solution: +========= +1. As soon as the administrative installation (unpacking) has completed + set the following parameters on the share containing it: + [MSOP95] + path = /where_you_put_it + comment = Your comment + volume = "The_CD_ROM_Label" + read only = yes + available = yes + share modes = no + locking = no + browseable = yes + public = yes + +2. Now you are ready to run the setup program from the Microsoft Windows +workstation as follows:- + \\"Server_Name"\MSOP95\msoffice\setup + +MS Office Sharing - Please note: +================================ + +Workgroup Templates should be stored on an ordinary writable or read-only share +but USER templates MUST be stored on a writable share _OR_ on the users' local +machine. diff --git a/docs/textdocs/BROWSING-Config.txt b/docs/textdocs/BROWSING-Config.txt new file mode 100644 index 00000000000..ba0f399f48d --- /dev/null +++ b/docs/textdocs/BROWSING-Config.txt @@ -0,0 +1,215 @@ +Date: July 5, 1998 +Contributor: John H Terpstra <jht@samba.org> + +Subject: Cross Subnet Browsing / Cross Workgroup Browsing +=============================================================================== + +OVERVIEW: +========= + +This document should be read in conjunction with BROWSING.txt and may +be taken as the fast track guide to implementing browsing across subnets +and / or across workgroups (or domains). WINS is the best tool for resolution +of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling +except by way of name to address mapping. + + +DISCUSSION: +=========== + +Firstly, all MS Windows networking is based on SMB (Server Message +Block) based messaging. SMB messaging is implemented using NetBIOS. Samba +implements NetBIOS by encapsulating it over TCP/IP. MS Windows products can +do likewise. NetBIOS based networking uses broadcast messaging to affect +browse list management. When running NetBIOS over TCP/IP this uses UDP +based messaging. UDP messages can be broadcast or unicast. + +Normally, only unicast UDP messaging can be forwarded by routers. The +"remote announce" parameter to smb.conf helps to project browse announcements +to remote network segments via unicast UDP. Similarly, the "remote browse sync" +parameter of smb.conf implements browse list collation using unicast UDP. + +Secondly, in those networks where Samba is the only SMB server technology +wherever possible nmbd should be configured on one (1) machine as the WINS +server. This makes it easy to manage the browsing environment. If each network +segment is configured with it's own Samba WINS server, then the only way to +get cross segment browsing to work is by using the "remote announce" and +the "remote browse sync" parameters to your smb.conf file. + +If only one WINS server is used then the use of the "remote announce" and the +"remote browse sync" parameters should NOT be necessary. + +Samba WINS does not support MS-WINS replication. This means that when setting up +Samba as a WINS server there must only be one nmbd configured as a WINS server +on the network. Some sites have used multiple Samba WINS servers for redundancy +(one server per subnet) and then used "remote browse sync" and "remote announce" +to affect browse list collation across all segments. Note that this means +clients will only resolve local names, and must be configured to use DNS to +resolve names on other subnets in order to resolve the IP addresses of the +servers they can see on other subnets. This setup is not recommended, but is +mentioned as a practical consideration (ie: an 'if all else fails' scenario). + +Lastly, take note that browse lists are a collection of unreliable broadcast +messages that are repeated at intervals of not more than 15 minutes. This means +that it will take time to establish a browse list and it can take up to 45 +minutes to stabilise, particularly across network segments. + + +A) Use of the "Remote Announce" parameter +------------------------------------------ +The "remote announce" parameter of smb.conf can be used to forcibly ensure +that all the NetBIOS names on a network get announced to a remote network. +The syntax of the "remote announce" parameter is: + + remote announce = a.b.c.d [e.f.g.h] ... +_or_ + remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ... + +where: + a.b.c.d: is either the LMB (Local Master Browser) IP address + e.f.g.h: or the broadcst address of the remote network. + ie: the LMB is at 192.168.1.10, or the address + could be given as 192.168.1.255 where the netmask + is assumed to be 24 bits (255.255.255.0). + When the remote announcement is made to the broadcast + address of the remote network every host will receive + our announcements. This is noisy and therefore + undesirable but may be necessary if we do NOT know + the IP address of the remote LMB. + + WORKGROUP: is optional and can be either our own workgroup + or that of the remote network. If you use the + workgroup name of the remote network then our + NetBIOS machine names will end up looking like + they belong to that workgroup, this may cause + name resolution problems and should be avoided. + + +B) Use of the "Remote Browse Sync" parameter +-------------------------------------------- + +The "remote browse sync" parameter of smb.conf is used to announce to +another LMB that it must synchronise it's NetBIOS name list with our +Samba LMB. It works ONLY if the Samba server that has this option is +simultaneously the LMB on it's network segment. + +The syntax of the "remote browse sync" parameter is: + + remote browse sync = a.b.c.d + +where: + a.b.c.d: is either the IP address of the remote LMB or else + is the network broadcast address of the remote segment. + + +C) Use of WINS +-------------- + +Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly +recommended. Every NetBIOS machine registers it's name together with a +name_type value for each of of several types of service it has available. +eg: It registers it's name directly as a unique (the type 0x03) name. +It also registers it's name if it is running the lanmanager compatible +server service (used to make shares and printers available to other users) +by registering the server (the type 0x20) name. + +All NetBIOS names are up to 15 characters in length. The name_type variable +is added to the end of the name - thus creating a 16 character name. Any +name that is shorter than 15 characters is padded with spaces to the 15th +character. ie: All NetBIOS names are 16 characters long (including the +name_type information). + +WINS can store these 16 character names as they get registered. A client +that wants to log onto the network can ask the WINS server for a list +of all names that have registered the NetLogon service name_type. This saves +broadcast traffic and greatly expedites logon processing. Since broadcast +name resolution can not be used across network segments this type of +information can only be provided via WINS _or_ via statically configured +"lmhosts" files that must reside on all clients in the absence of WINS. + +WINS also serves the purpose of forcing browse list synchronisation by all +LMB's. LMB's must synchronise their browse list with the DMB (domain master +browser) and WINS helps the LMB to identify it's DMB. By definition this +will work only within a single workgroup. Note that the domain master browser +has NOTHING to do with what is referred to as an MS Windows NT Domain. The +later is a reference to a security environment while the DMB refers to the +master controller for browse list information only. + +Use of WINS will work correctly only if EVERY client TCP/IP protocol stack +has been configured to use the WINS server/s. Any client that has not been +configured to use the WINS server will continue to use only broadcast based +name registration so that WINS may NEVER get to know about it. In any case, +machines that have not registered with a WINS server will fail name to address +lookup attempts by other clients and will therefore cause workstation access +errors. + +To configure Samba as a WINS server just add "wins support = yes" to the +smb.conf file [globals] section. + +To configure Samba to register with a WINS server just add +"wins server = a.b.c.d" to your smb.conf file [globals] section. + +DO NOT EVER use both "wins support = yes" together with "wins server = a.b.c.d" +particularly not using it's own IP address. + + +D) Do NOT use more than one (1) protocol on MS Windows machines +--------------------------------------------------------------- + +A very common cause of browsing problems results from installing more than +one protocol on an MS Windows machine. + +Every NetBIOS machine take part in a process of electing the LMB (and DMB) +every 15 minutes. A set of election criteria is used to determine the order +of precidence for winning this election process. A machine running Samba or +Windows NT will be biased so that the most suitable machine will predictably +win and thus retain it's role. + +The election process is "fought out" so to speak over every NetBIOS network +interface. In the case of a Windows 9x machine that has both TCP/IP and IPX +installed and has NetBIOS enabled over both protocols the election will be +decided over both protocols. As often happens, if the Windows 9x machine is +the only one with both protocols then the LMB may be won on the NetBIOS +interface over the IPX protocol. Samba will then lose the LMB role as Windows +9x will insist it knows who the LMB is. Samba will then cease to function +as an LMB and thus browse list operation on all TCP/IP only machines will +fail. + +The safest rule of all to follow it this - USE ONLY ONE PROTOCOL! + + +E) Name Resolution Order +======================== + +Resolution of NetBIOS names to IP addresses can take place using a number +of methods. The only ones that can provide NetBIOS name_type information +are: + WINS: the best tool! + LMHOSTS: is static and hard to maintain. + Broadcast: uses UDP and can not resolve names across + remote segments. + +Alternative means of name resolution includes: + /etc/hosts: is static, hard to maintain, and lacks name_type info. + DNS: is a good choice but lacks essential name_type info. + +Many sites want to restrict DNS lookups and want to avoid broadcast name +resolution traffic. The "name resolve order" parameter is of great help here. +The syntax of the "name resolve order" parameter is: + + name resolve order = wins lmhosts bcast host +_or_ + name resolve order = wins lmhosts (eliminates bcast and host) + +the default is: + name resolve order = host lmhost wins bcast + +where: + "host" refers the the native methods used by the Unix system + to implement the gethostbyname() function call. This is normally + controlled by: + /etc/host.conf + /etc/nsswitch.conf + /etc/resolv.conf + +=============================================================================== diff --git a/docs/textdocs/BROWSING.txt b/docs/textdocs/BROWSING.txt index 8a09d2274fb..2ca41e5624e 100644 --- a/docs/textdocs/BROWSING.txt +++ b/docs/textdocs/BROWSING.txt @@ -1,145 +1,559 @@ -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)). +Author/s: Many (Thanks to Luke, Jeremy, Andrew, etc.) +Updated: July 5, 1998 +Status: Current - For VERY Advanced Users ONLY -Samba can act as a browse master for a workgroup, but currently cannot -act as a domain controller. The ability to be a domain controller will -be added in a later version. +Summary: This describes how to configure Samba for improved browsing. +===================================================================== -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. +OVERVIEW: +========= -The -G option is most useful for simple setups where Samba is browsable -in only one workgroup. In more complex cases the lmhosts file is -better. +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. -Be very careful setting up your lmhosts file. An incorrectly setup -lmhosts file can have disasterous results for your net! +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. -A simple lmhosts file might be: +===================================================================== -# This is a simple lmhosts file -# -# This is a host alias. Anyone querying this name -# will get the specified IP -192.0.2.17 SMBDATA -# -# first put ourselves in workgroup MYGROUP using -# our own net address -0.0.0.0 MYGROUP G +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]. -Note in the above that I overrode what workgroup Samba is in using the -G flag. Also note that the 0.0.0.0 address is used, which will be -automatically replaced with the broadcast address for groups, and with -the local IP address for other entries. +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. - -This works by the lmhosts file specifying a broadcast address on the -other network to use to find a browse master for the workgroup. +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. -For example if you wanted yourself to appear in the workgroup STAFF on -the network which has a broadcast of 192.0.3.255 then this entry would -do the trick: - -# put ourselves in the STAFF workgroup on the other subnet -192.0.3.255 STAFF G - -Notice the G at the end! It is very important you include this as this -entry without the G could cause a broadcast storm! - -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. +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$ +"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 +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 +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 -addess, so in most cases these aren't needed. +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 -B, -N and -I -options to nmbd). +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 +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 +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 33 +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 +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 +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. +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 from other subnets and then contact them to -synchronise browse lists. +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. +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. -NOTIFYING THE DOMAIN CONTROLLER -=============================== +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. -If you have a domain controller for the domain which Samba is a part -of then you should add the line "domain controller = address" to -smb.conf. "address" can either be a name available via DNS or a IP -address or a broadcast address. If it is a broadcast address then -Samba will look for a domain controller on that network. +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. -When Samba is the master browser it will regularly contact the domain -controller to synchronise browse lists. +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 +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. -You have a few options: - -1) change to a 1's broadcast on your unix server. These often end in -.255 (check with your local network guru for details) -2) set the nmbd broadcast to a 1's based address on the command line using -the -B option. This only works if your network setup listens on both -0s and 1s based broadcasts. The -B option can only control what -address it sends to, not what it listens on. +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 index e0fd6951477..247998c6c7a 100644 --- a/docs/textdocs/BUGS.txt +++ b/docs/textdocs/BUGS.txt @@ -1,31 +1,31 @@ -This file describes how to report Samba bugs. +Contributor: Samba Team +Updated: June 27, 1997 ->> The email address for bug reports is samba-bugs@anu.edu.au << - -(NOTE: This mail may not be in place yet. If you have troubles with it -then use samba-bugs@arvidsjaur.anu.edu.au) +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 I -may be changing the bug reporting mechanism sometime soon. +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. I only develop Samba in my spare time and I receive far more mail -about it than I can possibly answer, so you have a much higher chance -of an answer and a fix if you send me a "developer friendly" bug -report that lets me fix it fast. +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 that I will read it. I do read all postings to the samba -mailing list (see the README). 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) 1900 other users on +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://lake.canberra.edu.au/pub/samba/ +at http://samba.org/samba/ GENERAL INFO @@ -36,6 +36,8 @@ 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. @@ -54,6 +56,7 @@ 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 @@ -63,6 +66,15 @@ 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 --------------- @@ -115,7 +127,7 @@ where it occurred. PATCHES ------- -The best sort of bug report is one that includes a fix! If you send me +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 diff --git a/docs/textdocs/DHCP-Server-Configuration.txt b/docs/textdocs/DHCP-Server-Configuration.txt new file mode 100644 index 00000000000..499706955fb --- /dev/null +++ b/docs/textdocs/DHCP-Server-Configuration.txt @@ -0,0 +1,240 @@ +Subject: DHCP Server Configuration for SMB Clients +Date: March 1, 1998 +Updated: May 15, 2001 +Contributor: John H Terpstra <jht@samba.org> +Support: This is an unsupported document. Refer to documentation that is + supplied with the ISC DHCP Server. Do NOT email the contributor + for ANY assistance. +=============================================================================== + +Background: +=========== + +We wish to help those folks who wish to use the ISC DHCP Server and provide +sample configuration settings. Most operating systems today come ship with +the ISC DHCP Server. ISC DHCP is available from: + ftp://ftp.isc.org/isc/dhcp + +Incorrect configuration of MS Windows clients (Windows9X, Windows ME, Windows +NT/2000) will lead to problems with browsing and with general network +operation. Windows 9X/ME users often report problems where the TCP/IP and related +network settings will inadvertantly become reset at machine start-up resulting +in loss of configuration settings. This results in increased maintenance +overheads as well as serious user frustration. + +In recent times users on one mailing list incorrectly attributed the cause of +network operating problems to incorrect configuration of Samba. + +One user insisted that the only way to provent Windows95 from periodically +performing a full system reset and hardware detection process on start-up was +to install the NetBEUI protocol in addition to TCP/IP. This assertion is not +correct. + +In the first place, there is NO need for NetBEUI. All Microsoft Windows clients +natively run NetBIOS over TCP/IP, and that is the only protocol that is +recognised by Samba. Installation of NetBEUI and/or NetBIOS over IPX will +cause problems with browse list operation on most networks. Even Windows NT +networks experience these problems when incorrectly configured Windows95 +systems share the same name space. It is important that only those protocols +that are strictly needed for site specific reasons should EVER be installed. + +Secondly, and totally against common opinion, DHCP is NOT an evil design but is +an extension of the BOOTP protocol that has been in use in Unix environments +for many years without any of the melt-down problems that some sensationalists +would have us believe can be experienced with DHCP. In fact, DHCP in covered by +rfc1541 and is a very safe method of keeping an MS Windows desktop environment +under control and for ensuring stable network operation. + +Please note that MS Windows systems as of MS Windows NT 3.1 and MS Windows 95 +store all network configuration settings a registry. There are a few reports +from MS Windows network administrators that warrant mention here. It would appear +that when one sets certain MS TCP/IP protocol settings (either directly or via +DHCP) that these do get written to the registry. Even though a subsequent +change of setting may occur the old value may persist in the registry. This +has been known to create serious networking problems. + +An example of this occurs when a manual TCP/IP environment is configured to +include a NetBIOS Scope. In this event, when the administrator then changes the +configuration of the MS TCP/IP protocol stack, without first deleting the +current settings, by simply checking the box to configure the MS TCP/IP stack +via DHCP then the NetBIOS Scope that is still persistent in the registry WILL be +applied to the resulting DHCP offered settings UNLESS the DHCP server also sets +a NetBIOS Scope. It may therefore be prudent to forcibly apply a NULL NetBIOS +Scope from your DHCP server. The can be done in the dhcpd.conf file with the +parameter: + option netbios-scope ""; + +While it is true that the Microsoft DHCP server that comes with Windows NT +Server provides only a sub-set of rfc1533 functionality this is hardly an issue +in those sites that already have a large investment and commitment to Unix +systems and technologies. The current state of the art of the DHCP Server +specification in covered in rfc2132. + +This document aims to provide enough background information so that the +majority of site can without too much hardship get the Internet Software +Consortium's (ISC) DHCP Server into operation. The key benefits of using DHCP +includes: + +1) Automated IP Address space management and maximised re-use of available IP +Addresses, + +2) Automated control of MS Windows client TCP/IP network configuration, + +3) Automatic recovery from start-up and run-time problems with Windows95. + + + +Client Configuration for SMB Networking: +======================================== +SMB network clients need to be configured so that all standard TCP/IP name to +address resolution works correctly. Once this has been achieved the SMB +environment provides additional tools and services that act as helper agents in +the translation of SMB (NetBIOS) names to their appropriate IP Addresses. One +such helper agent is the NetBIOS Name Server (NBNS) or as Microsoft called it +in their Windows NT Server implementation WINS (Windows Internet Name Server). + +A client needs to be configured so that it has a unique Machine (Computer) +Name. + +This can be done, but needs a few NT registry hacks and you need to be able to +speak UNICODE, which is of course no problem for a True Wizzard(tm) :) +Instructions on how to do this (including a small util for less capable +Wizzards) can be found at + + http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html + + +All remaining TCP/IP networking parameters can be assigned via DHCP. These include: + +a) IP Address, +b) Netmask, +c) Gateway (Router) Address, +d) DNS Domain Name, +e) DNS Server addresses, +f) WINS (NBNS) Server addresses, +g) IP Forwarding, +h) Timezone offset, +i) Node Type, +j) NetBIOS Scope + +Other assignments can be made from a DHCP server too, but the above cover the +major needs. + +Note: IF ever an entry has has been made to the NetBIOS Scope field of the +TCP/IP configuration panel on an MS Windows machine, and it has then been +committed, then that setting may become persistent. In such a c ase it is better +to configure the DHCP server with a NetBIOS Scope consisting of an empty string +(ie: A NULL scope). + + +DHCP Server Installation: +========================= +It is assumed that you will have obtained a copy of the GPL'd ISC DHCP server +source files from ftp://ftp.isc.org/isc/dhcp, it is also assumed that you have +compiled the sources and have installed the binary files. + +The following simply serves to provide sample configuration files to enable +dhcpd to operate. The sample files assume that your site is configured to use +private IP network address space using the Class B range of 172.16.1.0 - +172.16.1.255 and is using a netmask of 255.255.255.0 (ie:24 bits). It is +assumed that your router to the outside world is at 172.16.1.254 and that your +Internet Domain Name is bestnet.com.au. The IP Address range 172.16.1.100 to +172.16.1.240 has been set aside as your dynamically allocated range. In +addition, bestnet.com.au have two print servers that need to obtain settings +via BOOTP. The machine linux.bestnet.com.au has IP address 172.16.1.1 and is +you primary Samba server with WINS support enabled by adding the parameter to +the /etc/smb.conf file: [globals] wins support = yes. The dhcp lease time will +be set to 20 hours. + +Configuration Files: +==================== +Before dhcpd will run you need to install a file that speifies the +configuration settings, and another that holds the database of issued IP +addresses. On many systems these are stored in the /etc directory on the Unix +system. + +Example /etc/dhcpd.conf: +======================== +server-identifier linux.bestnet.com.au; + +subnet 172.16.1.0 netmask 255.255.255.0 { + range 172.16.1.100 172.16.1.240; + default-lease-time 72000; + max-lease-time 144000; + option subnet-mask 255.255.255.0; + option broadcast-address 172.16.1.255; + option routers 172.16.1.254; + option domain-name-servers 172.16.1.1, 172.16.1.2; + option domain-name "bestnet.com.au"; + option time-offset 39600; + option ip-forwarding off; + option netbios-name-servers 172.16.0.1, 172.16.0.1; + option netbios-dd-server 172.16.0.1; + option netbios-node-type 8; + option netbios-scope ""; +} + +; Note: The above netbios-scope is purposely an empty (NULL) string. + +group { + next-server 172.16.1.10; + option subnet-mask 255.255.255.0; + option domain-name "bestnet.com.au"; + option domain-name-servers 172.16.1.1, 172.16.0.2; + option netbios-name-servers 172.16.0.1, 172.16.0.1; + option netbios-dd-server 172.16.0.1; + option netbios-node-type 8; + option netbios-scope "SomeCrazyScope"; + option routers 172.16.1.240; + option time-offset 39600; + host lexmark1 { + hardware ethernet 06:07:08:09:0a:0b; + fixed-address 172.16.1.245; + } + host epson4 { + hardware ethernet 01:02:03:04:05:06; + fixed-address 172.16.1.242; + } +} + + +Creating the /etc/dhcpd.leases file: +==================================== +At a Unix shell create an empty dhcpd.leases file in the /etc directory. +You can do this by typing: cp /dev/null /etc/dhcpd.leases + + +Setting up a route table for all-ones addresses: +================================================ +Quoting from the README file that comes with the ISC DHCPD Server: + + BROADCAST + +In order for dhcpd to work correctly with picky DHCP clients (e.g., +Windows 95), it must be able to send packets with an IP destination +address of 255.255.255.255. Unfortunately, Linux insists on changing +255.255.255.255 into the local subnet broadcast address (here, that's +192.5.5.223). This results in a DHCP protocol violation, and while +many DHCP clients don't notice the problem, some (e.g., all Microsoft +DHCP clients) do. Clients that have this problem will appear not to +see DHCPOFFER messages from the server. + +It is possible to work around this problem on some versions of Linux +by creating a host route from your network interface address to +255.255.255.255. The command you need to use to do this on Linux +varies from version to version. The easiest version is: + + route add -host 255.255.255.255 dev eth0 + +On some older Linux systems, you will get an error if you try to do +this. On those systems, try adding the following entry to your +/etc/hosts file: + +255.255.255.255 all-ones + +Then, try: + + route add -host all-ones dev eth0 + + +For more information please refer to the ISC DHCPD Server documentation. diff --git a/docs/textdocs/DIAGNOSIS.txt b/docs/textdocs/DIAGNOSIS.txt index 6681bdc4bcb..2816610a9cb 100644 --- a/docs/textdocs/DIAGNOSIS.txt +++ b/docs/textdocs/DIAGNOSIS.txt @@ -1,5 +1,8 @@ -DIAGNOSING YOUR SAMBA SERVER -============================ +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 @@ -10,9 +13,6 @@ 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. -I would welcome additions to this set of tests. Please mail them to -samba-bugs@anu.edu.au - 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. @@ -22,11 +22,14 @@ ASSUMPTIONS ----------- In all of the tests I assume you have a Samba server called BIGSERVER -and a PC called ACLIENT. I also assume the PC is running windows for -workgroups with a recent copy of the microsoft tcp/ip stack. The -procedure is similar for other types of clients. +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 a available share in your +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: @@ -36,15 +39,28 @@ smb.conf. I will assume this share is called "tmp". You can add a read only = yes -THESE TESTS ASSUME VERSION 1.9.15 OR LATER OF THE SAMBA SUITE. SOME +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: ------- -run the command "testparm". If it reports any errors then your -smb.conf configuration file is faulty. +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: @@ -60,13 +76,18 @@ 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. +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 -U%" on the unix box. You +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 @@ -76,26 +97,57 @@ 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 could -not be run. If you installed it in inetd.conf then you probably edited +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 +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 for syntax errors with "testparm". +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 +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 yu run it from there, or that the daemon is running and listening +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 @@ -103,6 +155,7 @@ 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: ------- @@ -110,14 +163,16 @@ 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. Note that you probably won't get a "node -status response" from the PC due to a bug in the microsoft netbios -nameserver implementation (it responds to the wrong port number). +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 '*'" +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 @@ -128,33 +183,29 @@ 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 with the -B -option which allows you to manually specify the broadcast address, -overriding the automatic detection. You should try different broadcast -addresses until your find the one that works. It will most likely be -something like a.b.c.255 as microsoft tcpip stacks only listen on 1's -based broadcast addresses. If you get stuck then ask your local -networking guru for help (and show them this paragraph). - -If you find you do need the -B option (ie. the automatic detection -doesn't work) then you should add the -B option with the right -broadcast address for your network to the command line of nmbd in -inetd.conf or in the script you use to start nmbd as a daemon. Once -you do this go back to the "nmblookup __SAMBA__ -B BIGSERVER" test to -make sure you have it running properly. +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 +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 command -line. +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 @@ -168,6 +219,8 @@ compile in support for them in smbd - 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 @@ -199,11 +252,22 @@ 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 +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 @@ -215,23 +279,43 @@ 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 the Makefile). You should be able to double click on the -name of the server and get a list of shares. If you get a "invalid +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. +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. +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/DOMAIN.txt b/docs/textdocs/DOMAIN.txt deleted file mode 100644 index 31e19675fae..00000000000 --- a/docs/textdocs/DOMAIN.txt +++ /dev/null @@ -1,68 +0,0 @@ -Samba now supports domain logons and network logon scripts. The -support is still experimental, but it seems to work. - -The support is also not complete. Samba does not yet support the -sharing of the SAM database with other systems yet, or remote -administration. Support for these kind of things should be added -sometime in the future. - -The domain support only works for WfWg and Win95 clients. Support for -NT and OS/2 clients is still being worked on. - -Using these features you can make your clients verify their logon via -the Samba server and make clients run a batch file when they logon to -the network. The latter is particularly useful. - -To use domain logons you need to do the following: - -1) Setup nmbd and smbd and configure the smb.conf so that Samba is -acting as the master browser. See INSTALL.txt and BROWSING.txt for -details. - -2) create a share called [netlogon] in your smb.conf. This share should -be readable by all users, and probably should not be writeable. This -share will hold your network logon scripts. - -For example I have used: - - [netlogon] - path = /data/dos/netlogon - writeable = no - guest ok = yes - - -3) in the [global] section of smb.conf set the following: - - domain logons = yes - logon script = %U.bat - -the choice of batch file is, of course, up to you. The above would -give each user a separate batch file as the %U will be changed to -their username automatically. The other standard % macros may also be -used. You can make the btch files come from a subdirectory by using -soemthing like: - - logon script = scripts\%U.bat - -4) create the batch files to be run when the user logs in. If the batch -file doesn't exist then no batch file will be run. - -In the batch files you need to be careful to use DOS style cr/lf line -endings. If you don't then DOS may get confused. I suggest you use a -DOS editor to remotely edit the files if you don't know how to produce -DOS style files under unix. - -5) Use smbclient with the -U option for some users to make sure that -the \\server\NETLOGON share is available, the batch files are visible -and they are readable by the users. - -6) you will probabaly find that your clients automatically mount the -\\SERVER\NETLOGON share as drive z: while logging in. You can put some -useful programs there to execute from the batch files. - - -NOTE: You must be using "security = user" or "security = server" for -domain logons to work correctly. Share level security won't work -correctly. - - diff --git a/docs/textdocs/ENCRYPTION.txt b/docs/textdocs/ENCRYPTION.txt deleted file mode 100644 index 046b473e9a1..00000000000 --- a/docs/textdocs/ENCRYPTION.txt +++ /dev/null @@ -1,333 +0,0 @@ - LanManager / Samba Password Encryption. - --------------------------------------- - -With the development of LanManager compatible password encryption for -Samba, it is now able to validate user connections in exactly the same -way as a LanManager or Windows NT server. - -This document describes how the SMB password encryption algorithm -works and what issues there are in choosing whether you want to use -it. You should read it carefully, especially the part about security -and the "PROS and CONS" section. - -How does it work ? ------------------- - - LanManager encryption is somewhat similar to UNIX password -encryption. The server uses a file containing a hashed value of a -users password. This is created by taking the users paintext -password, capitalising it, and either truncating to 14 bytes (or -padding to 14 bytes with null bytes). This 14 byte value is used as -two 56 bit DES keys to encrypt a 'magic' eight byte value, forming a -16 byte value which is stored by the server and client. Let this value -be known as the *hashed password*. - -When a client (LanManager, Windows for WorkGroups, Windows 95 or -Windows NT) wishes to mount a Samba drive (or use a Samba resource) it -first requests a connection and negotiates the protocol that the client -and server will use. In the reply to this request the Samba server -generates and appends an 8 byte, random value - this is stored in the -Samba server after the reply is sent and is known as the *challenge*. - -The challenge is different for every client connection. - -The client then uses the hashed password (16 byte value described -above), appended with 5 null bytes, as three 56 bit DES keys, each of -which is used to encrypt the challenge 8 byte value, forming a 24 byte -value known as the *response*. - -In the SMB call SMBsessionsetupX (when user level security is -selected) or the call SMBtconX (when share level security is selected) -the 24 byte response is returned by the client to the Samba server. - -The Samba server then reproduces the above calculation, using it's own -stored value of the 16 byte hashed password (read from the smbpasswd -file - described later) and the challenge value that it kept from the -negotiate protocol reply. It then checks to see if the 24 byte value it -calculates matches the 24 byte value returned to it from the client. - -If these values match exactly, then the client knew the correct -password (or the 16 byte hashed value - see security note below) and -is this allowed access. If not then the client did not know the -correct password and is denied access. - -Note that the Samba server never knows or stores the cleartext of the -users password - just the 16 byte hashed function derived from it. Also -note that the cleartext password or 16 byte hashed value are never -transmitted over the network - thus increasing security. - -IMPORTANT NOTE ABOUT SECURITY ------------------------------ - -The unix and SMB password encryption techniques seem similar on the -surface. This similarity is, however, only skin deep. The unix scheme -typically sends clear text passwords over the nextwork when logging -in. This is bad. The SMB encryption scheme never sends the cleartext -password over the network but it does store the 16 byte hashed value -on disk. This is also bad. Why? Because the 16 byte hashed value is a -"password equivalent". You cannot derive the users password from it, -but it could potentially be used in a modified client to gain access -to a server. This would require considerable technical knowledge on -behalf of the attacker but is perfectly possible. You should thus -treat the smbpasswd file as though it contained the cleartext -passwords of all your users. Its contents must be kept secret, and the -file should be protected accordingly. - -Ideally we would like a password scheme which neither requires plain -text passwords on the net or on disk. Unfortunately this is not -available as Samba is stuck with being compatible with other SMB -systems (WinNT, WfWg, Win95 etc). - - -PROS AND CONS -------------- - -There are advantages and disadvantages to both schemes. - -Advantages of SMB Encryption: ------------------------------ - -- plain text passwords are not passed across the network. Someone using -a network sniffer cannot just record passwords going to the SMB server. - -- WinNT doesn't like talking to a server that isn't using SMB -encrypted passwords. It will refuse to browse the server if the server -is also in user level security mode. It will insist on promting the -user for the password on each connection, which is very annoying. The -only things you can do to stop this is to use SMB encryption. - -Advantages of non-encrypted passwords: --------------------------------------- - -- plain text passwords are not kept on disk. - -- uses same password file as other unix services such as login and -ftp - -- you are probably already using other services (such as telnet and -ftp) which send plain text passwords over the net, so not sending them -for SMB isn't such a big deal. - -- the SMB encryption code in Samba is new and has only had limited -testing. We have tried hard to make it secure but in any new -implementation of a password scheme there is the possability of an -error. - - -The smbpasswd file. -------------------- - - In order for Samba to participate in the above protocol it must -be able to look up the 16 byte hashed value given a user name. -Unfortunately, as the UNIX password value is also a one way hash -function (ie. it is impossible to retrieve the cleartext of the users -password given the UNIX hash of it) then a separate password file -containing this 16 byte value must be kept. To minimise problems with -these two password files, getting out of sync, the UNIX /etc/passwd and -the smbpasswd file, a utility, mksmbpasswd.sh, is provided to generate -a smbpasswd file from a UNIX /etc/passwd file. - -To generate the smbpasswd file from your /etc/passwd file use the -following command :- - -cat /etc/passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd - -If you are running on a system that uses NIS, use - -ypcat passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd - -The mksmbpasswd.sh program is found in the Samba source directory. By -default, the smbpasswd file is stored in :- - -/usr/local/samba/private/smbpasswd - -The owner of the /usr/local/samba/private directory should be set to -root, and the permissions on it should be set to :- - -r-x------ - -The command - -chmod 500 /usr/local/samba/private - -will do the trick. Likewise, the smbpasswd file inside the private -directory should be owned by root and the permissions on is should be -set to - -rw------- - -by the command :- - -chmod 600 smbpasswd. - -The format of the smbpasswd file is - -username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell - -Although only the username, uid, and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -sections are significant and are looked at in the Samba code. - -It is *VITALLY* important that there by 32 'X' characters between the -two ':' characters - the smbpasswd and Samba code will fail to validate -any entries that do not have 32 characters between ':' characters. - -When the password file is created all users have password entries -consisting of 32 'X' characters. By default this disallows any access -as this user. When a user has a password set, the 'X' characters change -to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii -representation of the 16 byte hashed value of a users password. - -To set a user to have no password (not recommended), edit the file -using vi, and replace the first 11 characters with the asci text - -NO PASSWORD - -Eg. To clear the password for user bob, his smbpasswd file entry would -look like : - -bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell - -If you are allowing users to use the smbpasswd command to set their own -passwords, you may want to give users NO PASSWORD initially so they do -not have to enter a previous password when changing to their new -password (not recommended). - -Note : This file should be protected very carefully. Anyone with -access to this file can (with enough knowledge of the protocols) gain -access to your SMB server. The file is thus more sensitive than a -normal unix /etc/passwd file. - -The smbpasswd Command. ----------------------- - - The smbpasswd command maintains the 32 byte password field in -the smbpasswd file. If you wish to make it similar to the unix passwd -or yppasswd programs, install it in /usr/local/samba/bin (or your main -Samba binary directory) and make it setuid root. - -Note that if you do not do this then the root user will have to set all -users passwords. - -To set up smbpasswd as setuid root, change to the Samba binary install -directory and then type (as root) : - -chown root smbpasswd -chmod 4555 smbpasswd - -If smbpasswd is installed as setuid root then you would use it as -follows. - -smbpasswd -Old SMB password: <type old alue here - just hit return if there is NO PASSWORD> -New SMB Password: < type new value > -Repeat New SMB Password: < re-type new value > - -If the old value does not match the current value stored for that user, -or the two new values do not match each other, then the password will -not be changed. - -If invoked by an ordinary user it will only allow the user to change -his or her own Samba password. - -If run by the root user smbpasswd may take an optional argument, -specifying the user name whose SMB password you wish to change. Note -that when run as root smbpasswd does not prompt for or check the old -password value, thus allowing root to set passwords for users who have -forgotten their passwords. - -smbpasswd is designed to work in the same way and be familiar to UNIX -users who use the passwd or yppasswd commands. - -NOTE. As smbpasswd is designed to be installed as setuid root I would -appreciate it if everyone examined the source code to look for -potential security flaws. A setuid program, if not written properly can -be an open door to a system cracker. Please help make this program -secure by reporting all problems to me (the author, Jeremy Allison). - -My email address is :- - -jra@vantive.com - -Setting up Samba to support LanManager Encryption. --------------------------------------------------- - -This is a very brief description on how to setup samba to support -password encryption. More complete instructions will probably be added -later. - -1) get and compile the libdes libraries. the source is available from -nimbus.anu.edu.au in pub/tridge/libdes/libdes.tar.92-10-13.gz - -2) enable the encryption stuff in the Samba makefile, making sure you -point it to the libdes library and include file (it needs des.h) -The entries you need to uncomment are the four lines after the comment :- - -# This is for SMB encrypted (lanman) passwords. - -Note that you may have to change the variable DES_BASE to -point at the place where you installed the DES library. - -3) compile and install samba as usual - -4) f your system can't compile the module getsmbpass.c then remove the --DSMBGETPASS define from the Makefile. - -5) enable encrypted passwords in smb.conf by adding the line -"encrypt passwords = yes" in the [global] section - -6) create the initial smbpasswd password file in the place you -specified in the Makefile. A simple way to do this based on your -existing Makefile (assuming it is in a reasonably standard format) is -like this: - -cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd - -Change ownership of private and smbpasswd to root. - -chown -R root /usr/local/samba/private - -Set the correct permissions on /usr/local/samba/private - -chmod 500 /usr/local/samba/private - -Set the correct permissions on /usr/local/samba/private/smbpasswd - -chmod 600 /usr/local/samba/private/smbpasswd - -note that the mksmbpasswd.sh script is in the samba source directory. - -If this fails then you will find that you will need entries that look -like this: - -# SMB password file. -tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh - -note that the uid and username fields must be right. Also, you must get -the number of X's right (there should be 32). - -If you wish, install the smbpasswd program as suid root. - -chown root /usr/local/samba/bin/smbpasswd -chmod 4555 /usr/local/samba/bin/smbpasswd - -7) set the passwords for users using the smbpasswd command. For -example, as root you could do "smbpasswd tridge" - -8) try it out! - -Note that you can test things using smbclient, as it also now supports -encryption. - -NOTE TO USA Sites that Mirror Samba ------------------------------------ - -The DES library is considered a munition in the USA. Under US Law it is -illegal to export this software, or to put it in a freely available ftp -site. - -Please do not mirror the DES directory from the site on nimbus.anu.edu.au - -Thank you, - -Jeremy Allison. - diff --git a/docs/textdocs/Faxing.txt b/docs/textdocs/Faxing.txt new file mode 100644 index 00000000000..0703d75cc35 --- /dev/null +++ b/docs/textdocs/Faxing.txt @@ -0,0 +1,220 @@ +Contributor: Gerhard Zuber <zuber@berlin.snafu.de> +Date: August 5th 1997. +Status: Current + +Subject: F A X I N G with S A M B A +========================================================================== + +This text describes how to turn your SAMBA-server into a fax-server +for any environment, especially for Windows. + Author: Gerhard Zuber <zuber@berlin.snafu.de> + Version: 1.4 + Date: 04. Aug. 1997 + +Requirements: + UNIX box (Linux preferred) with SAMBA and a faxmodem + ghostscript package + mgetty+sendfax package + pbm package (portable bitmap tools) + +FTP sites: + sunsite.unc.edu:/pub/Linux/system/Serial/mgetty+sendfax* + tsx-11.mit.edu:/pub/linux/sources/sbin/mgetty+sendfax + ftp.leo.org:/pub/comp/networking/communication/modem/mgetty/mgetty1.1.6-May05.tar.gz + + pbm10dec91.tgz + ftp.leo.org:/pub/comp/networking/communication/modem/mgetty/pbm10dec91.tgz + sunsite.unc.edu: ..../apps/graphics/convert/pbmplus-10dec91-bin.tar.gz + ftp.gwdg.de/pub/linux/grafik/pbmplus.src.tar.Z (this is 10dec91 source) + or ??? pbm10dec91.tgz pbmplus10dec91.tgz + + +making mgetty+sendfax running: +============================== + + go to source tree: /usr/src/mgetty+sendfax + cp policy.h-dist policy.h + + change your settings: valid tty ports, modem initstring, Station-Id + +#define MODEM_INIT_STRING "AT &F S0=0 &D3 &K3 &C1\\\\N2" + +#define FAX_STATION_ID "49 30 12345678" + +#define FAX_MODEM_TTYS "ttyS1:ttyS2:ttyS3" + + Modem initstring is for rockwell based modems + if you want to use mgetty+sendfax as PPP-dialin-server, + define AUTO_PPP in Makefile: + +CFLAGS=-O2 -Wall -pipe -DAUTO_PPP + + compile it and install the package. + edit your /etc/inittab and let mgetty running on your preferred + ports: + +s3:45:respawn:/usr/local/sbin/mgetty ttyS2 vt100 + + now issue a + kill -HUP 1 + and enjoy with the lightning LEDs on your modem + your now are ready to receive faxes ! + + + if you want a PPP dialin-server, edit + /usr/local/etc/mgetty+sendfax/login.config + +/AutoPPP/ - ppp /usr/sbin/pppd auth debug passive modem + + + Note: this package automatically decides between a fax call and + a modem call. In case of modem call you get a login prompt ! + +Tools for printing faxes: +========================= + + your incomed faxes are in: + /var/spool/fax/incoming + + print it with: + + for i in * + do + g3cat $i | g3tolj | lpr -P hp + done + + in case of low resolution use instead: + + g3cat $i | g3tolj -aspect 2 | lpr -P hp + + + g3cat is in the tools-section, g3tolj is in the contrib-section + for printing to HP lasers. + + If you want to produce files for displaying and printing with Windows, use + some tools from the pbm-package like follow + + g3cat $i | g3topbm - | ppmtopcx - >$i.pcx + + and view it with your favourite Windows tool (maybe paintbrush) + + +Now making the fax-server: +=========================== + + fetch the file + mgetty+sendfax/frontends/winword/faxfilter + + and place it in + + /usr/local/etc/mgetty+sendfax/ + + prepare your faxspool file as mentioned in this file + edit fax/faxspool.in and reinstall or change the final + /usr/local/bin/faxspool too. + + if [ "$user" = "root" -o "$user" = "fax" -o \ + "$user" = "lp" -o "$user" = "daemon" -o "$user" = "bin" ] + + find the first line and change the second. + + make sure you have pbmtext (from the pbm-package). This is + needed for creating the small header line on each page. + Notes on pbmplus: + Some peoples had problems with precompiled binaries (especially + at linux) with a shared lib libgr.so.x.x. The better way is + to fetch the source and compile it. One needs only pbmtext for + generating the small line on top of each page /faxheader). Install + only the individual programs you need. If you install the full + package then install pbmplus first and then mgetty+sendfax, because + this package has some changed programs by itself (but not pbmtext). + + make sure your ghostscript is functional. You need fonts ! + I prefer these from the OS/2 disks + + prepare your faxheader + /usr/local/etc/mgetty+sendfax/faxheader + + edit your /etc/printcap file: + +# FAX +lp3|fax:\ + :lp=/dev/null:\ + :sd=/usr/spool/lp3:\ + :if=/usr/local/etc/mgetty+sendfax/faxfilter:sh:sf:mx#0:\ + :lf=/usr/spool/lp3/fax-log: + + + + + edit your /usr/local/samba/lib/smb.conf + + so you have a smb based printer named "fax" + + +The final step: +=============== + + Now you have a printer called "fax" which can be used via + TCP/IP-printing (lpd-system) or via SAMBA (windows printing). + + On every system you are able to produce postscript-files you + are ready to fax. + + On Windows 3.1 95 and NT: + + Install a printer wich produces postscript output, + e.g. apple laserwriter + + connect the "fax" to your printer + + + Now write your first fax. Use your favourite wordprocessor, + write, winword, notepad or whatever you want, and start + with the headerpage. + + Usually each fax has a header page. It carries your name, + your address, your phone/fax-number. + + It carries also the recipient, his address and his *** fax + number ***. Now here is the trick: + + Use the text: + Fax-Nr: 123456789 + as the recipients fax-number. Make sure this text does not + occur in regular text ! Make sure this text is not broken + by formatting information, e.g. format it as a single entity. + (Windows Write and Win95 Wordpad are functional, maybe newer + versions of Winword are breaking formatting information). + + The trick is that postscript output is human readable and + the faxfilter program scans the text for this pattern and + uses the found number as the fax-destination-number. + + Now print your fax through the fax-printer and it will be + queued for later transmission. Use faxrunq for sending the + queue out. + + Notes of SAMBA smb.conf: + Simply use fall through from the samba printer to the unix + printer. Sample: + + + printcap name = /etc/printcap + print command = /usr/bin/lpr -r -P %p %s + lpq command = /usr/bin/lpq -P %p + lprm command = /usr/bin/lprm -P %p %j + + +[fax] + comment = FAX (mgetty+sendfax) + path = /tmp + printable = yes + public = yes + writable = no + create mode = 0700 + browseable = yes + guest ok = no + + + diff --git a/docs/textdocs/GOTCHAS.txt b/docs/textdocs/GOTCHAS.txt new file mode 100644 index 00000000000..bc5c6dae853 --- /dev/null +++ b/docs/textdocs/GOTCHAS.txt @@ -0,0 +1,68 @@ +This file lists Gotchas to watch out for: +========================================================================= +Item Number: 1.0 +Description: Problem Detecting Interfaces +Symptom: Workstations do NOT see Samba server in Browse List +OS: RedHat - Rembrandt Beta 2 +Platform: Intel +Date: August 16, 1996 +Submitted By: John H Terpstra +Details: + By default RedHat Rembrandt-II during installation adds an + entry to /etc/hosts as follows:- + 127.0.0.1 loopback "hostname"."domainname" + + This causes Samba to loop back onto the loopback interface. + The result is that Samba fails to communicate correctly with + the world and therefor may fail to correctly negotiate who + is the master browse list holder and who is the master browser. + +Corrective Action: Delete the entry after the word loopback + in the line starting 127.0.0.1 +========================================================================= +Item Number: 2.0 +Description: Problems with MS Windows NT Server network logon service +Symptom: Loss of Domain Logon Services and failed Windows NT / 95 + logon attempts. +OS: All Unix systems with Windows NT Domain Control environments. +Platform: All +Date: February 1, 1997 +Submitted By: John H Terpstra +Details: + Samba is configured for Domain logon control in a network + where a Windows NT Domain Primary Controller is running. + + Case 1: + The Windows NT Server is shut down, then restarted. Then + the Samba server is reconfigured so that it NO LONGER offers + Domain logon services. Windows NT and 95 workstations can no + longer log onto the domain. Ouch!!! + + Case 2: + The Windows NT Server which is running the Network logon + Service is shut down and restarted while Samba is a domain + controller offering the Domain LogOn service. Windows NT + Workstation and Server can no longer log onto the network. + + Cause: + Windows NT checks at start up to see if any domain logon + controllers are already running within the domain. It finds + Samba claiming to offer the service and therefore does NOT + start its Network Logon Service. + + Windows NT needs the Windows NT network logon service to gain + from its Domain controller's SAM database the security + identifier for the user loging on. + +Work-around: Stop the Samba nmbd and smbd processes, then on the Windows + NT Primary Domain Controller start the Network Logon Service. + Now restart the Samba nmbd and smbd services. + + Better still: DO NOT CONFIGURE SAMBA AS THE NETWORK LOGON + SERVER, DO NOT SET SAMBA TO BE THE DOMAIN MASTER, DO NOT + SET SAMBA TO OS LEVEL GREATER THAN 0. + + ie: Let Windows NT Server be the Domain Logon server, the + domain master browser and do NOT interfere with any aspect + of Microsoft Windows NT Domain Control. +========================================================================= diff --git a/docs/textdocs/GROUP-MAPPING-HOWTO.txt b/docs/textdocs/GROUP-MAPPING-HOWTO.txt new file mode 100644 index 00000000000..c266f56548d --- /dev/null +++ b/docs/textdocs/GROUP-MAPPING-HOWTO.txt @@ -0,0 +1,60 @@ +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/HINTS.txt b/docs/textdocs/HINTS.txt index 953650bdd3e..877640108ce 100644 --- a/docs/textdocs/HINTS.txt +++ b/docs/textdocs/HINTS.txt @@ -1,3 +1,10 @@ +Contributor: Many +Updated: Not for a long time! + +Subject: A collection of hints +Status: May be useful information but NOT current +=============================================================================== + Here are some random hints that you may find useful. These really should be incorporated in the main docs someday. @@ -40,7 +47,10 @@ Jim barry has written an excellent drag-and-drop cr/lf converter for windows. Just drag your file onto the icon and it converts the file. Get it from -ftp://nimbus.anu.edu.au/pub/tridge/samba/contributed/fixcrlf.zip +ftp://samba.org/pub/samba/contributed/fixcrlf.zip + +The utilities unix2dos and dos2unix(in the mtools package) should do +the job under unix. ---------------------- HINT: Use the "username map" option diff --git a/docs/textdocs/INSTALL.sambatar b/docs/textdocs/INSTALL.sambatar index 388e2a3eb6f..413f54d3c65 100644 --- a/docs/textdocs/INSTALL.sambatar +++ b/docs/textdocs/INSTALL.sambatar @@ -1,3 +1,9 @@ +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. diff --git a/docs/textdocs/Imprints.txt b/docs/textdocs/Imprints.txt new file mode 100644 index 00000000000..4ea9782bd38 --- /dev/null +++ b/docs/textdocs/Imprints.txt @@ -0,0 +1,47 @@ +================================================================== + + +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 new file mode 100644 index 00000000000..dfac97e1aa2 --- /dev/null +++ b/docs/textdocs/Macintosh_Clients.txt @@ -0,0 +1,23 @@ +> 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 new file mode 100644 index 00000000000..ca0dcc84b72 --- /dev/null +++ b/docs/textdocs/NetBIOS.txt @@ -0,0 +1,152 @@ +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/PROFILES.txt b/docs/textdocs/PROFILES.txt new file mode 100644 index 00000000000..1b9cf4213e3 --- /dev/null +++ b/docs/textdocs/PROFILES.txt @@ -0,0 +1,385 @@ +Contributors: Bruce Cook <BC3-AU@bigfoot.com> + Copyright (C) 1998 Bruce Cook + + John Terpstra <samba@samba.org> + Copyright (C) 1998 John H. Terpstra + + Wolfgang Ratzka <ratzka@hrz.uni-marburg.de> + Copyright (C) 1998 Wolfgang Ratzka + +Created: April 11, 1998 +Updated: April 11, 1998 + +Subject: User Profiles +=========================================================================== + +From BC3-AU@bigfoot.com Sat Apr 11 13:36:05 1998 +Date: Sat, 11 Apr 1998 17:13:49 +1000 +From: Bruce Cook <BC3-AU@bigfoot.com> +To: Multiple recipients of list <samba-ntdom@samba.org> +Subject: RE: A question about NT Domains + +Luke Kenneth Casson Leighton writes: + > On Fri, 10 Apr 1998, Jean-Francois Micouleau wrote: + > + > > On Fri, 10 Apr 1998, Luke Kenneth Casson Leighton wrote: + > > + > > > ah, then i need to explain better. two or more users have identical + > > > profiles. say only one user installs a program which adds additional keys + > > > into the registry. those keys, as i understand it, will *not* be removed + > > > from HKEY_LOCAL_USER when subsequent users log in. + > > + > > under W95 or NT ? + > + > my experience is with Win95, but i expect the same for NT, and have been + > told that it is so by someone who runs NT admin training courses. + > + > > and why do you want to have one profile shared between multiples users ? + > + > you don't. how did you get that impression? i said multiple users with + > identical profiles, not multiple users sharing one profile. + +In my experience with both Win95 and NT, is that the HKEY_LOCAL_USER information +is stored in USER.dat or NTuser.DAT for NT. ALL of this branch is in this file +and there is no overlap between any two users (Unless you have '95 set up +to use a single common profile). + +[** lkcl: see jht's message for conditions under which an overlap can occur **] + +The HKEY_LOCAL_MACHINE branch is machine based, and shared by all users of that +machine. + + +[And now for a whole stack of caveats] + +1. User start menu paths are not stored in the registry (obviously) they're + a directory structure that located by settings in HKEY_LOCAL_USER. + + If you want start menues / desktop / favorites to be individual to a user + you must set up your user registry so these can be located individually. + The easiest tool to manage this is the policy editor. + +2. When you log onto 'Doze 95, it has to find the user registry. + + + If you have specified a common profile, a "default user" USER.DAT is used. + + If you have specified individualised profiles, then USER.DAT will be found + by the following formula: + + 1. if NET USE x: /HOME was used at startup, try for x:\USER.DAT (where + x: is any drive letter from A to Z. + if no USER.DAT is found go to step 3 + + 2. if no home is specified in a mapping, + ...\windows\profiles\username\USER.DAT is used. If no USER.DAT exists + go to step 3. + + 3. If neither of the previous two found a USER.DAT, then it will use + a prototype USER.DAT which it will later save to the above specified + path when the user logs out. + + The interesting thing here is that the prototype USER.DAT used here + is actually a copy of the last USER.DAT used on this machine. (This + may be the effect that the original poster is seeing) + + 4. As discussed above the start menu and desktop are specified in the + registry contained within USER.DAT. When a new USER.DAT is created + from a prototype, new directories are created for the start menu and + desktop ACCORDING TO HOW THE COPIED PROTOTYPE DEFINES THEM. + + So if the prototype USER.DAT says that start menu is in H:\Start Menu + but programs folder is C:\windows\start menu\programs, then the + H:\start menu will be created, and the existing machine programs + folder used. + + This means that is is important when creating roving profiles to get + your prototype USER.DAT and general user directory structure set up + exactly as you want it, and then make a copy of it that you know will + be safe from modification. When creating a new user you then copy + this prototype into the new user area, so that the new user doesn't + just inherit what the previous user had. + + +3. When you log onto 'Doze NT, it has to find the user registry. + + + NT is easier to see what's going on, but follows much the same rules as + '95. The big difference being that 'NT gets its profile location from + the login server when it's logged in. (On an NT system have a look at user + manager/user/profile - you will see that you can specify the user profile + path) Under NT3.51 this profile path was a path to NTuser.DAT, on 4.0 this + seems to be a path to a directory structure (haven't played with many NT4 + servers) + + I'm not sure how this works in samba, as I haven't yet tried the NT_DOM stuff + yet (Luke: I assume you have a keyword for this?) + +[lkcl: nt workstations should look in exactly the same places for things on + samba or other SMB servers as they do on an NT server, as long as that + SMB server looks like NT. if anyone finds that something fails, alert + us on samba@samba.org and we'll look into it]. + + When an NT system find a user without a NTuser.DAT, it copies from a + prototype that it stores especially for this purpose, so while unlike '95 + the user doesn't get whatever happened last on the machine, the user will + get a fairly minimalist configuration. + +[[jht: +When a Win95 machine logs onto a Windows NT Domain the Win95 machine looks +for the presence of a file called Config.Pol in the following location: + \\"Authenticating Server"\NETLOGON +It reads this file and uses it to ammend both the desktop environment as well +as the file %WinDir%\Profiles\%USERNAME%\User.DAT. As with Windows NT, on log +out this file gets written back to the profile server into the %USERNAME% +directory in the profile share. + +It is thus possible to share a common desktop profile between Windows NT and +Windows 9x. +:jht]] + + +4. There are a *LOT* of reasons that the 'doze machine might not find USER.DAT + and therefore default to a prototype. + + 1. Can't execute logon script & therefore no /HOME mapping (Most common) + .Make sure the script exists + .that you have your logon script set right + .Netlogon share must exist + .Protection/ownership of the script and share + + 2. no /HOME mapping in the logon script + + 3. no home path specified in /etc/smb.conf (Or no home mapping set + up for that user in NT's user manager) + + 4. Protection/ownership of the user directory + + 5. protection/ownership of USER.DAT + + 6. basic networking problems + .Is the networking available (Test it by manually mapping + to both the user share and netlogon share) + .Was the networking working during logon ? + + 7. Has it defaulted to a prototype, and then had you map the home + directory afterwards ? - This will result in the bad prototype + being written into the users home, and them being stuck with it, + (Just replace USER.DAT again) + + +5. Interesting NOTE + + When '95 is performing the logon script, the HKEY_LOCAL_USERS has + NOT been mapped from the USER.DAT. What has been mapped at this stage + is the prototype registry (last one used). + + I assume the reason for this is that '95 is waiting for the logon + script to complete so that it can identify where the user's home + directory is. + + If at this point you attempt to do anything that uses the USER registry, + (installing something for example or reading something from the user + registry) you will actually be operating on the machine stored prototype + profile not the user profile. This means that nothing will realy + happen to the user setup (No menu items, no settings etc). + + To get around this you can name a process in the "run once" entries in + the HKEY_LOCAL_MACHINE branch, and these "run once" processes will be + executed once the USER.DAT is loaded, and all the user directories are + accessible. + + +To sum up: + + NET USE H: /HOME + is the key to getting your user profiles loaded from a server. + NET USE H: \\server\homes + Won't get it right without a lot of stuffing about. + + Windoze '95 goes through a lot to bring you your user profile and + if anything goes wrong during this process, it will drop back to + using whatever profile was last used on the machine. + + +From samba@aquasoft.com.au Sat Apr 11 13:48:54 1998 +Date: Sat, 11 Apr 1998 09:34:08 +1000 +From: Samba Bugs <samba@aquasoft.com.au> +To: Multiple recipients of list <samba-ntdom@samba.org> +Subject: Re: A question about NT Domains + +Just for the sake of completeness I thought I'd add a bit to this. +Let's be clear about which files affect registry changes (or contents). + +Under NT, open a command prompt interface: +cd %SystemRoot%\System32\config +dir + +The standard registry files are: + Default - all component default settings + System - all HKLM\System entries + Software - all HKLM\Software entries + Security - Domain/Machine releated User Rights & Privs. + SAM - the Security Access Manager database (ie:Passwords etc.) + +[[jht: +The SAM and Security files are the only files that get synchronised between +Windows NT Domain Controllers. +:jht]] + +These are used by EVERYTHING!! + +When a user logs in the following files get checked: + 1) \\"Authenticating Server"\NETLOGON\NTConfig.Pol + 2) %SystemRoot%\Profiles\Policies\NTConfig.Pol + this one is a copy of the last NTConfig.Pol downloaded + from (1) above - if available. + 3) %SystemRoot%\Policies\%UserName%\NTUser.DAT + +[[jht: +The System Policy Editor on Windows NT can be used to create both the +Windows 95 "Config.Pol" file, as well as the Windows NT "NTConfig.Pol" +file. To create the Windows 95 policy file you MUST load the Windows 95 +policy template BEFORE creating the Config.Pol file. +:jht]] + +The later, is first obtained from a profile server if the User_Init_Info +passed from the Domain Logon Server specifies use of a roaming profile. +If item (3) does NOT exist and/or NO default profile is available one gets +created from the system default settings PLUS the last loaded file at item +(2) above. + +The HKCU is always unique to the currently logged in user, BUT if the +currently logged in user is using a shared profile that has NOT been made +exclusive then on logout the HKCU will be written over the top of the +source files. That is why Mandatory profiles are essential when sharing a +roaming profile. + +On Sat, 11 Apr 1998, Wolfgang Ratzka wrote: + +> Luke Kenneth Casson Leighton wrote: +> +> > my experience is with Win95, but i expect the same for NT, and have been +> > told that it is so by someone who runs NT admin training courses. +> +> On NT it is quite definitely not so. HKCU will always be loaded completely from +> the user's NTuser.dat file and unloaded again after logout. +> In fact HKCU is not a proper registry hive but a symbolic reference to the subkey of +> HKEY_USERS that corresponds to the current user. If more than one user +> is active on an NT machine (on plain vanilla NT this *is* possible if you have +> services running as a non-system user; on WinFrame or Hydra multiple users +> can be logged in) you will see several subkeys of HKU that correspond to +> the active users and don't interfere with each other. +> +> Of course some settings that a user can change do not go into the HKCU hive +> but into HKLM, most notably the screen resolution and the number of colours +> (you can use policies to prevent user's from changing these). +> Some applications put information that should go into HKCU into HKLM instead. +> (Hall of Shame: Netscape Communicator, Microsoft Office 97 [User dictionaries!]...). +> Others just use plain good old INI files in their program directory or even +> in \WINNT\SYSTEM32. Those changes will not be user specific but machine +> specific and those programs will cause trouble, when one tries to run them +> on WinFrame or Hydra... :-). +> +> Summarizing: +> +> Q: Will the next user inherit a previous user's additions +> to the HKCU registry hive? +> A: Quite definitely not. + +Correct. + +> +> Q: Can a user foul up the configuration for the next user? +> A: Quite definitely yes! + +See above. Yes, but not if correctly configured. + +> +> Q: Is this discussion out of place on the samba-ntdom list? +> A: Errr.... + +Errr... Really? I think it is. Do we, or do we not, want to help people to +gain stable and dependable use of samba? + +> -- +> Wolfgang Ratzka (dialing in from home) + +Cheers, +John H Terpstra (Also from home!!!!) + +============================================================================= +Further notes by Bruce Cook + +Date: Sun, 12 Apr 1998 14:12:22 +1000 +From: Bruce Cook <BC3-AU@bigfoot.com> +Subject: Re: Win95 / NT Profiles (was: RE: A question about NT Domains) + +Ah yes I knew there was something I forgot. +here it is for completeness. + +============================================================================= + +When a user logs into a specific machine for the first time, they will be +told that they've never logged into the machine, and would they like to +store the user setting for future use. + +If the user answers NO, they will be nagged about this every time they +log into the machine until they say YES. (How about it MS, could we +possible do something about this feature?) + +When the user answers YES, thereafter upon logging out of the machine, +a copy of the user's profile is also written onto the machines local disk +for later use. + +When a user logs into a machine where his/her profile has previously been +saved, a comparison is made between the date of the profile copy kept on +the machine, and the date of the profile stored on the server. In theory +the server date should be later or the same. + +If the local machine date is later than the server date, the client +machine will tell you the the settings on the local machine are more +recent than those of the server, and would you like to user them instead. + +This occurs for a couple of reasons: + 1. Server not available when the user logs out + 2. Date mismatch between the server and the client + (I always use NET TIME \\server /SET /YES in my logon scripts) + + +Logging in with NO server available. + +In some cases a client will want to log into a network with no server +available. (Portables away from the office, or a dead server) + +This can only happen if the administrator has NOT set the machine to +give access only upon password verification from the server. +(If the admin has done this, it can be circumvented by restarting + the machine in safe mode, and running poledit, or regedit and + disabling that feature) + +If you are able to log in while the server is unavailable, you have +two choices + 1. Log in as a user that previously stored a profile + (The password won't have to match unless the machine + is set up to store passwords) + + 2. log in as the default user (bit the cancel button or escape key) + +If you choose to use your profile stored on the local machine, there are +several things you should be wary of: + 1. the profile stored on the machine will be a copy of the last + profile used when you logged into THAT machine. You may get + quite an old profile. + 2. When you log out, that local profile is garunteed to be later + than the one on the server, and if the server is available, or + you later log into that machine when the server is available + you could overwrite the good server profile with a bogus profile. + + +Technique note: + I set portable computers up so that they don't use roaming profiles, + rather they have a single profile kept on the machine. This means + that a user has the same desktop look an feel regardless of where + they are. This follows the philosophy that laptops tend to be used + by only one person. diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt index e06876fecae..25d4c816f05 100644 --- a/docs/textdocs/Passwords.txt +++ b/docs/textdocs/Passwords.txt @@ -1,5 +1,9 @@ -NOTE ABOUT PASSWORDS -==================== +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 @@ -30,10 +34,10 @@ 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 -================= +SECURITY = SERVER or DOMAIN +=========================== -Samba can use a remote server to do it's username/password +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. diff --git a/docs/textdocs/Printing.txt b/docs/textdocs/Printing.txt new file mode 100644 index 00000000000..2c50e5f4fe6 --- /dev/null +++ b/docs/textdocs/Printing.txt @@ -0,0 +1,255 @@ +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.DCEDFS b/docs/textdocs/README.DCEDFS index f84b84bb686..da9bb2197da 100644 --- a/docs/textdocs/README.DCEDFS +++ b/docs/textdocs/README.DCEDFS @@ -1,9 +1,8 @@ -============================================================================= - - Basic DCE/DFS Support for SAMBA 1.9.13 - - Jim Doyle <doyle@oec.com> 06-02-95 +Contributor: Jim Doyle <doyle@oec.com> +Date: 06-02-95 +Status: Current but needs updating +Subject: Basic DCE/DFS Support for SAMBA 1.9.13 ============================================================================= Functionality: diff --git a/docs/textdocs/README.NOW b/docs/textdocs/README.NOW new file mode 100644 index 00000000000..1184a9d057f --- /dev/null +++ b/docs/textdocs/README.NOW @@ -0,0 +1,8 @@ +The files in the directory have either yet to +converted into SGML/DocBook format or are outdated. +To create ASCII versions of the documentation +in the ../htmldocs/ directory, run + + $ lynx -dump file.html > file.txt + + diff --git a/docs/textdocs/README.jis b/docs/textdocs/README.jis index 2ac6716a6f6..50ff0cced74 100644 --- a/docs/textdocs/README.jis +++ b/docs/textdocs/README.jis @@ -14,6 +14,10 @@ $B$rL\E*$H$7$F$$$^$9!#$=$N$?$a!"F|K\8lBP1~$O!"I,MW:G>.8B$7$+9T$J$C$F$*$j$^$;$s!#(B + $BF|K\8lBP1~$7$?(B samba $B$rMxMQ$9$k$?$a$K$O!"%3%s%Q%$%k$9$k;~$K!"I,$:!"(BKANJI $B$NDj5A$rDI(B + $B2C$7$F$/$@$5$$!#$3$N%*%W%7%g%s$r;XDj$7$F$$$J$$>l9g$O!"F|K\8l$N%U%!%$%kL>$r@5$7$/07(B + $B$&$3$H$O$G$-$^$;$s!#!J%3%s%Q%$%k$K$D$$$F$O!"2<5-(B 3. $B$r;2>H$7$F2<$5$$!K(B + 2. $BMxMQJ}K!(B (1) $BDI2C$7$?%Q%i%a!<%?(B @@ -34,6 +38,12 @@ $B$N(B16$B?J?t$rB3$1$k7A<0$K$J$j$^$9!#(B $B$3$3$G!"(B':' $B$rB>$NJ8;z$KJQ99$7$?$$>l9g$O!"(Bhex $B$N8e$m$K$=$NJ8;z$r;XDj$7$^$9!#(B $BNc$($P!"(B@$B$rJQ$o$j$K;H$$$?$$>l9g$O!"(B'hex@'$B$N$h$&$K;XDj$7$^$9!#(B + cap: 7 bits $B$N(B ASCII $B%3!<%I0J30$N%3!<%I$r0J2<$N7A<0$GI=$9J}<0$H$$$&E@$G$O(B + hex$B$HF1MM$G$9$,!"(BCAP (The Columbia AppleTalk Package)$B$H8_49@-$r;}$DJQ49(B + $BJ}<0$H$J$C$F$$$^$9!#(Bhex$B$H$N0c$$$O(B0x80$B0J>e$N%3!<%I$N$_(B':80'$B$N$h$&$KJQ49(B + $B$5$l!"$=$NB>$O(BASCII$B%3!<%I$G8=$5$l$^$9!#(B + $BNc$($P!"(B'$B%*%U%#%9(B'$B$H$$$&L>A0$O!"(B':83I:83t:83B:83X'$B$H$J$j$^$9!#(B + JIS $B%3!<%I$K$D$$$F$O!"0J2<$NI=$r;2>H$7$F2<$5$$!#(B $B(#(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(!(!(!(!(!($(B $B(";XDj(B $B("4A;z3+;O("4A;z=*N;("%+%J3+;O("%+%J=*N;("1Q?t3+;O("Hw9M(B $B("(B @@ -90,6 +100,8 @@ $B%$%kL>$O!"(BEUC $B%3!<%I$K$J$j$^$9!#$3$3$G;XDj$7$?%3!<%I7O$O!"%5!<%P5Z$S%/%i%$%"%s%H(B $B%W%m%0%i%`$N%G%U%)%k%H$KCM$J$j$^$9!#(B + $B>0!"%*%W%7%g%sCf$N(B \ $B$d(B " $B$bK:$l$:$K;XDj$7$F2<$5$$!#(B + 3. $B@)8B;v9`(B (1) $B4A;z%3!<%I(B @@ -104,21 +116,34 @@ $B$A$c$s$H$7$?%9%Z%C%/$,$h$/$o$+$i$J$+$C$?$N$G$9$,!"0l1~!"(BDOS/V $B$NF0:n$HF1$8F0:n$r9T$J(B $B$&$h$&$K$J$C$F$$$^$9!#(B +(4) $B%m%s%0%U%!%$%kL>$K$D$$$F(B + Windows NT/95 $B$G$O!"%m%s%0%U%!%$%kL>$,07$($^$9!#%m%s%0%U%!%$%kL>$r(B 8.3 $B%U%)!<%^%C%H(B + $B$G07$&$?$a$K!"(Bmangling $B$7$F$$$^$9$,!"$3$NJ}K!$O!"(BNT $B$d(B 95 $B$,9T$J$C$F$$$k(B mangling $B$H(B + $B$O0[$J$j$^$9$N$GCm0U$7$F2<$5$$!#(B + 4. $B>c32Ey$N%l%]!<%H$K$D$$$F(B $BF|K\8l$N%U%!%$%kL>$K4X$7$F!"J8;z2=$1Ey$N>c32$,$"$l$P!";d$K%l%]!<%H$7$FD:$1$l$P9,$$$G(B $B$9!#$?$@$7!"%*%j%8%J%k$+$i$NLdBjE@$d<ALd$K$D$$$F$O!"%*%j%8%J%k$N:n<T$XD>@\Ld$$9g$o$;$k(B $B$+!"$b$7$/$O%a!<%j%s%0%j%9%H$J$I$X%l%]!<%H$9$k$h$&$K$7$F2<$5$$!#(B +$B%l%]!<%H$5$l$k>l9g!"MxMQ$5$l$F$$$k4D6-(B(UNIX $B5Z$S(B PC $BB&$N(BOS$B$J$I(B)$B$H$G$-$^$7$?$i@_Dj%U%!(B +$B%$%k$d%m%0$J$I$rE:IU$7$FD:$1$k$H9,$$$G$9!#(B + 5. $B$=$NB>(B - hex $B7A<0$NJQ49J}K!$O!"(B + $B%3!<%IJQ49$O0J2<$NJ}!9$,:n$i$l$?%W%m%0%i%`$rMxMQ$7$F$$$^$9!#(B - $BBgLZ!wBgDM!&C^GH(B <ohki@gssm.otsuka.tsukuba.ac.jp>$B;a(B + hex $B7A<0(B $BBgLZ!wBgDM!&C^GH(B <ohki@gssm.otsuka.tsukuba.ac.jp>$B;a(B + cap $B7A<0(B $BI%ED(B $BF;O:(B (michiro@po.iijnet.or.jp)(michiro@dms.toppan.co.jp)$B;a(B - $B$,:n$i$l$?%3!<%I$rMxMQ$7$F$$$^$9!#(B + $B$=$NB>!"$?$/$5$s$NJ}!9$+$i$$$m$$$m$H8f65<($$$?$@$-$"$j$,$H$&$4$6$$$^$7$?!#:#8e$H$b$h(B +$B$m$7$/$*4j$$CW$7$^$9!#(B 1994$BG/(B10$B7n(B28$BF|(B $BBh#1HG(B 1995$BG/(B 8$B7n(B16$BF|(B $BBh#2HG(B +1995$BG/(B11$B7n(B24$BF|(B $BBh#3HG(B +1996$BG/(B 5$B7n(B13$BF|(B $BBh#4HG(B + $BF#ED(B $B?r(B fujita@ainix.isac.co.jp diff --git a/docs/textdocs/README.sambatar b/docs/textdocs/README.sambatar index 26829952eb6..af7250c2a49 100644 --- a/docs/textdocs/README.sambatar +++ b/docs/textdocs/README.sambatar @@ -1,3 +1,11 @@ +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 diff --git a/docs/textdocs/Recent-FAQs.txt b/docs/textdocs/Recent-FAQs.txt new file mode 100644 index 00000000000..feed1278277 --- /dev/null +++ b/docs/textdocs/Recent-FAQs.txt @@ -0,0 +1,286 @@ +Contributor: Samba-bugs@samba.org +Date: July 5, 1998 +Status: Current + +============================================================================= +Subject: Recent FAQ answers to common questions / problems +============================================================================= +Contents: NetWkstaUserLogon + Not listening for calling name + System Error 1240 + Trapdoor UID + User Access Control + Using NT to Browse Samba Shares + setup.exe and 16 bit programs + smbclient -N + +NetWkstaUserLogon +================= +FAQ answer about the new password server code: + +In 1.9.18 you can disable the NetWkstaUserLogon call at compile time +in local.h and from 1.9.18p3 you can now disable it from an option in +your smb.conf. + +The password server behaviour changed because we discovered that bugs +in some NT servers allowed anyone to login with no password if they +chose an account name that did not exist on the password server. The +NT password server was saying "yes, it's OK to login" even when the +account didn't exist at all! Adding the NetWkstaUserLogon call fixed +the problem, and follows the "recommended" method that MS have +recently documented for pass through authentication. + +The problem now is that some NT servers (in particular NT +workstation?) don't support the NetWkstaUserLogon call. The call also +doesn't work for accounts in trust relationships. + +The eventual solution for this will be to replace the password server +code in Samba with NT domain code as that is developed. For now you +have the choice of compiling Samba either with or without the +NetWkstaUserLogon call in the password server code. + +In 1.9.18p3 the following was added (copied from the 1.9.18p3 release +notes): + +In the [global] section of smb.conf : + +networkstation user login + +This code (submitted by Rob Nielsen) allows the code many people +were having problems with that queries an NT password server to +be turned off at runtime rather than compile time. Please see the +documentation in the smb.conf manual page for details. This is a +security option - it must only be turned off after checks have been +made to ensure that your NT password server does not suffer from the +bug this code was meant to protect against ! + +In 1.9.18 you can enable/disable this call in local.h. In 1.9.17p5 +you could apply the following patch. Applying this patch will make +the password server code behave like the code in earlier versions +of Samba. If you do this then please ensure that you test to see +that users are prevented from logging in if they give a bogus +username/password. You may have a NT server that is affected by the +bug that this code is designed to avoid. + + +--- password.c 1997/10/21 10:09:28 1.25.2.4 ++++ password.c 1997/12/31 06:43:06 +@@ -1619,6 +1619,7 @@ + } + + ++#if 0 + if (!cli_NetWkstaUserLogon(&cli,user,local_machine)) { + DEBUG(1,("password server %s failed NetWkstaUserLogon\n", cli.desthost)); + cli_tdis(&cli); +@@ -1638,6 +1639,7 @@ + cli_tdis(&cli); + return False; + } ++#endif + + DEBUG(3,("password server %s accepted the password\n", cli.desthost)); +=============================================================================== + +Not listening for calling name +============================== + +> Session request failed (131,129) with myname=HOBBES destname=CALVIN +> Not listening for calling name + +If you get this when talking to a Samba box then it means that your +global "hosts allow" or "hosts deny" settings are causing the Samba +server to refuse the connection. + +Look carefully at your "hosts allow" and "hosts deny" lines in the +global section of smb.conf. + +It can also be a problem with reverse DNS lookups not functioning +correctly, leading to the remote host identity not being able to +be confirmed, but that is less likely. +=============================================================================== + +System Error 1240 +================= +System error 1240 means that the client is refusing to talk +to a non-encrypting server. Microsoft changed WinNT in service +pack 3 to refuse to connect to servers that do not support +SMB password encryption. + +There are two main solutions: + +1) enable SMB password encryption in Samba. See ENCRYPTION.txt in the +Samba docs + +2) disable this new behaviour in NT. See WinNT.txt in the +Samba docs +=============================================================================== + +Trapdoor UID +============ +> Log message "you appear to have a trapdoor uid system" + +This can have several causes. It might be because you are using a uid +or gid of 65535 or -1. This is a VERY bad idea, and is a big security +hole. Check carefully in your /etc/passwd file and make sure that no +user has uid 65535 or -1. Especially check the "nobody" user, as many +broken systems are shipped with nobody setup with a uid of 65535. + +It might also mean that your OS has a trapdoor uid/gid system :-) + +This means that once a process changes effective uid from root to +another user it can't go back to root. Unfortunately Samba relies on +being able to change effective uid from root to non-root and back +again to implement its security policy. If your OS has a trapdoor uid +system this won't work, and several things in Samba may break. Less +things will break if you use user or server level security instead of +the default share level security, but you may still strike +problems. + +The problems don't give rise to any security holes, so don't panic, +but it does mean some of Samba's capabilities will be unavailable. +In particular you will not be able to connect to the Samba server as +two different uids at once. This may happen if you try to print as a +"guest" while accessing a share as a normal user. It may also affect +your ability to list the available shares as this is normally done as +the guest user. + +Complain to your OS vendor and ask them to fix their system. + +Note: the reason why 65535 is a VERY bad choice of uid and gid is that +it casts to -1 as a uid, and the setreuid() system call ignores (with +no error) uid changes to -1. This means any daemon attempting to run +as uid 65535 will actually run as root. This is not good! +=============================================================================== + +User Access Control +=================== +> In windows when i set up a share in "user mode" i get the message: +> "You cannot view the list of users at this time. Please try again later." +> +> I know you have lists of users for access and aliasing purposes, but i +> have read nothing to support the idea that these lists control the Domain +> Users List... + +Samba does NOT at this time support user mode access control for Window 9x +of for NT. This is a priority item and requires full implementation of the NT SMB +protocol calls. Samba-1.9.19 will go into alpha in about 2 months time and will +have a more full implementation of the NT SMB protocols to support Domain Client +interoperability. When we can see that this has been succesful we wil then implement +the NT SMB Server components. This will probably be released as Samba-2.0 + +Samba-1.9.18p5 is scheduled to go out within 14 days. This will close off the 1.9.18 +branch and then opens the way to progress 1.9.19. + +I hope this answers your concerns adequately. +=============================================================================== + +Using NT to Browse Samba Shares +=============================== +> WIN-NT workstations (nt4.0, service pack 3) +> samba with +> security = user +> encrypt passwords = yes +> guest account = guest +> +> start the explorer on a win-nt workstation and select network. I find +> my unix server running samba, but I can not see the list of shares +> unless I am a user, who is known in the smbpasswd of the unix machine. +> The guest account "guest" exists on my unix machine. For testing I even +> made him a regular user with a password. +> +> With my network monitor I can see, that the win-nt workstation uses the +> current login, to connect to IPC$ on the samba server +> (for example "administrator"), not the guest account. + +This is exactly how Windows NT works. You MUST have a valid account on the Windows +NT box you are trying to see the resource list on. If your currently logged in +account details do NOT match an account on the NT machine you are trying to access +then you will be presented with a logon box for that machine. When you enter the +name of an account on that machine / domain, together with a valid password then +the resource list is made available. If the account details are not correct then +no resource list is shown. + +Samba follows the behaviour of Windows NT exactly. + +Warning:Warning:Warning: +======================== +Samba can be compiled with the GUEST_SESSION_SETUP option at 0,1 or 2. +The default is 0. If this is set to 1 or 2 then Windows NT machines that DO NOT +have an account on the Samba server will see the resource list. The down side of this +is that legitimate users may then be refused access to their legitimate resources. +Setting this option creates serious security holes. DO NOT DO IT. Samba has the +value of this option set at 0 - NOT WITHOUT REASON!!!! + +******> Warning:Warning:Warning: ****> Do not tamper with this setting!!! +=============================================================================== + +setup.exe and 16 bit programs +============================= +Running 16 bit programs from Windows NT on a Samba mapped drive +--------------------------------------------------------------- + +The Windows NT redirector has a bug when running against a +Samba or Windows 95 mapped drive and attempting to run a +16 bit executable. + +The problem occurs when the pathname to a 16 bit executable +contains a non 8.3 filename complient directory component, +Windows NT will fail to load the program and complain it +cannot find the path to the program. + +It can be verified that this is a bug in Windows NT and +not Samba as the same problem can be reproduced exactly +when attempting to run the same program with the same +pathname from a Windows 95 server (ie. the problem still +exists even with no Samba server involved). + +Microsoft have been made aware of this problem, it is +unknown if they regard it as serious enough to provide +a fix for this. + +One of the reasons this problem is reported frequently +is that InstallShield setup.exe executables are frequently +written as 16 bit programs, and so hit this problem. + +As a workaround, you may create (on a Samba server at +least) a symbolic link with an 8.3 complient name to +the non 8.3 complient directory name, and then the 16 +bit program will run. Alternatively, use the 8.3 +complient mangled name to specify the path to run +the binary. + +This will be fixed when Samba adds the NT-specific +SMB calls (currently targeted for the next major +Samba release), as once the NT SMB calls are used +this problem no longer occurs (which is why the +problem doesn't occur when running against a drive +mapped to a Windows NT server). + +Regards, + + Jeremy Allison. + Samba Team. +=============================================================================== + +smbclient -N +============ +> When getting the list of shares available on a host using the command +> smbclient -N -L <server> +> the program always prompts for the password if the server is a Samba server. +> It also ignores the "-N" argument when querying some (but not all) of our +> NT servers. + +No, it does not ignore -N, it is just that your server rejected the +null password in the connection, so smbclient prompts for a password +to try again. + +To get the behaviour that you probably want use + smbclient -L host -U% + +this will set both the username and password to null, which is +an anonymous login for SMB. Using -N would only set the password +to null, and this is not accepted as an anonymous login for most +SMB servers. +=============================================================================== + diff --git a/docs/textdocs/RoutedNetworks.txt b/docs/textdocs/RoutedNetworks.txt new file mode 100644 index 00000000000..fb55f9f9bf0 --- /dev/null +++ b/docs/textdocs/RoutedNetworks.txt @@ -0,0 +1,63 @@ +#NOFNR Flag in LMHosts to Communicate Across Routers
+
+ Last reviewed: May 5, 1997
+ Article ID: Q103765
+ The information in this article applies to:
+
+ Microsoft Windows NT operating system version 3.1
+ Microsoft Windows NT Advanced Server version 3.1
+
+ SUMMARY
+
+ Some of the LAN Manager for UNIX and Pathworks servers may have
+problems in communicating across routers with
+ Windows NT workstations. The use of #NOFNR flag in the LMHosts
+file solves the problem.
+
+ MORE INFORMATION
+
+ When you are communicating with a server across a router in a IP
+routed environment, the LMHosts file is used to
+ resolve Workstation name-to-IP address mapping. The LMHosts
+entry for a remote machine name provides the IP
+ address for the remote machine. In Lan Manager 2.x, providing
+the LMHosts entry eliminates the need to do a Name
+ Query broadcast to the local domain and instead a TCP session is
+established with the remote machine. Windows NT
+ performs the same function in a different way.
+
+ When an LMHosts entry exists for a remote server, Windows NT
+will not send a Name Query broadcast to the local
+ subnet and instead send a directed Name Query to the remote
+server. If the remote server does not respond to the Name
+ Query, further communications (TCP SYN, and so on) will not take
+place. This was done to eliminate the performance
+ issues when trying to connect to a remote machine when it was
+not available (down).
+
+ Some of the older LAN Manager for UNIX and DEC Pathworks servers
+do not respond to directed Name Queries sent
+ by Windows NT. In that case, the users will see an error 53
+(Path not found), even though they have specified the
+ LMHosts entries correctly. A new LMHosts flag #NOFNR was added
+to solve this problem. By specifying the
+ #NOFNR flag on the same line where the name resolution
+information for the server is provided, the directed Name
+ Query can be avoided. For example:
+
+ 130.20.1.1 mylmxserver #PRE #NOFNR
+
+
+ Note that this will only apply to mylmxserver and not to any
+other entries in the LMHosts file. To set
+ a global flag, an entry could be added in the registry. To
+completely remove any directed Name
+ Queries sent from a Windows NT machine, create the following
+value in
+
+HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbt\Parameters:
+
+ NoDirectedFNR REG_DWORD 1
+
+
+ This will cause the directed Name Queries to not go out for any
diff --git a/docs/textdocs/SCO.txt b/docs/textdocs/SCO.txt index 1b3801471f7..7c01aa57c6c 100644 --- a/docs/textdocs/SCO.txt +++ b/docs/textdocs/SCO.txt @@ -1,4 +1,11 @@ -There is an annoying TCPIP bug in SCO Unix. This causes orruption when +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: diff --git a/docs/textdocs/SMBTAR.notes b/docs/textdocs/SMBTAR.notes index a23cbf2b325..679d776f56c 100644 --- a/docs/textdocs/SMBTAR.notes +++ b/docs/textdocs/SMBTAR.notes @@ -1,3 +1,9 @@ +Contributor: Unknown +Date: 1994 +Status: Mostly Current - refer man page + +Subject: Smbtar +============================================================================ Intro ----- @@ -37,4 +43,4 @@ newer filename 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.
\ No newline at end of file +backups. diff --git a/docs/textdocs/Solaris-Winbind-HOWTO.txt b/docs/textdocs/Solaris-Winbind-HOWTO.txt new file mode 100644 index 00000000000..a81bacf4864 --- /dev/null +++ b/docs/textdocs/Solaris-Winbind-HOWTO.txt @@ -0,0 +1,361 @@ +!== +!== Solaris-Winbind-HOWTO.txt +!== +Contributors: Naag Mummaneni <getnag@rediffmail.com> +Updated: May 2, 2002 +Status: Current + +Subject: Installing and Configuring Winbind on Solaris +============================================================================= + +Installation and Configuration of Winbind on Solaris. +----------------------------------------------------- + +This HOWTO describes how to get winbind services up and running to control +access and authenticate users on your Solaris box using the winbind services +which come with SAMBA 2.2.x latest CVS Checkout.Make sure you are using the +latest Samba 2.2.x cvs checkout as other versions come with a lots of bugs +regarding winbind .And even the Latest Samba Stable Release is also not an +exception to this. + +Introduction +------------ + +This HOWTO describes the procedures used to get winbind up and running on a +Solaris system. Winbind is capable of providing access and authentication +control for Windows Domain users through an NT or Win2K PDC for 'regular' +services, such as telnet and ftp, as well for SAMBA services. + +Why should I to this? + +This allows the SAMBA administrator to rely on the authentication mechanisms +on the NT/Win2K PDC for the authentication of domain members. NT/Win2K users +no longer need to have separate accounts on the SAMBA server. + +Who should be reading this document? + +This HOWTO is designed for system administrators. If you are implementing +SAMBA on a file server and wish to (fairly easily) integrate existing +NT/Win2K users from your PDC onto the SAMBA server, this HOWTO is for you. + +Requirements +------------ + +If you have a samba configuration file that you are currently using... BACK +IT UP! If your system already uses PAM, back up the /etc/pam.conf file ! If +you haven't already made a boot disk, MAKEONE NOW! Messing with the pam +configuration file can make it nearly impossible to log in to yourmachine. +That's why you want to be able to boot back into your machine in single user +mode and restore your /etc/pam.conf back to the original state they were in +if you get frustrated with the way things are going. ;-) Please refer to the +main SAMBA web page or, better yet, your closest SAMBA mirror site for +instructions on downloading the source code of Samba 2.2.x from the SAMBA +CVS repository. To allow Domain users the ability to access SAMBA shares and +files, as well as potentially other services provided by your SAMBA machine, +PAM (pluggable authentication modules) must be setup properly on your +machine. In order to compile the winbind modules, you should have at least +the pam libraries resident on your system. Solaris 7/8 has its pam modules +coming with the distribution itself. + +Testing Things Out +------------------ + +Before starting, it is probably best to kill off all the SAMBA related +daemons running on your server. Kill off all smbd, nmbd, and winbindd +processes that may be running. + + +Configure and compile SAMBA +--------------------------- + +The configuration and compilation of SAMBA is pretty straightforward. The +first three steps may not be necessary depending upon whether or not you +have previously built the Samba binaries. + +root# autoconf +root# make clean +root# rm config.cache +root# ./configure --with-winbind --with-pam +root# make +root# make install + +This will, by default, install SAMBA in /usr/local/samba. See the main SAMBA +documentation if you want to install SAMBA somewhere else. It will also +build the winbindd executable and libraries. + +Configure nsswitch.conf and the winbind libraries +------------------------------------------------- + +The libraries needed to run the winbindd daemon through nsswitch need to be +copied to their proper locations, so + +root# cp ../samba/source/nsswitch/libnss_winbind.so /usr/lib + +I also found it necessary to make the following symbolic links: + +root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1 +root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.2 +root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1 +root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2 + +Now, as root you need to edit /etc/nsswitch.conf to allow user and group +entries to be visible from the winbindd daemon. My /etc/nsswitch.conf file +look like this after editing: + + passwd: files winbind + group: files winbind + + +Configure smb.conf +------------------ + +Several parameters are needed in the smb.conf file to control the behavior +of winbindd. Configure smb.conf These are described in more detail in the +winbindd(8) man page. My smb.conf file was modified to include the following +entries in the [global] section: + +[global] + <...> + # The previous documentation says to + # as the "winbind seperator " directive also but + # it is no longer supported. + + # use uids from 10000 to 20000 for domain users + winbind uid = 10000-20000 + + # use gids from 10000 to 20000 for domain groups + winbind gid = 10000-20000 + + # allow enumeration of winbind users and groups + winbind enum users = yes + winbind enum groups = yes + + # give winbind users a real shell (only needed if + # they have telnet access) + template homedir = /home/winnt/%D/%U + template shell = /bin/bash + + +Join the SAMBA server to the PDC domain +--------------------------------------- + +Enter the following command to make the SAMBA server join the PDC domain, +where DOMAIN is the name of your Windows domain and Administrator is a +domain user who has administrative privileges in the domain. + +root# /usr/local/samba/bin/smbpasswd -j DOMAIN -r PDC -U Administrator + +The proper response to the command should be: "Joined the domain DOMAIN" +where DOMAIN is your DOMAIN name. + +Start up the winbindd daemon and test it! + +Eventually, you will want to modify your smb startup script to automatically +invoke the winbindd daemon when the other parts of SAMBA start, but it is +possible to test out just the winbind portion first. To start up winbind +services, enter the following command as root: + +root# /usr/local/samba/bin/winbindd + +I'm always paranoid and like to make sure the daemon is really running... + +root# ps -ae | grep winbindd + +This command should produce output like this, if the daemon is running + + 3025 ? 00:00:00 winbindd + +Now... for the real test, try to get some information about the users on +your PDC + +root# /usr/local/samba/bin/wbinfo -u + +This should echo back a list of users on your Windows users on your PDC. For +example, I get the following response: + +CEO\Administrator +CEO\burdell +CEO\Guest +CEO\jt-ad +CEO\krbtgt +CEO\TsInternetUser + +root# /usr/local/samba/bin/wbinfo -g + +CEO\Domain Admins +CEO\Domain Users +CEO\Domain Guests +CEO\Domain Computers +CEO\Domain Controllers +CEO\Cert Publishers +CEO\Schema Admins +CEO\Enterprise Admins +CEO\Group Policy Creator Owners + +The function 'getent' can now be used to get unified lists of both local and +PDC users and groups. Try the following command: + +root# getent passwd + +You should get a list that looks like your /etc/passwd list followed by the domain users with their new +uids, gids, home directories and default shells. + +The same thing can be done for groups with the command + +root# getent group + +Fix the /etc/rc.d/init.d/samba.server startup files The winbindd daemon +needs to start up after the smbd and nmbd daemons are running. To accomplish +this task, you need to modify the /etc/init.d/samba.server script to add +commands to invoke this daemon in the proper sequence. My +/etc/init.d/samba.server file starts up smbd, nmbd, and winbindd from the +/usr/local/samba/bin directory directly. + +## +## samba.server +## + +if [ ! -d /usr/bin ] +then # /usr not mounted + exit +fi + +killproc() { # kill the named process(es) + pid=`/usr/bin/ps -e | + /usr/bin/grep -w $1 | + /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` + [ "$pid" != "" ] && kill $pid +} + +# Start/stop processes required for samba server + +case "$1" in + +'start') +# +# Edit these lines to suit your installation (paths, workgroup, host) +# +echo Starting SMBD + /usr/local/samba/bin/smbd -D -s \ + /usr/local/samba/smb.conf + +echo Starting NMBD + /usr/local/samba/bin/nmbd -D -l \ + /usr/local/samba/var/log -s /usr/local/samba/smb.conf + +echo Starting Winbind Daemon + /usr/local/samba/bin/winbindd + ;; + +'stop') + killproc nmbd + killproc smbd + killproc winbindd + ;; + +*) + echo "Usage: /etc/init.d/samba.server { start | stop }" + ;; +esac + +If you restart the smbd, nmbd, and winbindd daemons at this point, you +should be able to connect to the samba server as a domain member just as if +you were a local user. + + +Configure Winbind and PAM +------------------------- + +If you have made it this far, you know that winbindd and samba are working +together. If you want to use winbind to provide authentication for other +services, keep reading. The pam configuration file need to be altered in +this step. (Did you remember to make backups of your original /etc/pam.conf +file? If not, do it now.) You will need a pam module to use winbindd with +these other services. This module will be compiled in the ../source/nsswitch +directory by default when we used ./configure --with-pam option. + +root# make nsswitch/pam_winbind.so + +from the ../source directory. The pam_winbind.so file should be copied to +the location of your other pam security modules. On my Solaris 8, this was +the /usr/lib/security directory. + +root# cp ../samba/source/nsswitch/pam_winbind.so /usr/lib/security + +The /etc/pam.conf need to be changed. I changed this file so that my Domain +users can logon both locally as well as telnet.The following are the changes +that I made.You can customize the pam.conf file as per your requirements,but +be sure of those changes because in the worst case it will leave your system +nearly impossible to boot. + +# +#ident "@(#)pam.conf 1.14 99/09/16 SMI" +# +# Copyright (c) 1996-1999, Sun Microsystems, Inc. +# All Rights Reserved. +# +# PAM configuration +# +# Authentication management +# +login auth required /usr/lib/security/pam_winbind.so +login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass +# +rlogin auth sufficient /usr/lib/security/pam_winbind.so +rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 +rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +dtlogin auth sufficient /usr/lib/security/pam_winbind.so +dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 +other auth sufficient /usr/lib/security/pam_winbind.so +other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +# Account management +# +login account sufficient /usr/lib/security/pam_winbind.so +login account requisite /usr/lib/security/$ISA/pam_roles.so.1 +login account required /usr/lib/security/$ISA/pam_unix.so.1 +# +dtlogin account sufficient /usr/lib/security/pam_winbind.so +dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 +dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 +# +other account sufficient /usr/lib/security/pam_winbind.so +other account requisite /usr/lib/security/$ISA/pam_roles.so.1 +other account required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Session management +# +other session required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Password management +# +#other password sufficient /usr/lib/security/pam_winbind.so +other password required /usr/lib/security/$ISA/pam_unix.so.1 +dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Support for Kerberos V5 authentication (uncomment to use Kerberos) +# +#rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other account optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other session optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass + +I also added a try_first_pass line after the winbind.so line to get rid of +annoying double prompts for passwords. + +Now restart your Samba & try connecting through your application that you +configured in the pam.conf. + + + +!== +!== end of Solaris-Winbind-HOWTO.txt +!== diff --git a/docs/textdocs/Speed.txt b/docs/textdocs/Speed.txt index 5dfd70323b1..b82db8f8f4d 100644 --- a/docs/textdocs/Speed.txt +++ b/docs/textdocs/Speed.txt @@ -1,8 +1,8 @@ -This file tries to outline the ways to improve the speed of a Samba server. -Andrew Tridgell -January 1995 +Subject: Samba performance issues +============================================================================ +This file tries to outline the ways to improve the speed of a Samba server. COMPARISONS ----------- @@ -30,6 +30,62 @@ 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 -------------- @@ -80,7 +136,10 @@ 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. +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 @@ -111,7 +170,20 @@ 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. +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 --------- @@ -187,7 +259,7 @@ 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=1 option +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 @@ -239,6 +311,7 @@ person even reported a speed drop of a factor of 30 when he went from 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 ---------- @@ -263,10 +336,3 @@ smbclient running on another linux box. Maybe I'll add those results here someday ... -COMMENTS --------- - -If you've read this far then please give me some feedback! Which of -the above suggestions worked for you? - -Mail the samba mailing list or samba-bugs@anu.edu.au diff --git a/docs/textdocs/Speed2.txt b/docs/textdocs/Speed2.txt new file mode 100644 index 00000000000..a8c3e7381fd --- /dev/null +++ b/docs/textdocs/Speed2.txt @@ -0,0 +1,57 @@ +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/Support.txt b/docs/textdocs/Support.txt deleted file mode 100644 index d71bdaf7b3e..00000000000 --- a/docs/textdocs/Support.txt +++ /dev/null @@ -1,376 +0,0 @@ -The Samba Consultants List -========================== - -This is a list of people who are prepared to install and support Samba. -Note that in most countries nobody should admit to "supplying" Samba, since -there is then an implied warranty with possibly onerous legal obligations. -Just downloading and installing it isn't supply in this sense, but advertising -"run our Samba for best results" may be so. - -Being on this list does not imply any sort of endorsement by anyone, it is just -provided in the hope that it will be useful. - -If you want to be added to the list, or want your entry modified then -contact the address below. They are currently listed in the -order that they were received. If it gets too big we may organise it -by region. Please make sure to include a header line giving the region -and country, eg CANBERRA - AUSTRALIA. - -You can contact the maintainers at samba-bugs@anu.edu.au - - ------------------------------------------------------------------------------- -BRISBANE - AUSTRALIA - -Brett Worth -Select Computer Technology - Brisbane -431 Logan Road -Stones Corner QLD 4120 -E-Mail: brett@sct.com.au ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -CANBERRA - AUSTRALIA - -Paul Blackman (ictinus@lake.canberra.edu.au, Ph. 06 2012518) is -available for consultation. Paul's Samba background is with -Solaris 2.3/4 and WFWG/Win95 machines. Paul is also the maintainer -of the SAMBA Web Pages. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -READING - ENGLAND - -Philip Hands | E-Mail: info@hands.com -Philip Hands Computing Ltd. | Tel: +44 1734 476287 Fax: 1734 474655 -Unit 1, Cherry Close, Caversham, Reading RG4 8UP UK - -Samba experience: SVR4,SVR3.2 & Linux <--> WfWg, W3.1, OS2 and MS-LanMan ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -ILLONOIS - USA - -Information One, Inc. -736 Hinman Ave, Suite 2W -Evanston, IL 60202 -708-328-9137 708-328-0117 FAX -info@info1.com - -Providing custom Internet and networking solutions. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -Olympic Peninsula Consulting; 1241 Lansing Ave W., Bremerton, WA 98312-4343 -telephone 1+ 360 792 6938; mailto:opc@aa.net; http://www.aa.net/~opc; -Unix Systems and TCP/IP Network design, programming, and administration. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -SolutionS R Us has been in business for 3+ years providing viable 3rd -party support in system/network administration. With our own Linux -distribution which we're constantly improving to make it the best and -using it to provide total solutions for companies which are open to -using Linux. - -Mauro DePalma <mauro@sru.com> ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -BIELEFELD - GERMANY - -I am located in Bielefeld/Germany and have been doing Unix consultancy -work for the past 8 years throughout Germany and the rest of Europe. I -can be contacted by email at <jpm@mens.de> or via phone at +49 521 -9225922 or telefax at +49 521 9225924. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -CANBERRA - AUSTRALIA - -Ben Elliston -Faculty of Information Sciences and Engineering -University of Canberra AUSTRALIA -E-mail: ben@ise.canberra.edu.au (Uni) ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -PALERMO - ITALY - -Francesco Cardinale -E-Mail: cardinal@palermo.italtel.it -Samba experience: SVR3.2, SOLARIS, ULTRIX, LINUX <--> DOS LAN-MAN, WFW ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -SYDNEY - AUSTRALIA - -John Terpstra - Aquasoft (jht@aquasoft.com.au) -Business: +612 524 4040 -Home: +612 540 3154 -Shoephone: +612 414 334422 (aka 0414 334422) ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -ONTARIO - CANADA - -Strata Software Limited, Kanata Ontario CANADA -Tel: +1 (613) 591-1922 Fax: +1 (613) 591-3485 -Email: sales@strataware.com WWW: http://www.strataware.com/ - -Strata Software Limited is a software development and consulting group -specializing in data communications (TCP/IP and OSI), X.400, X.500 and -LDAP, and X.509-based security. We have Samba experience with Windows NT, -Windows 95, and Windows for Workgroups clients with Linux, Unixware -(SVR4), and HP-UX servers. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------ -SYDNEY - AUSTRALIA - -We are a Unix & Windows developer with a consulting & support component. -In business since 1981 with experience on Sun, hp, sgi, IBM rs6000 plus -Windows, NT and Win95, Using Samba since September 94. -CodeSmiths, 22 Darley Road, MANLY 2095 NSW; 977 1979; fax: 977 2116 -philm@esi.com.au (Australia; New South Wales; SYDNEY; North East) ------------------------------------------------------------------------ - ------------------------------------------------------------------------------- -EDINBUGH - SCOTLAND - -Charlie Hussey email charlie@edina.demon.co.uk -Edina Software Limited tel 0131 657 1129 -4 James Street fax 0131 669 9092 -Edinburgh EH15 2DS - -SAMBA experience: SCO UNIX <=> WfWg ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -LONDON - ENGLAND - -Mark H. Preston, -Network Analyst, | Email : mpreston@sghms.ac.uk -Computer Unit, | Tel : +44 (0)181 725-5434 -St. George's Hospital Med School, | Fax : +44 (0)181 725-3583 -London SW17 ORE. | WWW : http://www.sghms.ac.uk - -Samba Experience: -Server: Solaris 2.3 & 2.4, Irix 5.2 & 5.3 -Client: WinNT, Win95, WfWg, Win3.1, Ms-LanMan, DHCP support ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -SYDNEY - AUSTRALIA - -Pacific ESI has used and installed Samba since 1.6 on a range -of machines running SunOS, BSD/OS, SCO/UNIX, HP/UX, and Solaris, -and WfWG and Windows95. The largest system worked on to date -involved an Australia wide network of machines with PCs and SUNs -at the various nodes. The in-house testing site is a wide area -network with three sites, remotely connected with PPP and with -SUN servers at each site to all of which are connected several -PCs running mainly WfWG. - -Stefan Kjellberg Pacific Engineering Systems -International -info@eram.esi.com.au Voice:+61-2-9063377 -... Fax:+61-2-9063468 ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -CHANTILLY - USA - -Intelligent Decisions, Inc. -ATTN: Richard Bullington -14121 Parke Long Ct. #104 -Chantilly, VA 22021 -U.S.A. -(703) 803-8070 -rbullington@intdec.com - -Samba experience: Linux, DEC ULTRIX <=> WFWG 3.11, Windows NT 3.5 -Specializing in World Wide Web related UNIX-to-PC connectivity. ------------------------------------------------------------------------------- - ------------------------------------------------------------------------------- -FORT COLLINS, CO - USA - -Granite Computing Solutions -ATTN: Brian Grossman -Box 270103 -Fort Collins, CO 80527-0103 -U.S.A. -(970) 225-2370 -granite@fortnet.org - -Information services, including WfWG, NT, Apple <=> Unix interoperability. - -Our standard advertisement says: - -> Unix workstations, servers and custom systems < ->> WWW and Unix education << ->>> Enterprise and departmental computing solutions <<< ->>> Backup & restore <<< ->> Software forensics << -> Data translation < ------------------------------------------------------------------------------- - ----------------------------------------------------------- -Adelaide, Australia - -NS Computer Software and Services P/L -PO Box 86 -Ingle Farm -SA 5098 - -Contact: Richard Sharpe - Ph: +61-8-281-0063 (08-281-0063) AH - FAX:+61-8-250-2080 (08-250-2080) - -Experience with: ULTRIX, Digital UNIX, SunOS, WfW 3.11, Win95, WNT 3.51 - ----------------------------------------------------------- - ----------------------------------------------------------- -TECTONIC LIMITED -WESTWOOD -78 LOUGHBOROUGH ROAD -QUORN -LEICESTERSHIRE -LE12 8DX - -TELEPHONE 01509-620922 -FAX 01509-620933 - -CONTACT DAVID ROBINSON - -WE ARE UNIX ORIENTATED BUT ALSO SPECIALISE IN PC TO UNIX COMMUNICATIONS, WE -KNOW AND UNDERSTAND PC-NFS, (HENCE OUR INTEREST IN SAMBA). -WE SUPPORT SUNOS, SOLARIS 1.X AND 2.X, HP-UX 9.0 AND 10.0, OSF (or DEC UNIX, -whichever you prefer), WinNT, WfWG and Win95. - -WE ARE ALREADY TALKING TO A COUPLE OF VERY LARGE SAMBA USERS HERE IN THE UK. -WE WOULD LIKE TO SUPPORT THEM (AND MANY MORE), WOULD YOU PLEASE CONTACT ME ON: -david@tectonic.demon.co.uk ----------------------------------------------------------- - ----------------------------------------------------------- -MIAMI, FL - USA - -Swaney & Associates, Inc. -ATTN: Stephen Swaney - 2543 Lincoln Avenue - Miami, Florida 33133 - U.S.A - (305) 860-0570 - -Specializing in: - High Availability system & networks - UNIX to PC connectivity - Market Data systems - Messaging Systems (Sendmail & Microsoft Exchange) ----------------------------------------------------------- - ------------------------------------------------------------------------------- -NEW JERSEY - USA - -William J. Maggio -LAN & Computer Integrators, Inc. -242 Old New Brunswick Road Email: bmaggio@lci.com -Suite 440 Voice: 908-981-1991 -Piscataway, NJ 08855 Fax : 908-981-1858 - - Specializing in Internet connectivity and security, Sun integration and - high speed, enterprise network design and deployment. ------------------------------------------------------------------------------- - -FAREHAM - ENGLAND - -High Field Technology Ltd -Little Park Farm Road, Segensworth West, -Fareham, Hants PO15 5SJ, UK. -sales@hft.co.uk tel +44 148 957 0111 fax +44 148 957 0555 - -Company skills: Real time hardware and software systems - -Samba experience: BSD/OS, Linux, LynxOS <==> WFWG, NT - ------------------------------------------------------------------------------- - ------------------------------------------------------------------------ -QUEBEC - CANADA - -Dataden Computer Systems -Attn: Danny Arseneau -arseneau@parkmed.com -895 2nd Avenue -Ile Bizard, Quebec -Canada, H9C 1K3 -Tel: (514)891-2293 -Fax: (514)696-0848 - -Dataden is company that specializes in Unix--TCP/IP networking. -We have over 15 years of experience. We have been installing, -configuring and maintaining Samba for clients for 1-1/2 years now. We -have samba installations on Linx, SunOS and DEC OSF. Our biggest site -has 4 Suns and 3 Linux servers running Samba which are serving a network -of about 50 PC's running WFWg and Win95. ------------------------------------------------------------------------ - ------------------------------------------------------------------------ -CALIFORNIA - USA - -Ron Halstead -Open Systems Consulting -3098-4 Lakemont Drive -San Ramon, CA 94583 (San Francisco Bay Area) -(510) 735-7529 -halstead@ix.netcom.com ------------------------------------------------------------------------ - - ------------------------------------------------------------------------ -MELBOURNE - AUSTRALIA - -Michael Ciavarella -Cybersoruce Pty Ltd. -8/140 Queen Street -Melbourne VIC 3000 -Phone: +61-3-9642-5997 -Fax: +61-3-9642-5998 -Email: mikec@cyber.com.au -WWW: http://www.cyber.com.au - -Cybersource specialises in TCP/IP network integration and Open Systems -administration. Cybersource is an Australian-owned and operated -company, with clients including some of Australia's largest financial, -petrochemical and state government organisations. ------------------------------------------------------------------------ - ------------------------------------------------------------------------ -SOUTHERN CALIFORNIA - USA - -Michael St. Laurent -Serving Los Angeles and Orange Counties. Please contact via email. -rowl@earthlink.net -Michael St. Laurent -Hartwell Corporation ------------------------------------------------------------------------------- -WASHINGTON DC METRO - USA - -Asset Software, Inc. has been running Samba since the 1.6 release on various -platforms, including SunOS 4.x, Solaris 2.x, IRIX 4.x and 5.x, Linux 1.1x, -1.2x, and 1.3x, and BSD UNIX 4.3 and above. We specialize in small office -network solutions and provide services to enhance a small office's -operations. Primarily a custom software operation, our vast knowledge of -Windows, DOS, Unix, Windows NT, MacOS, and OS/2 enable us to provide quality -technical assistance to the small office environment at a reasonable price. -Our upcoming multi-mailbox mail client, IQ Mail, enables users with more -than one mailbox to send and retrieve their mail from a single, consistent -mail client running in Windows. - -David J. Fenwick Asset Software, Inc. -President djf@assetsw.com ------------------------------------------------------------------------------- - diff --git a/docs/textdocs/Tracing.txt b/docs/textdocs/Tracing.txt new file mode 100644 index 00000000000..6cc1d69258d --- /dev/null +++ b/docs/textdocs/Tracing.txt @@ -0,0 +1,93 @@ +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 index b2c064215cf..c3d7643cbcb 100644 --- a/docs/textdocs/UNIX-SMB.txt +++ b/docs/textdocs/UNIX-SMB.txt @@ -1,3 +1,9 @@ +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 @@ -6,9 +12,6 @@ interoperability. It was written to help out a person who was writing a paper on unix to PC connectivity. -Andrew Tridgell -April 1995 - Usernames ========= @@ -85,19 +88,17 @@ 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 it's validation via another machine +option which allows Samba to do its validation via another machine (typically a WinNT server). -Samba also doesn't support the password encryption method used by SMB -clients. This is because the spec isn't sufficiently detailed for an -implementation (although Jeremy Allison is working on it, to try and -work it out). Also, there is a fundamental problem with what we -understand so far in the algorithm, as it seems that the server would -need to store somewhere on disk a reversibly encrypted (effectively -plaintext) copy of the users password in order to use the -algorithm. This goes against the unix policy that "even the super-user -doesn't know your password" which comes from the use of a one-way hash -function. +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 ======= @@ -127,7 +128,7 @@ 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 it's lock. Unix has no simple way of implementing +give up its lock. Unix has no simple way of implementing opportunistic locking, and currently Samba has no support for it. Deny Modes @@ -140,10 +141,12 @@ 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 these Samba uses lock +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. These are clumsy and consume processing and file resources, -so they are optional and off by default. +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 ============= @@ -155,6 +158,9 @@ 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 ============ @@ -216,5 +222,10 @@ 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. +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/UNIX_SECURITY.txt b/docs/textdocs/UNIX_SECURITY.txt new file mode 100644 index 00000000000..38705f018ac --- /dev/null +++ b/docs/textdocs/UNIX_SECURITY.txt @@ -0,0 +1,54 @@ +Contributor: John H Terpstra <jht@samba.org> +Date: July 5, 1998 +Status: Current + +Subject: SETTING UNIX FILE SYSTEM SECURITY +=============================================================================== +The following excerpt from a bug report demonstrates the need to +understand Unix file system security and to manage it correctly. + +Quote: +====== +> We are unable to keep individual users from mapping to any other user's +> home directory once they have supplied a valid password! They only need +> to enter their own password. I have not found *any* method that I can +> use to configure samba to enforce that only a user may map their own +> home directory. +> +> User xyzzy can map his home directory. Once mapped user xyzzy can also map +> *anyone* elses home directory! + +ANSWER: +======= +This is not a security flaw, it is by design. Samba allows +users to have *exactly* the same access to the UNIX filesystem +as they would if they were logged onto the UNIX box, except +that it only allows such views onto the file system as are +allowed by the defined shares. + +This means that if your UNIX home directories are set up +such that one user can happily cd into another users +directory and do an ls, the UNIX security solution is to +change the UNIX file permissions on the users home directories +such that the cd and ls would be denied. + +Samba tries very hard not to second guess the UNIX administrators +security policies, and trusts the UNIX admin to set +the policies and permissions he or she desires. + +Samba does allow the setup you require when you have set the +"only user = yes" option on the share, is that you have not set the +valid users list for the share. + +Note that only user works in conjunction with the users= list, +so to get the behavior you require, add the line : + +users = %S + +this is equivalent to: + +valid users = %S + +to the definition of the [homes] share, as recommended in +the smb.conf man page. + diff --git a/docs/textdocs/Win95.txt b/docs/textdocs/Win95.txt new file mode 100644 index 00000000000..69330c512d4 --- /dev/null +++ b/docs/textdocs/Win95.txt @@ -0,0 +1,74 @@ +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 index b57abb7742e..5c72fb08aa7 100644 --- a/docs/textdocs/WinNT.txt +++ b/docs/textdocs/WinNT.txt @@ -1,6 +1,17 @@ -There are some particular issues with Samba and Windows NT +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 @@ -8,21 +19,34 @@ 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. +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). - -Samba should support encrypted passwords soon, which will solve this -problem. ===================================================================== - - -===================================================================== +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: @@ -49,8 +73,32 @@ 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 new file mode 100644 index 00000000000..643b8957c9f --- /dev/null +++ b/docs/textdocs/cifsntdomain.txt @@ -0,0 +1,1498 @@ +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 new file mode 100644 index 00000000000..8408acb979a --- /dev/null +++ b/docs/textdocs/outdated/NTDOMAIN.txt @@ -0,0 +1,51 @@ +!== +!== 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/PRINTER_DRIVER.txt b/docs/textdocs/outdated/PRINTER_DRIVER.txt new file mode 100644 index 00000000000..5bf82e0cfe4 --- /dev/null +++ b/docs/textdocs/outdated/PRINTER_DRIVER.txt @@ -0,0 +1,240 @@ +!== +!== PRINTER_DRIVER.txt for Samba release 2.0.4 18 May 1999 +!== +========================================================================== + Supporting the famous PRINTER$ share + + Jean-Francois.Micouleau@utc.fr, 10/26/97 + modified by herb@sgi.com 1/2/98 + +=========================================================================== + +Disclaimer: + + This ONLY works with Windows 95 + It does NOT work with Windows NT 4 + + +Goal: + + When you click on a samba shared printer, you can now install the driver + automatically onto the Windows 95 machine, as you would from an NT server. + +How To: + + It's a three step config. + + First, create a new directory, where you will put the driver files, and + make a share in smb.conf pointing to it. + + Example: + + [printer$] + path=/usr/local/samba/printer + public=yes + writable=no + browseable=yes + + Second, you have to build the list of drivers required for a specific + printer. This is the most complicated thing to do. Get the files + 'msprint.inf' and 'msprint2.inf' from Windows 95, the easiest way is to + grab them from a working Windows 95 computer. They are usually located + in 'c:\windows\inf'. Look in them for the printer you have. Run the new + program 'make_printerdef' with the file name and the printer name as + parameters. If you have drivers for an unsupported or updated printer, + first install these drivers on an Windows 95 system. There will be a + file created in your inf directory named 'oem?.inf' (where the ? is some + number). Use this file instead of msprint.inf. + + Example: (from the /usr/local/samba/lib directory) + + make_printerdef msprint.inf "Apple LaserWriter" >> printers.def + + The program will print out a list of required files to stderr. + Copy all the files listed into the directory you created in step 1. + If you have "preserve case = yes" make sure your files names match + EXACTLY the names listed. + + Third, you need to add 2 new parameters in smb.conf. One is in the + [global] section, called 'printer driver file' pointing to the printer + description file you just created, and the other in each printer share, + called 'printer driver location' pointing to where the client will get + the drivers. Don't forget to set correctly the printer driver parameter + to the Windows printer name. + + Example: + + [global] + printer driver file=/usr/local/samba/lib/printers.def + + [lp] + comment = My old printer laser + browseable = yes + printable = yes + public = yes + writable = no + create mode = 0700 + printer driver=Apple LaserWriter + printer driver location=\\%h\PRINTER$ + + %h will expand to the computer name, and PRINTER$ is the name of the + share created in step one. + + +If it doesn't work for you, don't send flame ! It worked for me. In case of +trouble don't hesitate to send me a mail with your smb.conf file and +printers.def + + +******* added by herb@sgi.com + +For those of you who like to know the details, and in case I have guessed +wrong on some of the fields - The following is the format of the entries +in the printers.def file: (entries are 1 single line - they are split here +for readability) + +<Long Printer Name>:<Driver File Name>:<Data File Name>:<Help File Name>: +<Language Monitor Name>:<Default Data Type>:<Comma Separated list of Files> + +The <Help File Name> and the <Language Monitor Name> can be empty. +If no <Driver File Name> or <Data File Name> are specified in the inf file, +these will default to the section name for the printer. + +The following is an excerpt from the MSPRINT2.INF file on a WIN95 machine. +I have deleted all but the entries relating to installing a driver for the +"QMS ColorScript 100 Model 30" printer. Using this "file" I'll try to +explain how the printers.def file is created. + +make_printerdef is run with the first argument being the name of this +file (MSPRINT2.INF in this case) and the second argument being the +name of the printer ("QMS ColorScript 100 Model 30" in this case). + +The printer name is first found in the "Model section" to obtain the +name of the "Installer Section" (this is the name after the equal sign). +We ignore the alternate name. + +The "Installer Section" contains entries for "CopyFiles" and "DataSection". +The "CopyFiles" line gives a list of all the required files for this +printer. If the name begins with an @ it is the name of a file (after +you strip off the @), otherwise it is the name of a "Copy Section" which +in turn is a list of files required. This printer has one file listed +"QCS30503.SPD" and two sections "COLOR_QMS_100_30" and "PSCRIPT". The +"COLOR_QMS_100_30" section is listed in the "[DestinationDirs]" as +having a value of 23. This means that all files listed in this section +should go into the "color" subdirectory. The list of files to copy for +this printer is thus: + +QCS30503.SPD,color\QMS10030.ICM,PSCRIPT.DRV,PSCRIPT.HLP,PSCRIPT.INI, +TESTPS.TXT,APPLE380.SPD,FONTS.MFM,ICONLIB.DLL,PSMON.DLL + +From the "Data Section" we obtain values for "DriverFile", "HelpFile", +and "LanguageMonitor". The % around the value for "LanguageMonitor" +indicates that it is a string that can be localized so its actual value +is obtained from the "[Strings]" section. The "Data Section" could also +have contained an entry for "DefaultDataType". + +Using the information we have obtained we can now construct the entry +for the printers.def file. + +<Long Printer Name> -> QMS ColorScript 100 Model 30 (name given + on the command line) +<Driver File Name> -> PSCRIPT.DRV (given in Data Section) +<Data File Name> -> QCS30503.SPD (defaults to Install Section name) +<Help File Name> -> PSCRIPT.HLP (given in Data Section) +<Language Monitor Name> -> PostScript Language Monitor (given in Data Section) +<Default Data Type> -> RAW (default if not specified) + + +So.... the enty (actually one line but split here for readability) would +be: + +QMS ColorScript 100 Model 30:PSCRIPT.DRV:QCS30503.SPD: +PSCRIPT.HLP:PostScript Language Monitor:RAW: +QCS30503.SPD,color\QMS10030.ICM,PSCRIPT.DRV,PSCRIPT.HLP,PSCRIPT.INI, +TESTPS.TXT,APPLE380.SPD,FONTS.MFM,ICONLIB.DLL,PSMON.DLL + +---------------------- Info from MSPRINT2.INF ------------------------ +; +; The Manufacturer section lists all of the manufacturers that we will +; display in the Dialog box + +[Manufacturer] +"QMS" + + +; +; Model sections. Each section here corresponds with an entry listed in the +; [Manufacturer] section, above. The models will be displayed in the order +; that they appear in the INF file. +; +; Each model lists a variation of its own name as a compatible ID. This +; is done primarily as an optimization during upgrade. +; +[QMS] +"QMS ColorScript 100 Model 30" = QCS30503.SPD,QMS_ColorScript_100_Model_30 + + +; +; Installer Sections +; +; These sections control file installation, and reference all files that +; need to be copied. The section name will be assumed to be the driver +; file, unless there is an explicit DriverFile section listed. +; +[QCS30503.SPD] +CopyFiles=@QCS30503.SPD,COLOR_QMS_100_30,PSCRIPT +DataSection=PSCRIPT_DATA + +; Copy Sections +; +; Lists of files that are actually copied. These sections are referenced +; from the installer sections, above. Only create a section if it contains +; two or more files (if we only copy a single file, identify it in the +; installer section, using the @filename notation) or if it's a color +; profile (since the DestinationDirs can only handle sections, and not +; individual files). +; +[COLOR_QMS_100_30] +QMS10030.ICM + +[PSCRIPT] +PSCRIPT.DRV +PSCRIPT.HLP +PSCRIPT.INI +TESTPS.TXT +APPLE380.SPD +FONTS.MFM +ICONLIB.DLL +PSMON.DLL + + +; +; Data Sections +; +; These sections contain data that is shared between devices. +; +[PSCRIPT_DATA] +DriverFile=PSCRIPT.DRV +HelpFile=PSCRIPT.HLP +LanguageMonitor=%PS_MONITOR% + + +; +; Color profiles go to the colors directory. All other files go to the +; system directory +; + +[DestinationDirs] +DefaultDestDir=11 +COLOR_QMS_100_30=23 +COLOR_TEKTRONIX_200I=23 +COLOR_TEKTRONIX_III_PXI=23 + + +; +; Localizable Strings +; +[Strings] +MS="Microsoft" +PS_MONITOR="PostScript Language Monitor,PSMON.DLL" + diff --git a/docs/textdocs/PROJECTS b/docs/textdocs/outdated/PROJECTS index cf903f2c6dd..3008bea430d 100644 --- a/docs/textdocs/PROJECTS +++ b/docs/textdocs/outdated/PROJECTS @@ -14,35 +14,37 @@ 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@anu.edu.au +samba-bugs@samba.org ======================================================================== Documentation and FAQ Docs and FAQ files for the Samba suite of software. -Contact Karl.Auer@anu.edu.au +Contact samba-bugs@samba.org with the diffs. These are urgently +required. -Mark Preston is now working on a set of formatted docs for Samba. -Contact mpreston@sghms.ac.uk +The FAQ is being added to on an ad hoc basis, see the web pages for info. -Docs are currently up to date with version, 1.7.07. FAQ being added to -as questions arise. +Mark Preston was working on a set of formatted docs for Samba. Is this +still happening? Contact mpreston@sghms.ac.uk -Status last updated 27th September 1994 +Status last updated 2nd October 1996 ======================================================================== ======================================================================== Netbeui support -This aims to produce patches so that Samba can be used with clients +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) - -The project is just startup up. - -Status last updated 4th October 1994 +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 ======================================================================== ======================================================================== @@ -52,21 +54,11 @@ A mountable smb filesystem for Linux using the userfs userspace filesystem Contact lendecke@namu01.gwdg.de (Volker Lendecke) -Currently this is at version 0.2. It works but is really only for -people with some knowledge and experience of Linux kernel hacking. - -Status last updated 23rd August 1994 -======================================================================== - -======================================================================== -Nmbd - -Aims to produce a complete rfc1001/1002 implementation. The current -nmbd is a partial implementation. - -Contact Fabrice Cetre (cetre@ifhpserv.insa-lyon.fr) +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 23rd August 1994 +Status last updated June 1997 ======================================================================== ======================================================================== diff --git a/docs/textdocs/security_level.txt b/docs/textdocs/security_level.txt new file mode 100644 index 00000000000..f4e0df7139c --- /dev/null +++ b/docs/textdocs/security_level.txt @@ -0,0 +1,100 @@ +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. |