= Proposed Self Contained Change: Authselect: new tool to replace authconfig = https://fedoraproject.org/wiki/Changes/Authselect
Change owner(s): * Pavel Březina pbrezina@redhat.com
Authselect is a tool to select system authentication and identity sources from a list of supported profiles.
It is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it would ship several tested stacks (profiles) that solve a use-case and are well tested and supported. At the same time, some obsolete features of authconfig would not be supported by authselect.
This tool aims to be first shipped along and later deprecate and later replace authconfig in a future Fedora release.
== Detailed Description ==
Authselect will allow the administrator to choose one of the supported profiles. A profile provides description of how the resulting pam and nsswitch configuration looks like. The tool will be packaged with a default profile set that will be fully supported. If an administrator has different needs they can create a custom profile and make it accessible by authselect by dropping it in the tool directory.
The authentication and identity configuration is hardcoded within the profile. However each profile is also allowed to contain some conditional modules that can be either enabled or disabled to allow the administrator to enable some optional behaviour such as password policy or ecryptfs support.
Authselect will not configure daemons that provide the selected identity and authentication services such as SSSD or winbind, it will only configure pam and nsswitch. Daemons must be configured manually or through other system tools like realmd or ipa-client-install.
The default profile set will contain the following profiles:
Local users + SSSD -- local users and remote users are handled by sssd Local users + SSSD + Fingerprint -- same as above but also pam_fprintd is enabled Local users + winbind -- local users are handled by files and remote users by winbind Local users + winbind + Fingerprint -- same as above but also pam_fprintd is enabled
We do not want to support nss-pam-ldapd and pam_krb5 in default profiles since their use-cases are completely or almost completely covered by SSSD. SSSD can be used as a complete replacement for pam_krb5 and there are only few old and rarely used maps for LDAP that remain unimplemented within SSSD such as hosts and aliases. These maps will be added in a future SSSD version.
== Scope == * Proposal owners: implement the change * Other developers: N/A (not a System Wide Change) * Release engineering: [1] (a check of an impact with Release Engineering is needed) * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change)
[1] https://pagure.io/releng/issue/6907
Jaroslav
On 18/07/17 14:48, Jaroslav Reznik wrote:
The default profile set will contain the following profiles:
Local users + SSSD -- local users and remote users are handled by sssd Local users + SSSD + Fingerprint -- same as above but also pam_fprintd is enabled Local users + winbind -- local users are handled by files and remote users by winbind Local users + winbind + Fingerprint -- same as above but also pam_fprintd is enabled
No "local only" profiles for people that don't need sssd?
What is the effect of this on configurations that haven't been using sssd at all? Is everything going to suddenly start blocking/timing out on being unable to talk to it?
Tom
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes tom@compton.nu wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote:
The default profile set will contain the following profiles:
Local users + SSSD -- local users and remote users are handled by sssd Local users + SSSD + Fingerprint -- same as above but also pam_fprintd is enabled Local users + winbind -- local users are handled by files and remote users by winbind Local users + winbind + Fingerprint -- same as above but also pam_fprintd is enabled
No "local only" profiles for people that don't need sssd?
What is the effect of this on configurations that haven't been using sssd at all? Is everything going to suddenly start blocking/timing out on being unable to talk to it?
Starting with F26, the default configuration is for all setups to be using SSSD. See https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
This is actually advantageous, since the previous behavior was that all access to local users previously had to hit the disk (unless nscd was manually configured). If SSSD isn't responding, nsswitch will fail back to the old behavior fairly quickly.
Also, the authselect stuff *puts* the configuration into place. If you don't want your configuration to change, don't call authselect. (Even if you do, it will detect that you have a manual configuration and won't change anything unless you pass a "force" option).
On 18/07/17 15:12, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote: > The default profile set will contain the following profiles: > > Local users + SSSD -- local users and remote users are handled by sssd > Local users + SSSD + Fingerprint -- same as above but also pam_fprintd > is enabled > Local users + winbind -- local users are handled by files and remote > users by winbind > Local users + winbind + Fingerprint -- same as above but also > pam_fprintd is enabled No "local only" profiles for people that don't need sssd? What is the effect of this on configurations that haven't been using sssd at all? Is everything going to suddenly start blocking/timing out on being unable to talk to it?Starting with F26, the default configuration is for all setups to be using SSSD. See https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Well none of my newly upgraded F26 machines appear to be running it ;-)
This is actually advantageous, since the previous behavior was that all access to local users previously had to hit the disk (unless nscd was manually configured). If SSSD isn't responding, nsswitch will fail back to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too annoying...
Tom
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes tom@compton.nu wrote:
On 18/07/17 15:12, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote: > The default profile set will contain the following profiles: > > Local users + SSSD -- local users and remote users are handled by sssd > Local users + SSSD + Fingerprint -- same as above but also pam_fprintd > is enabled > Local users + winbind -- local users are handled by files andremote
> users by winbind > Local users + winbind + Fingerprint -- same as above but also > pam_fprintd is enabled No "local only" profiles for people that don't need sssd? What is the effect of this on configurations that haven't been using sssd at all? Is everything going to suddenly start blocking/timingout
on being unable to talk to it?Starting with F26, the default configuration is for all setups to be using SSSD. See https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
This is actually advantageous, since the previous behavior was that all access to local users previously had to hit the disk (unless nscd was manually configured). If SSSD isn't responding, nsswitch will fail back to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too annoying...
SSSD's caching is a lot more reliable for local users than nscd, as it monitors all of the relevant files with inotify and will immediately flush its cache anytime a change occurs to those files. It also does a full cache when this happens, rather than on-demand, so the only time there should ever be a lag here is on a request the instant between when a change is made on the disk and SSSD reloads it (during this time, SSSD just doesn't cache at all and passes the request on to nss_files.so to answer straight from the disk).
Also, the SSSD cache in use isn't strictly dependent on the SSSD daemon running; if SSSD was to crash and be in the middle of restarting, the memory-mapped fast cache will continue on independently. So in theory, there really shouldn't be any downside to this change (and I encourage you to tweak your upgraded boxes to use the new configuration).
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing nsswitch.conf however, so running "authconfig --updateall" to rebuild the configuration would have disabled it.
> This is actually advantageous, since the previous behavior was that all > access to local users previously had to hit the disk (unless nscd was > manually configured). If SSSD isn't responding, nsswitch will fail back > to the old behavior fairly quickly. I normally disabled nscd as well because the caching was just way too annoying...SSSD's caching is a lot more reliable for local users than nscd, as it monitors all of the relevant files with inotify and will immediately flush its cache anytime a change occurs to those files. It also does a full cache when this happens, rather than on-demand, so the only time there should ever be a lag here is on a request the instant between when a change is made on the disk and SSSD reloads it (during this time, SSSD just doesn't cache at all and passes the request on to nss_files.so to answer straight from the disk).
Also, the SSSD cache in use isn't strictly dependent on the SSSD daemon running; if SSSD was to crash and be in the middle of restarting, the memory-mapped fast cache will continue on independently. So in theory, there really shouldn't be any downside to this change (and I encourage you to tweak your upgraded boxes to use the new configuration).
I never really bothered with sssd because I understood it's purpose to be caching network users for disconnected use and I as I don't use network users anywhere, let alone on machines that need to continue working when disconnected, it didn't seem worth learning about.
I have now tried enabling it on another machine and we'll see how that goes...
Tom
On Tue, Jul 18, 2017 at 08:30:57PM +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing
The default nsswitch.conf is owned by libc, which, if I remember the discussions with Florian earlier is also not deemed ideal.
nsswitch.conf however, so running "authconfig --updateall" to rebuild the configuration would have disabled it.
I would say this is a bug in authconfig (and by the way, this is one of the reasons curated and tested NSS/PAM stacks would be more reliable than generating the stack based on user input where more or less anything goes..)
On 18/07/17 20:43, Jakub Hrozek wrote:
On Tue, Jul 18, 2017 at 08:30:57PM +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing
The default nsswitch.conf is owned by libc, which, if I remember the discussions with Florian earlier is also not deemed ideal.
nsswitch.conf however, so running "authconfig --updateall" to rebuild the configuration would have disabled it.
I would say this is a bug in authconfig (and by the way, this is one of the reasons curated and tested NSS/PAM stacks would be more reliable than generating the stack based on user input where more or less anything goes..)
Well I'm just going by USESSSD=no in /etc/sysconfig/authconfig...
Interestingly something had changed that file in other ways - the default one installed by authconfig doesn't even have shadow enabled but my laptop had it enabled so anaconda had presumably run authconfig --enableshadow or something.
I agree that I'm no fan of authconfig but I've been in the habit of running --updateall when I get rpmnew files for nsswitch or the pam files that it generates which is fairly common on a upgrade to a new Fedora version.
Tom
On Tue, 2017-07-18 at 20:30 +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing nsswitch.conf however, so running "authconfig --updateall" to rebuild the configuration would have disabled it.
That would be most probably authconfig bug, could you please report it, ideally with steps to reproduce?
The contents of the /etc/nsswitch.conf should have priority over /etc/sysconfig/authconfig. I already have RFE for authconfig to basically keep /etc/sysconfig/authconfig only as a hint and diminish its use. Unfortunately I have not had time to work on that yet.
On 19/07/17 09:01, Tomas Mraz wrote:
On Tue, 2017-07-18 at 20:30 +0100, Tom Hughes wrote:
On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
Well none of my newly upgraded F26 machines appear to berunning it ;-)
I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually editing nsswitch.conf however, so running "authconfig --updateall" to rebuild the configuration would have disabled it.
That would be most probably authconfig bug, could you please report it, ideally with steps to reproduce?
The contents of the /etc/nsswitch.conf should have priority over /etc/sysconfig/authconfig. I already have RFE for authconfig to basically keep /etc/sysconfig/authconfig only as a hint and diminish its use. Unfortunately I have not had time to work on that yet.
Oh in that case there might not be a bug. I didn't actually try it but I assumed that authconfig would rebuild the rules based on it's configuration rather then preserving what is already there which would seem to defeat the object of it?
Hmm actually having tried it my assumption appears to have been correct as sss has been removed from nsswitch.conf.
I'll file a bug...
Tom
"JR" == Jaroslav Reznik jreznik@redhat.com writes:
JR> At the same time, some obsolete features of authconfig JR> would not be supported by authselect.
I have a couple of concerns about this.
First, this seems to impact anaconda/kickstart since the "authconfig" line basically _is_ an authconfig command line.
Secondly, what would replace a call like:
authconfig --enableldap --ldapbase=dc=whatever --ldapserver=ldaps://ldap1.whatever,ldaps://ldap2.whatever,ldaps://ldap3.whatever --enablekrb5 --krb5realm=WHATEVER --krb5kdc=kerberos1.whatever,kerberos2.whatever --krb5adminserver=kerberos1.whatever --useshadow
Is setting those ldap and kerberos servers in the proper files now obsolete functionality? If that all needs to be configured manually (since there's no IPA or AD server involved here) then will anaconda grow support for that or will existing authconfig lines just not work?
Disclaimer: Fortunately for me I've recently switched to doing that kind of setup via ansible instead of using the authconfig line in kickstart. So technically I don't care any more, but I can imagine that there are still a number of people who do.
JR> == Scope == JR> * Proposal owners: implement the change JR> * Other developers: N/A (not a System Wide Change)
So I do think this is a bit wider in scope than the authconfig command going away, unless anaconda has stopped implementing the 'authconfig' directive by running authconfig.
- J<
On Tue, Jul 18, 2017 at 12:38 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JR" == Jaroslav Reznik jreznik@redhat.com writes:
JR> At the same time, some obsolete features of authconfig JR> would not be supported by authselect.
I have a couple of concerns about this.
First, this seems to impact anaconda/kickstart since the "authconfig" line basically _is_ an authconfig command line.
Secondly, what would replace a call like:
authconfig --enableldap --ldapbase=dc=whatever
--ldapserver=ldaps://ldap1.whatever,ldaps://ldap2.whatever,ldaps://ldap3.whatever --enablekrb5 --krb5realm=WHATEVER --krb5kdc=kerberos1.whatever,kerberos2.whatever --krb5adminserver=kerberos1.whatever --useshadow
Is setting those ldap and kerberos servers in the proper files now obsolete functionality? If that all needs to be configured manually (since there's no IPA or AD server involved here) then will anaconda grow support for that or will existing authconfig lines just not work?
Disclaimer: Fortunately for me I've recently switched to doing that kind of setup via ansible instead of using the authconfig line in kickstart. So technically I don't care any more, but I can imagine that there are still a number of people who do.
JR> == Scope == JR> * Proposal owners: implement the change JR> * Other developers: N/A (not a System Wide Change)
So I do think this is a bit wider in scope than the authconfig command going away, unless anaconda has stopped implementing the 'authconfig' directive by running authconfig.
Short version: this isn't going away in F27 and the Change title is misleading. Authconfig isn't going away at least until F28 (once authselect has been tested in the real world). The "auth" line in Anaconda will continue to be handled by authconfig in F27 (which is why this is a self-contained change rather than a system-wide one).
It will not actually *replace* authconfig until it can satisfy the requirements of the kickstarts as well (and not any earlier than F28).
-
Jakub Hrozek -
Jaroslav Reznik -
Jason L Tibbitts III -
Stephen Gallagher -
Tom Hughes -
Tomas Mraz