From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.21; Mac_PowerPC) Description of problem: When authconfig is run and LDAP is configured, or nothing is changed at all (simply run with <next> and <ok>), it writes back krb5.conf and krb.conf even if those files were not selected/altered in authconfig. For krb4 sites the krb5.conf entries and krb.conf (v4) are merged into a new krb.conf with both, breaking clients. Version-Release number of selected component (if applicable): at least 4.2.8-4 How reproducible: Always Steps to Reproduce: 1. Have krb5 info in /etc/krb5.conf, krb4 info in /etc/krb.conf 2. run authconfig, select <next> and then <ok>. Exit. 3. /etc/krb.conf now contains krb5.conf information at the top Actual Results: kinit results in incorrect password after using authconfig. Files were altered by authconfig even though not toggled in the utility. Expected Results: requests should have been forwarded to Krb4 servers (which are now listed later in /etc/krb.conf). Specifically, authconfig read in Kerberos files and wrote them back EVEN THOUGH no changes were made. It should not do this. First detected when trying to set LDAP information, and Krb info was altered too! Additional info: For sites with site-wide configuration files (Stanford, MIT, UMich, etc) that still use Kerberos v4 as well as v5, the v4 applications now fail because krb.conf is munged. sample pre authconfig krb.conf file: IR.STANFORD.EDU auth1.stanford.edu admin server IR.STANFORD.EDU auth2.stanford.edu admin server IR.STANFORD.EDU auth3.stanford.edu admin server sample post authconfig krb.conf file: stanford.edu stanford.edu krb5auth1.stanford.edu:88 stanford.edu krb5auth2.stanford.edu:88 stanford.edu krb5auth3.stanford.edu:88 stanford.edu krb5-admin.stanford.edu admin server IR.STANFORD.EDU auth2.stanford.edu admin server IR.STANFORD.EDU auth3.stanford.edu admin server I consider this a security issue since it affects authorization systems. Once authconfig is run and ticket-grabbing background applications silently fail to acquire tickets during login, desktop network services assumed to be secure by end users may in fact be in clear text.
This is actually a feature of authconfig. A bad feature and I agree it should be fixed.
It is questionable if authconfig should mess with krb.conf at all. However at least it shouldn't overwrite it if no configuration changes were done in the Kerberos settings.
So I've finally fixed it. If no kerberos settings are changed the krb.conf (and krb5.conf) files aren't overwritten.