the 'map to guest' paramater is ignored when 'security = server'. 'map to guest' does work when 'security = user'. In my case, I want map to guest = bad user so that a user with a valid username and password gets access to the share. A user with a valid username but a bad password is rejected, and an invalid username and any password (blank or anything else) gets guest access. Here's how it all works (correctly) with security = user. First the smb.conf: [global] workgroup = workgroup-test security = user smb passwd file = /etc/samba/smbpasswd encrypt passwords = yes guest ok = yes browsable = yes map to guest = Bad User unix extensions = yes [homes] guest ok = no read only = no [public] guest ok = yes browseable = yes path = /tmp writeable = yes Here's the smbclient session, followed by the log information for each connection. First we connect as a valid user with the correct password > smbclient '\\localserver\public' -U valudiser Password: [correct password] Domain=[LOCALSERVER] OS=[Unix] Server=[Samba 3.0.24] smb: \> mkdir validuser smb: \> exit The smb.log entry: [2007/03/28 13:00:21, 1] smbd/service.c:make_connection_snum(950) client (xxx.xxx.xxx.xxx) connect to service public initially as user validuser (uid=xxxx, gid=xxxx) (pid 2712) [2007/03/28 13:00:41, 1] smbd/service.c:close_cnum(1150) client (xxx.xxx.xxx.xxx) closed connection to service public Now we'll connect as a valid user with a bad password > smbclient '\\localserver\public' -U validuser Password: [wrong password] session setup failed: NT_STATUS_LOGON_FAILURE This doesn't generate any information in the logs that I could find Finally, we'll connect as a bogus user > smbclient '\\localserver\public' -U nonuser Password: [some password] Domain=[LOCALSERVER] OS=[Unix] Server=[Samba 3.0.24] smb: \> mkdir nonuser smb: \> quit > That log entry: [2007/03/28 13:00:56, 1] smbd/service.c:make_connection_snum(950) client (xxx.xxx.xxx.xxx) connect to service public initially as user nobody (uid=99, gid=99) (pid 2727) [2007/03/28 13:01:03, 1] smbd/service.c:close_cnum(1150) client (xxx.xxx.xxx.xxx) closed connection to service public -- Okay, let's do it all over again with the following changes to smb.conf: [global] workgroup = scc-test security = server encrypt passwords = yes password server = PASS_SERVER guest ok = yes browsable = yes map to guest = Bad User unix extensions = yes [homes] guest ok = no read only = no [public] guest ok = yes browseable = yes path = /tmp writeable = yes Valid users connect the same as with security=server. The problem arises when a non valid user connects. Here's how that looks: > smbclient '\\localserver\public' -U nonuser Password: [some password] session setup failed: NT_STATUS_LOGON_FAILURE And here's what the log looks like: [2007/03/28 13:09:43, 1] auth/auth_server.c:check_smbserver_security(373) password server PASS_SERVER gave us guest only Which is interesting because the password server is telling us that the user is a guest user, but the local server then rejects that user outright. It is worth mentioning that PASS_SERVER is running Samba 3.0.10 (red hat enterprise linux) It is also worth mentioning that in security=server, any user who enters an empty password will get guest access regardless if the username is valid or not. In security=user this is not the case and an empty password will get non-valid users guest access, but reject valid users. I haven't been able to get this to work since around samba 2.0.10 and am still running that version for that reason. Let me know if more information is needed or if there are more tests you'd like me to run. Thanks!
Ok, I've been doing some experiments on this. Using "security = server" with a Windows server this will never work. The "map to guest" code depends on being able to know that the user exists or not - with modern Windows (and Samba) servers we never tell this information to a connecting client (which is what security = server is). We always map both bad user and bad password to NT_STATUS_LOGON_FAILURE, so as not to give any information to the caller about whether if it was the password or the username that was bad. map to guest works correctly with "security = user" and "secuity = domain/ads" because in the user case we know directly and in the domain case we have a secure channel from the DC so it's willing to tell us if a user existed or not. What this means is that the map to guest code can never work reliably with security=server I'm afraid.
closing based on Jeremy comments.
Thanks for the explaination. Though I'm still a bit confused. Currently, the password server is a 'modern' samba server (Samba 3.0.10). The 'file server' runs an old version (2.0.10), and the behavior of 'map to guest = bad user' works properly. When I use a modern 'file server'(3.0.24), 'map to guest = bad user' breaks, even though I've made no changes to the password server. So something is telling 2.0.10 about the existance of the user. The 3.0.x versions are ignoring this information or not asking. Or am I missing something here? (such as 2.0.10 is getting its user lists from local sources). If this won't be fixed, please update the man pages and other docs to mention that this doen't work. Thanks!
The current behavior is correct. Moving to docs component for the update.
I've updated the smb.conf docs. Jeremy.