Hi Dave, yeah, not pretty - should be fixed in the code. Just looking for a workaround that might be less undesireable than security = share!!!! (which was one of the options he was looking at in a private message to me). The point really is that we shouldn't even be LOOKING in the smbpasswd file when we specify encrypt passwords = no. But until we fix that, moving his users (from whatever user store he is using, nis, etc/passwd, etc) into the smbpasswd file, will avoid this particular windowsism. And with encrypt passwords = no, the smbpasswd is NOT being used for authentication, just verification of user existence for the 'map to guest=bad user' case... It's very convoluted code... not pretending to understand it all. (grin) That's why I cc'ed the list on the original problem and a (possibly poor) code diff change to fix it... Hopefully someone will look at that and say - well, HEY, that's dumb - lets fix it THIS way...
Don > -----Original Message----- > From: David Collier-Brown -- Customer Engineering > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 10:34 > To: MCCALL,DON (HP-USA,ex1); '[EMAIL PROTECTED]' > Subject: Re: FW: encrypt passwords=no, security=yes, samba 2.2.8, W2K > user aut h fails > > > That's highly undesirable, as it breaks single-signon > (unless you're an NT-cenric organization, which Sun isn't (:-)) > > --dave > > |Hi Tony, > |Another workaround would be to populate an smbpasswd file > with all the names > | > |from your /etc/passwd file. > |But I realize this can be onerous. Samba has a script to > help with this, > |mksmbpasswd.sh > |since you won't be needing passwords from this smbpasswd > file, this would do > |it for you, I think.... if your distribution doesn't > install this script, > |it > |can be found in the source at > /usr/local/samba/source/script/mksmbpasswd.sh > | > |useage: > | > |cat /etc/passwd|./mksmbpasswd.sh > >/usr/local/samba/var/private/smbpasswd > | > |Hope this helps > |Don > >