msktutil / msktutil

Msktutil creates user or computer accounts in Active Directory, creates Kerberos keytabs on Unix/Linux systems, adds and removes principals to and from keytabs and changes the user or computer account's password.
GNU General Public License v2.0
56 stars 19 forks source link

Handle the absence of single-DES #172

Open michael-o opened 3 years ago

michael-o commented 3 years ago

MIT Kerberos has removed the support for single-DES in 1.18 (fb2dada5eb89c4cd4e39dedd6dbb7dbd5e94f8b8) and result is:

Error: krb5_c_string_to_key failed (falscher Verschlüsselungstyp)

The entire process stops. Both MIT Kerberos and Heimdal (via MIT glue) offer krb5_c_valid_enctype(krb5_encytpe) to test whether an encryption type is supported. Note that testing for the ENCTYPE macro will not work because it is always present. There are now two ways to solve this: at configure time try to detect and set a macro which will remove DES-related code or do it at runtime and issue warnings/error if DES is requested.

Since we do AES checking at configure time we should either do it at configure time too or move both to runtime.

dkobras commented 3 years ago

Which behaviour would you deem appropriate here? AFAICS we add DES keys only if they've been explicitly requested by a command-line option, configured for the account in AD, or present in the keytab already. In any case, users would expect msktutil to update the DES keys. If we're unable to do so, failing with an error looks like the proper reaction to me. Do you agree, or would you rather see a more graceful behaviour here?

Since we do AES checking at configure time we should either do it at configure time too or move both to runtime.

The AES configure check prevents actual compile-time errors, whereas krb5_c_valid_enctype() would be used to prevent a runtime error. Hence, I'd rather keep them separate from each other.

michael-o commented 3 years ago

I prefer a runtime check with failure (exit_code != 0) to explicitly signal to cronjobs or alike that DES is not available. msktldap.cpp and msktkrb5.cpp are affected. I noticed this because my domain admin account was not entitled to write msDS-supportedEncryptionTypes (for unrelated reasons). I hope no one uses DES anymore.