Hi, Since the following commit, the plaintext authentication is not working. the "if (! pass)" block is probably the cause of the problem. http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=9ed12bfc48fe7f9b1863a9dd88e881974083053c Michael Adam already committed something that fix it for security = share http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=008c4bdbe5de064b4469fc1f7c7173290f35b3ef but the problem is also occuring with security = user Our Windows XP have the following registry parameter, allowing them to work in plaintext password [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters] "EnablePlainTextPassword"=dword:00000001 And I've changed those parameters in the smb.conf from the default value in 3.2.0: lanman auth = Yes client lanman auth = Yes client plaintext auth = Yes It seems that when Windows is set to use PlainTextPassword, it try to send an empty password before prompting the user for his password when the he issue a command like "net use * \\servername.domain.com\share /USER:username" the solution would probably be to set the plaintext_password to "" when one or a combinaison of the 3 smb.conf parameters I've mentionned are set to "Yes" instead of raising reply_nterro,END_PROFILE,return but I will let you handle it the way you want.
Hi Yannick, thanks for recording that here. I will try to look at it in the next couple of days. Michael That occurred on AIX, right? (The os field in this case does not refer to the client os but the samba platform)
Hi Michael thanks for getting involved for this bug Yes the smbd server platform is AIX (5.2 or 5.3) pretty sure the same would happen on a different OS. This seems to be based on the choice of our samba configuration and client configuration using plaintext password, something that isn't a lot used in samba from what I've heard. But I don't have any easy choice with our authentication service (DCE) except this one.
Created attachment 3208 [details] client plaintext auth working back again since a commit in November (see bug 5342), the client plaintext auth wasn't working with a Windows client which had is registry set to send non-encrypted password. Windows seems to try an empty password first and this commit was ending the current profile so it wasn't letting do a second attempt with the plaintext password. My patch only add an if block which set the pass to "" instead of letting it NULL when using client plaintext auth and keep the same logic if it isn't set.
Created attachment 3209 [details] "encrypted passwords = no" instead this one makes more sense. Michael corrected me because client plaintext auth is a smb client parameter and not a server one. Checking the "encrypted passwords" parameter instead makes a lot more sense
Created attachment 3210 [details] smb.conf used This is the smb.conf I'm using to debug this problem. I've removed most of the share but kept the 3 mains dfs (/dfs) home (/dfs/home) projects (/dfs/projects)
Created attachment 3212 [details] debug level = 10 without the patch this is the output without the provided patch. On the client side, here is what I get C:\Documents and Settings\Administrator>net use * \\aix53tst.bromont.ibm.com\dfs /USER:yaberger System error 53 has occurred. The network path was not found. ---- with the patch, it works as expected and map the drive correctly
after checking the code, not sure I would go with my second patch for this reason: we are already in an else block where the if condition is "if (doencrypt)" the END_PROFILE has been put there for some reason. I must understand why I get this problem when Michael doesn't (after setting his Windows client to plaintext password)
I'm closing the bug. I've found that the result of this problem was because I was using a patch to rollback a change to support some old client running on MacOS9 with Dave3.1 smb client I'll put my effort on maybe creating a new arch (ex: RA_DAVE31) and adding it to the if block if (unic && (passlen2 == 0) && passlen1 && ra_type != RA_DAVE31) {