Bug 4475 - 'map to guest' ignored when 'security = server'
'map to guest' ignored when 'security = server'
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Docs
3.0.24
x86 Linux
: P3 major
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-28 12:17 UTC by Jerry Marceau
Modified: 2007-04-11 16:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jerry Marceau 2007-03-28 12:17:08 UTC
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!
Comment 1 Jeremy Allison 2007-04-10 20:29:34 UTC
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.
Comment 2 Gerald (Jerry) Carter 2007-04-11 06:24:03 UTC
closing based on Jeremy comments.
Comment 3 Jerry Marceau 2007-04-11 15:13:12 UTC
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!
Comment 4 Gerald (Jerry) Carter 2007-04-11 15:22:20 UTC
The current behavior is correct.  Moving to docs component for the update.
Comment 5 Jeremy Allison 2007-04-11 16:00:57 UTC
I've updated the smb.conf docs.
Jeremy.