Bug 8793 - Rejecting auth messages in syslog and randomly unable to logon on workstations
Rejecting auth messages in syslog and randomly unable to logon on workstations
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: Domain Control
x64 Linux
: P5 critical
: ---
Assigned To: Guenther Deschner
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-03-05 10:55 UTC by Wilco Baan Hofman
Modified: 2012-03-13 14:39 UTC (History)
1 user (show)

See Also:

Log file of the interaction between 2003 server and 3.6.1 as DC (44 bytes, text/plain)
2012-03-05 13:05 UTC, Wilco Baan Hofman
no flags Details
smb.conf (1.92 KB, application/octet-stream)
2012-03-05 13:15 UTC, Wilco Baan Hofman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wilco Baan Hofman 2012-03-05 10:55:27 UTC
Samba 3.6.1 has a problem with rejecting authentications on all of our servers.

For Windows Server 2008 it seems to reject the workstation credentials on logon a few times before being able to logon, pretty consistently. For Windows XP it's more of a random thing. After samba runs for a while, some workstations become unable to logon.. it seems to get increasingly worse, until samba is restarted and the problems go away. I've not seen this behaviour with 3.2.5, 3.4.8 or 3.5.6, not unless the workstations domain password is incorrect.

I've tried to attach gdb to the process rejecting the authentication, I can see that the hashes it computes indeed do not match, but I can't seem to find where it would go wrong.
Comment 1 Wilco Baan Hofman 2012-03-05 13:05:01 UTC
Created attachment 7358 [details]
Log file of the interaction between 2003 server and 3.6.1 as DC

Attached a log file where the samba server is incorrectly rejecting authentications made by Windows Server 2003.
Comment 2 Wilco Baan Hofman 2012-03-05 13:15:53 UTC
Created attachment 7359 [details]

Copy of the smb.conf showing the LDAP configuration etc.
Comment 3 Wilco Baan Hofman 2012-03-05 13:20:22 UTC
Computer User in LDAP (hash is relevant for the debug, but not really secret):

# tsbroker$, Computers, andolan
dn: uid=tsbroker$,ou=Computers,dc=andolan
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: sambaSamAccount
cn: tsbroker$
uid: tsbroker$
uidNumber: 10006
gidNumber: 10002
homeDirectory: /dev/null
loginShell: /bin/false
description: Computer
gecos: Computer
sambaSID: S-1-5-21-2969752157-892696647-4271518216-101018
displayName: TSBROKER$
sambaAcctFlags: [W          ]
sambaNTPassword: 2F289948F19B02086E1D88C20DA8C28B
sambaPwdLastSet: 1325407019
Comment 4 Andreas Schneider 2012-03-09 13:04:07 UTC
I just did a quick look, I don't see any idmapping config in the smb.conf and a lot of failures of creating uid/gid and mapping users/groups.
Comment 5 Guenther Deschner 2012-03-13 13:48:37 UTC
Interesting, seems to only fail when TS1$ tries to do a samlogon via tsbroker$. Is this a terminal server setup ?
Comment 6 Wilco Baan Hofman 2012-03-13 14:26:21 UTC
Yes, this is a terminal server setup. It also seems to fail a few times in some other cases, like on terminal server logon.. but also in XP after a while. 

The logs are actually from a failure that's the easiest to trigger; adding the terminal server to a session directory, but the same principles apply to all the situations
Comment 7 Guenther Deschner 2012-03-13 14:27:52 UTC
Ok, and are you saying this is a regression from earlier releases ?
Comment 8 Wilco Baan Hofman 2012-03-13 14:29:48 UTC
Yeah, this worked in 3.4.8
Comment 9 Wilco Baan Hofman 2012-03-13 14:32:11 UTC
To be clear, we use ntlm_auth / winbind on the pdc, so I can't really test 3.5.x. 3.4.8 has some annoying inotify fd issues where smbd gets stuck in a loop, so that version is also not really an option (although that one could be used for testing).
Comment 10 Wilco Baan Hofman 2012-03-13 14:39:27 UTC
And there's another simple way to trigger the bug actually..

logging on from a 2008 terminal server.. you get a rejecting auth message a couple of times before the logon succeeds, this also worked in 3.4.8 without the rejecting authentication errors.