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) sambasvr\username.
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.
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
Jerry, 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.
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?) Thanks! -Marc
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 auth method.
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.
no work on this in a long time.
originally against 3.0.0rc2