path: root/docs/textdocs/Recent-FAQs.txt

!==
!== Recent-FAQs.txt for Samba release 2.1.0prealpha 981204
!==
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.
===============================================================================