I'm not sure which tools there are, but I do have some recommendations to better ensure security even with weaker passwords. First of all, use pre-authentication if at all possible. That's a flag set in the Kerberos database on principals and can be configured to be default on new principals. Without pre-authentication, someone could request a Kerberos ticket without knowing the users password. While they can't use it yet, they can store it off-line and repeatedly try to decrypt this ticket which various passwords until they are successful. Most likely the ticket will have expired by then, but the password won't have. They can now request another ticket knowing the users password. Pre-auth requires proof of knowledge of the password before the Kerberos server will offer up a ticket for the user to decrypt.
Second, be aware of what algorithms and salts you allow for Kerberos. Each algorithm has a different string-to-key function which is how a password is turned into. The more complicated the string-to-key function, the harder it is to brute-force. Generally, the AES encryptions have a much better string-to-key algorithm. This is separate from the fact that AES itself is better encryption. Even if clients only request AES encryption, if the the Kerberos stores DES or 3DES keys for the user, they might be able to be requested making brute force easier. Also, you want to make sure you only use v5 salts. Older Kerberos used no salt (sometimes called v4 salt) and DES encryption. If you are not using a salt, then a simple pre-generated lookup table of passwords and their encryption keys can be used to brute-force a password. The salt adds a unique value, the users name and realm to their password to ensure that their encryption keys are unique even for the same password an another user or realm.
