net use * \\sambasvr\share /u:username password
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)
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
This is a break from 2.2, but it is one that people have
been asking for.
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.
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?
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.
actually just try
auth methods = guest sam_ignoredomain winbind:ntdomain
Okay, I checked the DefaultDomain, and it is set to . on both boxes. Let me
detail my configuration:
[DOMAIN: Lothlorien] [Domain: A-DOMAIN]
<Win2k: w2k-c1> <Win2k: w2k-c2>
Local Users: test1%a
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.
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?)
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.
fixed using the sam_ignoredomain
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
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.
no work on this in a long time.
originally against 3.0.0rc2