This patch adds a 'restrict anonymous' parameter to samba which forces samba to deny anonymous connections from clients. It supersedes my "null overrides valid username" patch (http://samba.anu.edu.au/listproc/samba-ntdom/2351.html). The patch can be downloaded from for 2.0.2: http://www.reac.com/samba/2.0.2/samba-restanon-2.0.2.diff This has two effects: - The %U and %G macro expansions will work in a predictable manner, because a username is always needed. This gets rid of cases where the client refreshes the share listing and shares "disappear". - Killing an smbd process for a WinNT client can cause the client to assume it's still validated, and sometimes will attempt reconnection anonymously. This will force it to revalidate. It has one side effect (related to how NT behaves after logout): - If you are using samba as a PDC, the client machine will be unable to revalidate it's machine account after a user logs out because WinNT maintains a validated connection after logout, and it tries to access the machine account initially using an anonymous connection. The solution here is to "Shutdown and restart" between interactive logons, rather than "Close all programs and logon as a different user". The fact that NT maintains a connection after logout has been a long standing problem with using Samba as a PDC, for which there is currently no know solution or workaround. If having to restart between interactive logons bothers you, then do not set restrict anonymous to true. The restrict anonymous parameter is not designed for use in share level security. Do not use it if you have security=share. Restrict anonymous does effect browsing on mixed client networks, but I have attempted to compensate for that. What appears to be a bug in Win95 makes it difficult to browse non-anonymously. If restrict anonymous is turned on, a work around gets enabled for win95 clients to make browsing work. See http://samba.anu.edu.au/listproc/samba-technical/1856.html for a more detailed description of this Win95 problem. I would recommend that restrict anonymous only be used on homogenous NT networks, but I am successfully (that is, browsing works for all machines when restrict anonymous is on) using it in a mixed NT and 95 network. If a Win95 machine is on your network and the workaround gets enabled, a message is generated to the system logs. If restrict anonymous is turned off (the default), then the complete original behaviour is used. My environment: Samba2.0.0beta4 Primary Domain Controller (RH 5.1) Samba2.0.0beta4 domain member (RH 5.1) approx 3 dozen Windows NT4 Workstations (mixed SP3 and SP4) 2 Windows NT4 Server SP4 Files patched are: source/smbd/reply.c source/param/loadparam.c yodldocs/smb.conf.5.yo The other kinds of docs will have to be regenerated from the yodl format docs. To apply: $ cd to the directory that contains the samba-2.0.0beta4/source directory $ ls (to verify you are in the right place) samba-2.0.0beta4 $ patch -p0 < samba-restanon-2beta4.diff patching file... I recommend GNU patch. The -p0 option is important so that it finds the files to patch in the subdirectories. From the docs: restrict anonymous(G) This is a boolean parameter. If it is true, then anonymous access to the server will be restricted, namely in the case where the server is expecting the client to send a username, but it doesn't. Setting it to true will force these anonymous connections to be denied, and the client will be required to always supply a username and password when connecting. Use of this parameter is only recommened for homogenous NT client environments. This parameter makes the use of macro expansions that rely on the username (%U, %G, etc) consistant. NT 4.0 likes to use anonymous connections when refreshing the share list, and this is a way to work around that. When restrict anonymous is true, all anonymous connections are denied no matter what they are for. This can effect the ability of a machine to access the samba Primary Domain Controller to revalidate it's machine account after someone else has logged on the client interactively. The NT client will display a message saying that the machine's account in the domain doesn't exist or the password is bad. The best way to deal with this is to reboot NT client machines between interactive logons, using "Shutdown and Restart", rather than "Close all programs and logon as a different user".