I have use the following command to configure the password policy on the samba4.3 AD server. /usr/local/samba/bin/samba-tool domain passwordsettings set --account-lockout-threshold=3 If a user using windows 7 workstation logon to the samba server and type a wrong password only 1 time, the samba4 server will count the bad password attempt for 2 or 3 times, and the user account will be locked out. Would you please investigate this issue ?
I was able to reproduce it with Samba 4.3.3. Attached you'll find a tcpdump and samba log with debug level 12. I tested with testuser2.
Created attachment 11748 [details] windows7_login.pcap
Created attachment 11749 [details] log.samba.gz
Created attachment 11750 [details] ad_w2k8r2_windows7_login.pcap I've joined the Windows 7 client into a Windows 2008 R2 Microsoft based Active Directory domain. Attached you can find the Wireshark trace of a failed login at the Windows 7 client. The badPwdCount was correctly increased by 1.
Created attachment 11761 [details] Patch to return enc data on preauth failed The issue appears to be that in the preauth failed case, the e-data is not returned to the client. Failing to do so against Windows, causes it to reissue a second AS-REQ and resulting in a second failure (incrementing the password lockout count twice).
(In reply to Garming Sam from comment #5) In the capture windows only returns PA-ETYPE-INFO2 and no it returns no e-text in both replies. I think at least with the pa types we should match.
(In reply to Stefan Metzmacher from comment #6) The adjacent comment in the code regarding the types returned says: RFC4120 requires: - If the client only knows about old enctypes, then send both info replies (we send 'info' first in the list). - If the client is 'modern', because it knows about 'new' enctype types, then only send the 'info2' reply. Before we send the full list of etype-info data, we pick the client key we would have used anyway below, just pick that instead. The reason it doesn't return only info2 is possibly a wider issue. Andrew seemed to suggest the AES handling which Andreas picked up on in Heimdal. In which case, fixing it to return info2 may not be actually be all that desirable.
*** This bug has been marked as a duplicate of bug 11029 ***