Open michael-o opened 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.
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.
MIT Kerberos has removed the support for single-DES in 1.18 (fb2dada5eb89c4cd4e39dedd6dbb7dbd5e94f8b8) and result is:
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.