Bug 4697 - Cannot specify a user name in smb.conf if smbpasswd file does not contain that user
Summary: Cannot specify a user name in smb.conf if smbpasswd file does not contain tha...
Status: ASSIGNED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Config Files (show other bugs)
Version: 3.0.25a
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 4678
Blocks:
  Show dependency tree / graph
 
Reported: 2007-06-14 04:31 UTC by WS Chan
Modified: 2007-06-17 22:03 UTC (History)
1 user (show)

See Also:

Attachments
Patch (2.05 KB, patch)
2007-06-17 14:20 UTC, Jeremy Allison 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description WS Chan 2007-06-14 04:31:03 UTC 
We used security = server to authenticate with an Active Directory server:
security = server
password server = NAME_OF_AD_SERVER
workgroup = DOMAIN_NAME_OF_AD

and we left the smbpasswd file empty.

With 3.0.25a, listing individual user names in parameters such as 'valid users' and 'printer admin' was no longer effective, but specifying UNIX groups using the '+group' or '@group' syntax still worked.

After a few trials, we found that when we added the user names in the smbpasswd file, listing them in 'valid users' and 'printer admin' parameters worked again.
Comment 1 Tomasz Fortuna 2007-06-17 05:55:57 UTC 
That behavior you experience is almost exactly the same as in bug 4678, but I doubt if the fix proposed in that bug will cover this bug...

Maybe Jeremy will be able to cover both bugs with a single patch
Comment 2 Jeremy Allison 2007-06-17 14:20:13 UTC 
Created attachment 2766 [details]
Patch

This patch should fix bug #4678 and not cause any backwards compatibility problems in environments with plaintext passwords and no backend SAM. Let me know - in testing this I discovered some minor memory leaks in our auth subsystem but I'll fix these for 3.0.26, too dangerous for 3.0.25b. I think this is safe though.
Jeremy.