Improve the mechanism to reject devices using an old password

[julsemaan]

Is your feature request related to a problem? Please describe. When the password of a user gets changed, he needs to change it on all his devices using EAP-PEAP MSCHAPv2. If the user forgets to update a device, then it may lead to its account being locked.

Currently we have a cache that if a device uses the wrong password for X times in a timeframe, then we automatically reject the device for a configurable time T until we try to send it to the AD again. This means that if the user finally updates the device with the right password, he will have to wait until T has elapsed for his connection to work again.

Describe the solution you'd like The base of this mechanism is good but could use the following improvements:

• Use the security events to manage this mechanism where we'll stop sending it to the AD if a specific security event is opened
• That security event will auto-close and have grace time configuration so that should allow for easy configuration of this feature through the admin
• When the security event is opened, don't simply reject the request but try to hit the NTLM cache only (i.e. if the NTLM cache misses then we don't send it to the AD). That means the device will succeed if at least one of the user's device has previously authenticated with the right password while the NTLM cache is enabled.

Additional context Add any other context or screenshots about the feature request here.

[extrafu]

For this to work, NT hashes caching with AD needs to be enabled?

When would the security event be raised?

[julsemaan]

For this to work, NT hashes caching with AD needs to be enabled?

For the full flow to work (i.e. the user inputs the right password while the security event is opened), then yes it needs it. Without NT caching, the user will be denied until the security event auto-closes or gets closed by a PF admin

When would the security event be raised?

After X amount of failed NTLM authentications on the AD (ntlm_auth call) for the same sAMAccountName. Example, bob has a faulty password on 2 devices and the bad password threshold is 4, then after 2 failed auths from these 2 devices, both devices will stop authenticating. That way if the AD account locks at 5, then the user bob will never reach that threshold and the account will not lock in the AD

[extrafu]

Ok, if we track it correctly using ntlm_auth's exit code - I guess it has one specific for wrong password (versus other issues).

If at that point we still accept the connection using the NTLM cache, I think it's worth considering these options, configurable of course:

1- showing the portal by accepting the connection in the quarantine VLAN and showing a remediation page 2- sending a mail to the user, if we have an associated email address in the person table

Makes sense?

[julsemaan]

Ok, if we track it correctly using ntlm_auth's exit code - I guess it has one specific for wrong password (versus other issues).

That should be possible, perhaps with the code in the stdout output which may offer more precision. We could make this configurable since it could offer more flexibility as to what triggers this event

If at that point we still accept the connection using the NTLM cache, I think it's worth considering these options, configurable of course:

1- showing the portal by accepting the connection in the quarantine VLAN and showing a remediation page

We can't accept the NTLM connection if the password in the NTLM cache doesn't match the one in the request. We would need to track X previous hashes to be able to match this which requires a rework of our NTLM cache plumbing and we'll need to make sure the cache expiration is high for these entries (may lead to larger mem usage but shouldn't be problematic)

2- sending a mail to the user, if we have an associated email address in the person table

That can be done and all AD users should have their email in the table since it's looked up via LDAP after a successful connection. We also already have the plumbing in the security events to make it happen without additional code.

[nqb]

Approach looks good to me. However, it's not completely clear to me what code will do if a user connect with a bad password and we see a recent success in NTLM cache.

[julsemaan]

Approach looks good to me. However, it's not completely clear to me what code will do if a user connect with a bad password and we see a recent success in NTLM cache.

I'm not sure I really understand your concern

[nqb]

In following scenario:

1. NTLM cache enabled
2. Device 1 owned by userA is doing 802.1X with userA and a correct password: authentication succeed
3. Device 2 owned by userA is doing 802.1X with userA and a bad password

Two questions:

1. How PacketFence will handle third step with your implementation ?
2. What will be the difference when NTLM is disabled ?

[julsemaan]

In following scenario:

1. NTLM cache enabled
2. Device 1 owned by userA is doing 802.1X with userA and a correct password: authentication succeed
3. Device 2 owned by userA is doing 802.1X with userA and a bad password

Two questions:

1. How PacketFence will handle third step with your implementation ?

Let's say the device will authenticate continously for the purpose of our example and we set the AD hit limit to 3

1. Request 1, bad password, try the NTLM cache (miss), try the AD (fail)
2. Request 2, bad password, try the NTLM cache (miss), try the AD (fail)
3. Request 3, bad password, try the NTLM cache (miss), try the AD (fail)
4. 3 failed attempts for the same device, open the security event
5. Request 4, bad password, try the NTLM cache (miss), security event is opened do not try the AD
6. Request 5, bad password, try the NTLM cache (miss), security event is opened do not try the AD
7. User fixes his password in the device after X time
8. Request X, good password, try the NTLM cache (hit), security event is closed
9. Request X+1, good password, try the NTLM cache (hit)
10. User changes his password again after Y time and immediately adjusts it in the device
11. Request Y, good password, try the NTLM cache (miss), try the AD (hit)
12. Request Y+1, good password, try the NTLM cache (hit), try the AD (miss)

2. What will be the difference when NTLM is disabled ?

The device will not be able to authenticate until the security event auto-closes or a PF admin closes the security event through the web admin. Needless to say the usability is way better with NTLM enabled

One other important thing is that if the user has only one device and this device gets the security event opened, it will be important to populate the NTLM cache at that moment so that when the user does fix his password, he can hit the cache. This won't be a problem if he has 1 device with the correct new password and 1 device with the wrong old password since the device with the new password will get the NTLM cache populated. Nonetheless, this needs to be handled