Bug 5342 - Can't authenticate with plaintext password
Summary: Can't authenticate with plaintext password
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.0
Hardware: PPC AIX
: P3 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2008-03-20 13:19 UTC by Yannick Bergeron (mail address dead)
Modified: 2008-04-18 11:36 UTC (History)
1 user (show)

See Also:

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

Note You need to log in before you can comment on or make changes to this bug.
Description Yannick Bergeron (mail address dead) 2008-03-20 13:19:09 UTC

Since the following commit, the plaintext authentication is not working. the "if (! pass)" block is probably the cause of the problem.

Michael Adam already committed something that fix it for security = share

but the problem is also occuring with security = user
Our Windows XP have the following registry parameter, allowing them to work in plaintext password

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.


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 (mail address dead) 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 (mail address dead) 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 (mail address dead) 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 (mail address dead) 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 (mail address dead) 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 (mail address dead) 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 (mail address dead) 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) {