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.
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.
Created attachment 7359 [details] smb.conf Copy of the smb.conf showing the LDAP configuration etc.
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
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.
Interesting, seems to only fail when TS1$ tries to do a samlogon via tsbroker$. Is this a terminal server setup ?
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
Ok, and are you saying this is a regression from earlier releases ?
Yeah, this worked in 3.4.8
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).
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.
whatever the problem was 10 years ago, I haven't seen this issue in the last decade, closing this accordingly