SSSD By Default
This feature is a proposal to include SSSD by default in the set of base Fedora 13 packages, and to have it be configurable, through authconfig, by firstboot.
- Name: Stephen Gallagher
- email: firstname.lastname@example.org
- Targeted release: Fedora 28
- Last updated: 2009-12-02 15:00:00 EST
- Percentage of completion: 10%
This feature would provide support in firstboot for joining a client to an LDAP/Kerberos or FreeIPA server. Users would be able to select "Use Network Login" during firstboot setup and configure it for connection to one or more central identity and authentication stores.
Benefit to Fedora
The prime benefit of the System Security Services Daemon is support for offline logins. Above and beyond the traditional pam_ldap or pam_krb5 approaches, the SSSD would remove the need for laptop users of Fedora to maintain a local account, separate from their centrally-managed account, to work offline or disconnected from the central servers.
The SSSD and its dependency packages (libtdb, libldb, libtevent, libtalloc and c-ares) need to be included in the default installation of Fedora. Support needs to be added to authconfig to provide a simplistic way to configure the SSSD. To that end, a python API is exposed from the SSSD that can be consumed by authconfig. Support for the new authconfig SSSD features needs to be added to firstboot.
How To Test
Testing will require a centralized identity and authentication store. The SSSD natively supports LDAP as an identity store, and either LDAP or Kerberos 5 as an authentication store. The SSSD has been tested successfully against FreeIPA (LDAP+Kerberos) as well as Fedora DS and MIT Kerberos, and limited testing against ActiveDirectory.
To test, one would need to configure the SSSD using authconfig to communicate with a centralized user store. Then they may attempt to log in using SSH or GDM (or KDM, etc.). If this succeeds, they can then attempt to do the same while offline.
If authenticating against a Kerberos server, they should also verify that they received a valid TGT (when performing online authentication).
Users with centrally managed accounts will no longer need to maintain second, local user for use when not connected to the central servers.
At this time, no dependencies other than those listed above are known.
If it is not completed in time, Fedora can drop this feature with no ill effects and continue to use the existing remote authentication methods.
These may be dependent on the work done in authconfig.