Winbindd 3.0.20 does not enjoy getting zero length user names from ntlm_auth
3.0.20 -- after a blank user name winbind no longer responds to ntlm_auth (even
after restarting ntlm_auth). This makes ntlm_auth rather unstable, because
people love to enter blank user names. Here's a scriptlet to reproduce the
# winbind in fg debugging mode, single process, no caching:
winbindd -i -F -S -d 10 -Y -n
# Try a good password, a blank user, then the same good password
echo angelo password
echo ' peep' # note the blank user name
echo angelo password
} | ntlm_auth --helper-protocol=squid-2.5-basic
Winbind log for the above at
ftp://pepper.on.dyn.ledge.co.za/ntlm-auth-kills-winbindd (not for long though)
I've made an *incorrect* workaround patch for ntlm_auth, because I don't know
how to fix this in winbind:
# this is like a patch, just not as clear ...
- fstrcpy(request.data.auth.user, user);
+ fstrcpy(request.data.auth.user, *user ? user : "BOGUS");
That prevents the problem for basic authentication, but does not solve the
underlying problem with winbind crashing.
Are you using Samba 3.0.14 or less as a Domain Controller? If yes, we have fixed
a bug in winbind after 3.0.20 that would prevent logons after any invalid logon
attempt. Even a wrong password kills the connection to the DC. Your logfile
strongly indicates that this is the case.
If your DC really is 3.0.14, please try the current SAMBA_3_0_RELEASE branch in
subversion, this will be 3.0.20a with the fixes.
The domain controller was upgraded from 3.0.14 to 3.0.20, and following this
upgrade, it was not possible to run ntlm_auth against it (from the proxy
server). While an invalid user name (except '') does not hurt winbindd, a
valid user name with an invalid password does also cause winbindd to stop
working. Is this the same bug?
Hmmm. A 3.0.20 winbind/ntlm_auth is not able to authenticate against a 3.0.20
PDC? I have not seen that yet, the only combination that failed for me is
3.0.20/3.0.earlier. You might try to upgrade both to 3.0.20a that will be
3.0.20a changes the behaviour to the following:
proxy:~# winbindd -i -F -S -d 10 -Y -n >& x & ntlm_auth
PDC is Samba 3.0.20 on Debian/amd64 (em64t).
winbind 3.0.20a log (temporarily) at
I see that in the winbindd log, just before "NT_STATUS_ACCESS_DENIED" the
following is logged --
challenge : 0000000000000000
credentials check wrong
DC sent wrong credentials
Winbind is blaming the DC for the problem, but I reckon that having a zero
challenge record is a little fishy. (Thought I'd say, just in case.)