Bug 366 - When in domain authentication samba no longer accepts a local user (in smbpasswd) connecting in a seamless manner (can cause win9x a denial of service)
Summary: When in domain authentication samba no longer accepts a local user (in smbpas...
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.0preX
Hardware: Other other
: P3 enhancement
Target Milestone: none
Assignee: Andrew Bartlett
QA Contact:
Depends on:
Reported: 2003-08-28 15:34 UTC by Marc Kaplan
Modified: 2005-02-07 09:08 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Marc Kaplan 2003-08-28 15:34:14 UTC
Instead of:
net use * \\sambasvr\share /u:username password

We need:
net use * \\sambasvr\share /u:sambasvr\username password

This is unacceptable, as many programs, logon scripts, etc try doing the connect 
simply as username. win2k->win2k DOES NOT behave like this, and win2k->samba 
shouldn't either. This actually causes win9x clients to not be able to connect 
since they are not capable of sending (at least via the UI or command line) 
Comment 1 Gerald (Jerry) Carter (dead mail address) 2003-08-28 19:55:59 UTC
When I ran my tests this is exactly how windows 2 windows worked.
The current behavior is by design because people asked for it.
btw dude, please lay off the caps.  it's one of my pet peeves.
I'll retest your scenario, but I remember that NT did work 
like this.  

This is a break from 2.2, but it is one that people have 
been asking for.
Comment 2 Marc Kaplan 2003-08-29 09:19:54 UTC
Sorry about the caps, I didn't know you had a sensitivity to them :).

My test scenario was win2kc->win2ks. The server, win2ks was a domain member with 
some local users. I tried connecting via win2kc as one of those local users, and 
I could do so without having to do win2ks\username. I've not tested this with 
NT, but I can't imagine it would work differently than 2k, as that would cause 
9x clients to break. 
Comment 3 Gerald (Jerry) Carter (dead mail address) 2003-09-04 22:30:46 UTC
Mark.  I believe the is actually controlled by a "DefaultDomain" 
registry value in the WinLogon registry key.  Can you check and see
what it is set to on the clients you are testing with?
Comment 4 Gerald (Jerry) Carter (dead mail address) 2003-09-05 12:48:17 UTC
I think I know what the problem is now.   You are trying to connect 
as a username that doesn't exist in the windows domain  (e.g. root).

The current code maps the default domain (DOMAIN\root) and the the 
sam passdb backend only looks at account that match its own 
domain.  If you were connecting as Administrator (that did exist 
in the windows domain), the the LOGON_FAILURE would be correct.

I distincly remember running these tests with Volker using NT 
member servers.  But now 2k seems to be defaulting to local 
accounts for some reason.

I believe that the current behavior is more benefecial
(defaulting to the DOMAIN\user and not to SERVER\user
based on community feedback).  However, if we remove 
the strict checks in the sam passdb, I think we can have 
our cake and eat it too.  
Comment 5 Gerald (Jerry) Carter (dead mail address) 2003-09-05 12:50:09 UTC
actually just try

  auth methods = guest sam_ignoredomain winbind:ntdomain
Comment 6 Marc Kaplan 2003-09-08 14:37:33 UTC

Okay, I checked the DefaultDomain, and it is set to . on both boxes. Let me 
detail my configuration:

[DOMAIN: Lothlorien]                  [Domain: A-DOMAIN]
      ^                                         ^
   Joined                                     Joined
      "                                         "
      "                                         "
<Win2k: w2k-c1>                         <Win2k: w2k-c2>
Local Users: test1%a
Shares:  Share1

I have w2k-c2(currently logged into A-DOMAIN) connect to w2k-c1, and I get 
prompted for user/password. I enter test1 for the user and a for password. I am 
logged in successfully. 

If I replace w2k-c1 with a samba server named samba-svr1, I cannot connect 
unless I prepend samba-svr1 to username username. This is problematic for win9x 
clients who can't prepend anything to the username.
Comment 7 Marc Kaplan 2003-09-08 14:40:07 UTC
Oh, I didn't see your most recent comments. I guess the update notification 
(which I liked) has been turned off. I guess I should have replied to that mail

Anyway, I tried your suggestion about auth methods, it seems to be working 
great! I'll check for other ramifications, and if there are no major ones I'll 
mark as resolved (though maybe we should consider changing the default?)


Comment 8 Gerald (Jerry) Carter (dead mail address) 2003-09-10 07:37:57 UTC
I think we should keep the current default.  It 
too many people raise a stink, then we might 
consider it.  Let's see how 3.0.0 goes.
The current behavior should be less surprising 
that the sam_ignoredomain one I think.

Putting this into "monitor" mode.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2003-10-01 10:14:43 UTC
fixed using the sam_ignoredomain 
auth method.  
Comment 10 Andrew Bartlett 2003-10-01 15:30:20 UTC
When I get out from under this pile of work, I'm going to 'fix' this by allowing
the default authentication domain to be changed (much like windows allows via a
registry key).  

The testing we have done seems to show that Samba's current behaviour is
correct, except it is using the 'incorrrect' default domain.  Using
sam_ignoredomain doesn't quite achive the desired effect.
Comment 11 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:07:45 UTC
no work on this in a long time.
Comment 12 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:08:03 UTC
originally against 3.0.0rc2