Bug 5342 - Can't authenticate with plaintext password
Can't authenticate with plaintext password
Status: RESOLVED INVALID
Product: Samba 3.2
Classification: Unclassified
Component: File services
3.2.0
PPC AIX
: P3 normal
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-20 13:19 UTC by Yannick Bergeron
Modified: 2008-04-18 11:36 UTC (History)
1 user (show)

See Also:


Attachments
client plaintext auth working back again (928 bytes, patch)
2008-03-25 08:11 UTC, Yannick Bergeron
no flags Details
"encrypted passwords = no" instead (928 bytes, patch)
2008-03-25 08:56 UTC, Yannick Bergeron
no flags Details
smb.conf used (1.32 KB, text/plain)
2008-03-25 09:11 UTC, Yannick Bergeron
no flags Details
debug level = 10 without the patch (11.19 KB, text/plain)
2008-03-25 09:58 UTC, Yannick Bergeron
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yannick Bergeron 2008-03-20 13:19:09 UTC
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.
Comment 1 Michael Adam 2008-03-20 18:34:12 UTC
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)
Comment 2 Yannick Bergeron 2008-03-20 21:37:49 UTC
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.
Comment 3 Yannick Bergeron 2008-03-25 08:11:47 UTC
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.
Comment 4 Yannick Bergeron 2008-03-25 08:56:51 UTC
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
Comment 5 Yannick Bergeron 2008-03-25 09:11:51 UTC
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)
Comment 6 Yannick Bergeron 2008-03-25 09:58:10 UTC
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
Comment 7 Yannick Bergeron 2008-03-27 08:31:02 UTC
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)
Comment 8 Yannick Bergeron 2008-04-18 11:36:04 UTC
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) {