Bug 9561 - Samba 3.6.10 as domain member is no longer recognizing valid users
Samba 3.6.10 as domain member is no longer recognizing valid users
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: Winbind
3.6.10
All All
: P5 major
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-14 18:32 UTC by Chris Smith
Modified: 2013-02-06 20:00 UTC (History)
0 users

See Also:


Attachments
log, wbinfo, getent, conf (3.33 KB, application/x-bzip)
2013-01-14 18:32 UTC, Chris Smith
no flags Details
new full level 10 log (397.56 KB, text/plain)
2013-01-14 20:38 UTC, Chris Smith
no flags Details
new log files without log filename redirect (65.98 KB, application/x-bzip2)
2013-01-14 20:53 UTC, Chris Smith
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Smith 2013-01-14 18:32:27 UTC
Created attachment 8425 [details]
log, wbinfo, getent, conf

After upgrade from Samba 3.5.15 to 3.6.10 there is a serious auth issue.

Samba 3.6.10 as domain member to NT4 PDC is no longer recognizing valid users for shares. Even the "Domain Admins" are denied access to shares.

The file proserver.log in the attachment shows the Administrator logging on to the PDC and then trying to connect to a share with a valid users line that includes the Domain Admins group yet is authenticated as the guest user and is denied access.
Comment 1 Volker Lendecke 2013-01-14 20:05:20 UTC
We need the client specific log file, not the general smbd one.
Comment 2 Chris Smith 2013-01-14 20:16:59 UTC
That is the log file of the client machine (the PDC in this case).
Comment 3 Chris Smith 2013-01-14 20:25:52 UTC
It was created with:
log level = printdrivers:0 lanman:10 rpc_parse:0 rpc_srv:0 rpc_cli:0 smb:10 tdb:10 sam:4 passdb:10 registry:0 auth:10 vfs:1 idmap:10 winbind:10 quota:0 acls:4 locking:2 msdfs:0
Comment 4 Volker Lendecke 2013-01-14 20:28:05 UTC
To me it seems that you have "log file = <something>.%m" or so somewhere in your smb.conf. This will redirect the logfile before the interesting piece.
Comment 5 Volker Lendecke 2013-01-14 20:29:16 UTC
Ah, and please do not play with debug modules. This will just confuse anybody trying to debug this defect.
Comment 6 Chris Smith 2013-01-14 20:38:26 UTC
Created attachment 8426 [details]
new full level 10 log

This is a full level 10 log from another member server. I logged onto the PDC (PROSERVER) as the administrator and attempted to connect to a share on the member server (HAWKING) that lists Domain Admins as valid users. Instead of connecting a credentials prompt was displayed.
Comment 7 Chris Smith 2013-01-14 20:41:27 UTC
(In reply to comment #4)
> To me it seems that you have "log file = <something>.%m" or so somewhere in
> your smb.conf. This will redirect the logfile before the interesting piece.

Yes, I use:
log file = /var/log/samba/%m.log

As I find it easier to deal with *.log instead of log.* - will this create a problem for you?
Comment 8 Chris Smith 2013-01-14 20:53:43 UTC
Created attachment 8427 [details]
new log files without log filename redirect

OK, did this with no log filename redirect and full log level 10. This attachment contains all of the log files created. Interestingly no client specific log file was created.
Comment 9 Chris Smith 2013-01-14 23:28:27 UTC
If you need anything else please let me know. I have full reign until the morning with the systems (office is closed for the night).
Comment 10 Chris Smith 2013-01-18 14:30:08 UTC
Anything else required?
Comment 11 Chris Smith 2013-01-30 22:39:15 UTC
Looking for some traction on this issue. What else can I provide that will assist?

Thanks.
Comment 12 Christian Ambach 2013-02-05 19:17:34 UTC
Does this only affect the WARGAMES\Administrator user or all users?

I am asking because WARGAMES\Administrator is mapped to root in your setup
Comment 13 Chris Smith 2013-02-06 20:00:25 UTC
(In reply to comment #12)
> Does this only affect the WARGAMES\Administrator user or all users?
> 
> I am asking because WARGAMES\Administrator is mapped to root in your setup

It doesn't affect another user that is a Domain Admin and if I remove the map in smbusers it doesn't affect the user "Administrator". But somehow I never had that issue previously.