The scenario:
- There are a lot of SLES 11 SP3 servers in the customers environment.
- The SLES servers are configured to authenticate AD users using Kerberos.
- Winbind has been configured to cache successful Kerberos authentications and configured with winbind refresh tickets.
- This is configured and working.
- It will continue to work in their environments until they change a working users password in AD.
- That change appears to be ok at first, but eventually that users account in AD will get locked.
- When that happens the Windows AD servers log files will blame one of the SLES servers for attempting too many invalid authentication attempts.
- To the AD users knowledge they may not have even accessed that SLES server that day with that user.

This sounds to me like this SLES server is using old cached information.

I believe the problem is in krb5_ticket_refresh_handler(), where winbind will attempt a password kinit if the user's ticket is no longer renewable.
When winbind refresh tickets is enabled, and the ticket is expired (and can't be renewed), we kinit the user using the cached password (without checking the usnChanged attribute to see if the cached creds are valid). If our cached creds are invalid, the kinit triggers a wrong password attempt. This happening from multiple machines could be what is locking out the users.

I think we should add an option for enabling the password kinit (so that it is disabled by default). We could also track the user's usnchanged ldap attribute to determine whether the cached password is valid.