diff options
| -rw-r--r-- | docs/textdocs/GOTCHAS.txt | 46 | ||||
| -rw-r--r-- | docs/textdocs/HINTS.txt | 103 | ||||
| -rw-r--r-- | docs/textdocs/Recent-FAQs.txt | 225 |
3 files changed, 2 insertions, 372 deletions
diff --git a/docs/textdocs/GOTCHAS.txt b/docs/textdocs/GOTCHAS.txt index bc5c6dae85..ca8f86f9e6 100644 --- a/docs/textdocs/GOTCHAS.txt +++ b/docs/textdocs/GOTCHAS.txt @@ -20,49 +20,3 @@ Details: 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/HINTS.txt b/docs/textdocs/HINTS.txt index 877640108c..7af39adc9f 100644 --- a/docs/textdocs/HINTS.txt +++ b/docs/textdocs/HINTS.txt @@ -1,5 +1,5 @@ Contributor: Many -Updated: Not for a long time! +Updated: October 2002 Subject: A collection of hints Status: May be useful information but NOT current @@ -96,44 +96,6 @@ privilages and use it instead. Your users don't need to know the password of the guest account. ------------------------ -HINT: Use the latest TCP/IP stack from microsoft if you use Windows -for workgroups. - -The early TCP/IP stacks had lots of bugs. - -Microsoft has released an incremental upgrade to their TCP/IP 32-Bit -VxD drivers. The latest release can be found on their ftp site at -ftp.microsoft.com, located in /peropsys/windows/public/tcpip/wfwt32.exe. -There is an update.txt file there that describes the problems that were -fixed. New files include WINSOCK.DLL, TELNET.EXE, WSOCK.386, VNBT.386, -WSTCP.386, TRACERT.EXE, NETSTAT.EXE, and NBTSTAT.EXE. - - ------------------------ -HINT: nmbd can act as a "WINS" server - -By default SMB clients use broadcasts to find shares. Recent clients -(such as WfWg) can use a "wins" server instead, whcih reduces your -broadcast traffic and allows you to find names across routers. - -Just point your WfWg, Win95 and NT clients at the Samba box in the WINS option. - -Note: nmbd does not support all WINS operations. Anyone out there have -a spec they could send me? - ------------------------ -HINT: you may need to delete your .pwl files when you change password. - -WfWg does a lousy job with passwords. I find that if I change my -password on either the unix box or the PC the safest thing to do is to -delete the .pwl files in the windows directory. The PC will complain about not finding the files, but will soon get over it, allowing you to enter the new password. - -If you don't do this you may find that WfWg remembers and uses the old -password, even if you told it a new one. - -Often WfWg will totally ignore a password you give it in a dialog box. - ---------------------- HINT: Using MS Access @@ -147,66 +109,3 @@ Kjellberg <stefank@esi.com.au> records' 3. Of course locking must be enabled for the particular share (smb.conf) - - ---------------------- -HINT: password cacheing in WfWg - -Here is a hint from michael@ecel.uwa.edu.au (Michael Simmons): - -In case people where not aware. There is a program call admincfg.exe -on the last disk (disk 8) of the WFW 3.11 disk set. To install it -type EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXE Then add an icon -for it via the "Progam Manager" "New" Menu. This program allows you -to control how WFW handles passwords. ie disable Password Caching etc -for use with "security = user" - - --------------------- -HINT: file descriptor limits - -If you have problems with the limits on the number of open files you -can edit local.h to fix it. - --------------------- -HINT: HPUX initgroups() problem - -here is a hint from Frank Wales [frank@arcglade.demon.co.uk]: - -HP's implementation of supplementary groups is, er, non-standard (for -hysterical reasons). There are two group files, /etc/group and -/etc/logingroup; the system maps UIDs to numbers using the former, but -initgroups() reads the latter. Most system admins who know the ropes -symlink /etc/group to /etc/logingroup (hard link doesn't work for reasons -too stupid to go into here). initgroups() will complain if one of the -groups you're in in /etc/logingroup has what it considers to be an invalid -ID, which means outside the range [0..UID_MAX], where UID_MAX is (I think) -60000 currently on HP-UX. This precludes -2 and 65534, the usual 'nobody' -GIDs. - -Perhaps you could suggest to users that, if they encounter this problem, -they make sure that the programs that are failing to initgroups() be -run as users not in any groups with GIDs outside the allowed range. - -This is documented in the HP manual pages under setgroups(2) and passwd(4). - - ---------------------- -HINT: Patch your SCO system - -If you run SCO Unix then you may need to get important TCP/IP patches -for Samba to work correctly. Try - -Paul_Davis@mindlink.bc.ca writes: - - I was having problems with Accpac using 1.9.02 on SCO Unix. One - posting function reported corrupted data. After installing uod385a, - the problem went away (a restore from backup and then another - run-thru). - - It appears that the uod385a update for SCO may be fairly important for - a lot of different DOS and Windows software under Samba. - - uod385a can be found at ftp.sco.com /SLS/uod385a.Z and uod385a.ltr.Z. - - diff --git a/docs/textdocs/Recent-FAQs.txt b/docs/textdocs/Recent-FAQs.txt index feed127827..d6f4d6b99f 100644 --- a/docs/textdocs/Recent-FAQs.txt +++ b/docs/textdocs/Recent-FAQs.txt @@ -1,86 +1,10 @@ Contributor: Samba-bugs@samba.org -Date: July 5, 1998 +Date: October 2002 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 ============================== @@ -116,153 +40,6 @@ Samba docs 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 |