In retrospect, it seems reasonable that authconfig would need to write to sssd.conf. Unfortunately, sssd.conf does not have a big banner at the top warning that the file will be overwritten. It would be very helpful if there were such a warning and if it gave a clear description of where and how users are intended to make custom settings if needed.
Given authconfig uses the SSSD config API, what would be the best way to add this comment to sssd.conf? I suppose the config API itself does not have calls for adding comments. Perhaps it should be added to the default config file in the sssd package?
Maybe we should rename the "default" domain to "default-ac" or "authconfig" domain. That should make it clear. The idea is that if a customer wants to create a custom domain, they should do so by changing the domain name. We thought "default" would be sufficient, but now I'm thinking it would make more sense if we used a less-ambiguous name. Additionally, I think you're right that we should add a new config option "description" that has no purpose in the SSSD itself, but could be used by authconfig to add a notice that the domain was autoconfigured and could be changed by subsequent executions of authconfig. This would be better than changing the default config file. I've actually been thinking about renaming the default config file to sssd-example.conf so that SSSD doesn't try to use it (since it intentionally doesn't work out of the box anyway). The SSSDConfig API (and by extension, authconfig) can create an empty file trivially. Tomas, please use this BZ to track changing the default domain name to something more clear, and then please clone this ticket against the SSSD for me to add the 'description' option and change the example config name.
Unfortunately, authconfig can add a default domain that is very similar a pre-existing custom domain. For example, after running authconfig, I had to remove the "default" domain and restart sssd. I think there needs to be a warning message so that people know that the file might get modified.
But if you do not want to use authconfig for configuring sssd.conf at all, just use 'authconfig --enablesssd --enablesssdauth --update'. This will make it to enable it explicitly in system-auth and nsswitch.conf but it will not try to configure domains in sssd.conf. This is described in 'man authconfig'.
Unfortunately, to get authconfig to write out the ecryptfs-related pam configuration, the recommended solution is to add "USEECRYPTFS=yes" to /etc/sysconfig/authconfig and run "authconfig-tui --updateall": http://fedoraproject.org/wiki/Features/EcryptfsAuthConfig There may be other features that require this as well. I'm not aware of a "--updatepam" option or anything like that. Of course, it's possible that there is some other combination of settings that would make "--updateall" work without rewriting sssd config files, but if I had known to expect it, I wouldn't have been very bothered.
I've decided to not change this as this brings only a very little improvement but it has potential for breaking existing user configurations and expectations. The 'default' name is there for many Fedora releases and also in RHEL-6 so it should be now quite firmly established.