Avoid accounts being locked due to password changes in AD

[extrafu]

Issue: Alice has her password being changed by Windows administrator Zaymmitte. She forgets to change the password her password on her iPhone which uses WiFi/EAP-PEAP. After X failed logins from her iPhone, her account gets locked out and she sadly has to call Zaymmitte - who is likely busy bitching about manouches.

Solution:

1. you can enable N-x password history in AD - so AD will keep x previously used password and if one of them is being used, it will NOT lock the account (the WiFi connection will still be rejected)
2. if a wrong and unknown password is being sent (ie., brute-force attack or anything else), the badPwdCount attribue for the user will be incremented each time a wrong password is tried. It will be reset to 0 upon a successful "login"
3. one thing can be done, is to use a LDAP filter in FreeRADIUS prior doing the ntlm_auth call. This filter can check if the badPwdCount attribute is greater than a preferred value and if so, we reject the connection immediately. This will prevent from doing ntlm_auth calls with a bogus password and thus, potentially lock the account.
4. if we detect such cases in 3, we could always unconditionally accept the EAP-PEAP connection but raise a violation showing the captive portal page with password informations. This will not work for supplicants doing NT key/LM session key validations but for those who don't, they will at least see some instructions.

[louismunro]

This should be dealt with in Active Directory, using password history.

[extrafu]

I disagree - we should also consider no. 3 in my rationale above. We should put a sample in our RADIUS configuration, commented out, showing how and where it can be done. It should also be documented how to enable this in our official doc.

[julsemaan]

Lets state on a recipe and put it in place, I think @fdurand has something we could use so lets integrate it as a feature that can be enabled manually in an official release