Description of problem: Fresh ScientificLinux 7.0 install. Initial authconfig is: authconfig --enablemd5 --enableshadow --disablefingerprint --enableldap --enableldapauth --ldapserver=server1,server2 --ldapbasedn=dc=domain,dc=com --enableldaptls --ldaploadcacert=http://url/ --disablefingerprint with an extra: /usr/sbin/authconfig --update --nostart --ldaploadcacert=http://url/ Results in /etc/sssd/sssd.conf: [domain/default] autofs_provider = ldap cache_credentials = True krb5_realm = # This krb5_realm = # then causes more problems later when configuring /etc/krb5.conf. Version-Release number of selected component (if applicable): authconfig-6.2.8-8.el7.x86_64 Additional info: https://fedorahosted.org/freeipa/ticket/4859
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