When LDAP is not enabled, and Kerberos, the sssd.conf file is being updated with Kerberos configurations. But the sssd daemon should not, and on CentOS 6 and 7 cannot run. So the first chef run enabling Kerberos fails because of an attempt to restart sssd, which is a disabled daemon due to the other settings made by authconfig.
You and I have discussed this before: it's still a confusing bug to most. Running chef twice because that ignores broken operations under the first run is not a good approach to configuring security related software.
When LDAP is not enabled, and Kerberos, the sssd.conf file is being updated with Kerberos configurations. But the sssd daemon should not, and on CentOS 6 and 7 cannot run. So the first chef run enabling Kerberos fails because of an attempt to restart sssd, which is a disabled daemon due to the other settings made by authconfig.
You and I have discussed this before: it's still a confusing bug to most. Running chef twice because that ignores broken operations under the first run is not a good approach to configuring security related software.