Bug 1184639

Could you please attach the 'authconfig --test' output after the initial authconfig run and after the second run?

Created attachment 985334 [details]
authconfig --test output

authconfig --test output is identical before and after the authconfig --update run.  Looks like the realm is there from the start:

pam_krb5 is disabled
 krb5 realm = "#"

this was with 7.1 beta

Tomas, I see you got this bug to assigned state. Do you know what is the root cause then? What is the impact for IPA/IdM in RHEL?

There is a bug in authconfig when parsing the realms from krb5.conf when there is no realm configured.

Not sure about the impact for IPA.

I'd like to offer what I think is another manifestation of this:

Scenario: 

* You open authconfig-gtk to configure kerberos auth for the first time.
* You see the realm field prefilled with a hashmark (#)
* You assume that is supposed to stay, and you add your realm after it (e.g., "#EXAMPLE.COM")
* You apply changes and nothing works

In this scenario, sssd fails to start.

The problem is that using authconfig to put a hash at the beginning of your realm setting leads to this in krb5.conf:

    [libdefaults]
     default_realm = #EXAMPLE.COM
    [realms]
     #EXAMPLE.COM = {
      kdc = classroom.example.com
      admin_server = classroom.example.com
     }
    [domain_realm]
     #example.com = #EXAMPLE.COM
     .#example.com = #EXAMPLE.COM

From a little testing, it seems that that basically boils down to sssd seeing the following when it reads krb5.conf:

    [libdefaults]
     default_realm = 
    [realms]
      kdc = classroom.example.com
      admin_server = classroom.example.com
     }
    [domain_realm]
     .

So that's bad. Even worse is the fact that using authconfig to FIX this doesn't remove ANY of the bogus entries. For anyone having trouble following, here's what a run through on RHEL 7.0 looks like:

    [root@server0 ~]# yum install sssd krb5-workstation authconfig-gtk -y &>/dev/null
    [root@server0 ~]# rpm -q krb5-libs sssd authconfig
    krb5-libs-1.11.3-49.el7.x86_64
    sssd-1.11.2-65.el7.x86_64
    authconfig-6.2.8-8.el7.x86_64
    [root@server0 ~]# cp /etc/krb5.conf /etc/krb5.conf.orig
    [root@server0 ~]# systemctl status sssd
    sssd.service - System Security Services Daemon
       Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled)
       Active: inactive (dead)

    [root@server0 ~]# authconfig --enableldap --ldapserver=classroom.example.com --ldapbasedn=dc=example,dc=com --enableldaptls --ldaploadcacert=http://c/pub/example-ca.crt --enablekrb5 --krb5kdc=classroom.example.com --krb5adminserver=classroom.example.com --krb5realm='#EXAMPLE.COM' --update
    Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for details.
    [root@server0 ~]# diff /etc/krb5.conf.orig /etc/krb5.conf
    14a15
    >  default_realm = #EXAMPLE.COM
    20a22,26
    >  #EXAMPLE.COM = {
    >   kdc = classroom.example.com
    >   admin_server = classroom.example.com
    >  }
    > 
    23a30,31
    >  #example.com = #EXAMPLE.COM
    >  .#example.com = #EXAMPLE.COM
    [root@server0 ~]# cp /etc/krb5.conf /etc/krb5.conf.broken
    [root@server0 ~]# authconfig --enableldap --ldapserver=classroom.example.com --ldapbasedn=dc=example,dc=com --enableldaptls --ldaploadcacert=http://c/pub/example-ca.crt --enablekrb5 --krb5kdc=classroom.example.com --krb5adminserver=classroom.example.com --krb5realm='EXAMPLE.COM' --update
    Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for details.
    [root@server0 ~]# diff /etc/krb5.conf.broken /etc/krb5.conf15c15
    <  default_realm = #EXAMPLE.COM
    ---
    >  default_realm = EXAMPLE.COM
    26a27,31
    >  EXAMPLE.COM = {
    >   kdc = classroom.example.com
    >   admin_server = classroom.example.com
    >  }
    > 
    31a37,38
    >  example.com = EXAMPLE.COM
    >  .example.com = EXAMPLE.COM

In case it isn't obvious, that last authconfig command only added new valid entries; look closely at diff and you'll see the only thing it fixed was the old default_realm setting.

Also, to be clear, the only way to fix this is manually edit krb5.conf (or remove it and reinstall krb5-libs).

@Tomas and friends: let me know if you feel this warrants a separate bz.

I don't think it is really worth it to try to automatically undo the eventual damage that was done. I'd recommend creating a KB article to cover this.

@Tomas: Ok. I hear you. I can't help but point out that earlier versions of RHEL (and Fedora 22 alpha) did not prefill the realm field with hash mark ... I guess that's the point I'm trying to make.

I think this is rather a coincidence due to change of the contents of the default krb5.conf in the krb5 package. The routine that reads the file was not changed. So the bug was there in the authconfig code for long time but it did not manifest itself before.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2403.html